OSDev.org

linguofreak wrote:I think it has more to do with C itself than any specific compiler. C was simply designed on the assumption of a flat memory model (with the exception of the fact that it can handle separate code and data spaces).

This is just plain false. C was designed with complex address spaces in mind. Why else are there all these weird rules about pointer arithmetic and what pointer comparisons are allowed? If C was designed with flat address spaces in mind, it would have just been "compare the numbers", but those are not the rules. The fact that the DOS compilers made a hash of things with their __far pointers doesn't invalidate that they could have just made all pointers far. That would have been a valid implementation.

nullplan wrote:

linguofreak wrote:I think it has more to do with C itself than any specific compiler. C was simply designed on the assumption of a flat memory model (with the exception of the fact that it can handle separate code and data spaces).

This is just plain false. C was designed with complex address spaces in mind. Why else are there all these weird rules about pointer arithmetic and what pointer comparisons are allowed? If C was designed with flat address spaces in mind, it would have just been "compare the numbers", but those are not the rules. The fact that the DOS compilers made a hash of things with their __far pointers doesn't invalidate that they could have just made all pointers far. That would have been a valid implementation.

The basic problem is that the compiler must minimize the number of far pointers (segment register loads) in order to achieve optimal performance. Watcom has based pointers, but I don't think these work in an optimal way. Ideally, all pointers should be typed so it was possible to determine if they were far pointer, ss-based, ds-based or cs-based near pointers. Then the segment part could be passed on stack or in segment registers (es, fs, gs).