Adrian (a.delete@this.acm.org) on January 9, 2020 11:49 pm wrote:
>> Anon (anon.delete@this.anon.com) on January 8, 2020 8:37 pm wrote:
>> [snip]
[EMPHASIS ADDED]
>>> To name one bad feature I will say segments, of all methods of addressing
>>> data beyond the native int size Intel probably choose the worst of them.

[snip]

> Segments used for address extension are definitely very bad, there is no doubt about that. I remember with
> horror the ancient times when I had to juggle with the large, medium, compact and small memory models.

While the use of register pairs is cleaner and one can even always use double-width addresses, for optimized code one would still have to use different pointer reaches (possibly even sort-of-emulating segments by moving reused "segment values" in registers to be paired with different regsiters, i.e., not limiting smaller references to a zero segment). An always double-width address programming model would seem to be similar to always using doubles on early SPARCs which used register pairs for double precision.

For early microprocessors, the number of registers was limited in part from area issues. With 32 16-bit registers, sacrificing four to eight for the more significant bits of 32-bit addresses might not be problematic. With 16 registers, the performance impact might be measurable. With 8 registers, doubling the register consumption of pointers would seem likely to significantly impact performance.

Using register pairs for 8086 might have implied that a mode would be set for default addressing and an override prefix would be used to specify that the other address size is being used (register pair (32-bit) addresses in legacy mode, single-register (16-bit) addresses in extended mode).

Adding code, data, and stack segments would provide "free" encoding of the address extension. For 16-bit addresses, code could more easily use a large portion of the available address space, so a quasi-Harvard architecture would be more helpful than in a 32-bit address space. The separation of stack references would come mostly for free (one might need to provide an override to allow non-stack pointers to reference the stack, though introducing the coding discipline of allocating local objects off the stack might have been appropriate), but would not add much memory space. User-space swapping of segments would have provided an additional benefit over PAE (which by requires privileged access to change address translations).

Manually tracking segments would be similarly annoying to overlays in early systems. Such also does not play well with large arrays. However, it does seem better than a PAE-like mechanism, especially with 16-bit words; far jumps could encode the target segment into the instruction (and indirect far jumps might even be used to provide 32-bit instruction addresses) with a caller segment saved on the stack with the rest of the return address. For data, one could support over-/under-flow into the segment (so streamed accesses in one direction could be transparent), but the limit of one data segment would be painful.

The design space is not entirely descrete. If every register was associated with a segment, the difference from doubling register size would be modest in terms of saved area (and the nuisance of lack of "full-size" operations might be significant) and this would look similar to using register pairs. PowerPC segments are not extremely dissimilar to PAE, using the most significant bits to specify translation blocks; if x86 PAE had assigned four ASIDs that could be changed independently, the difference from PowerPC segments would seem limited to having only four segments rather than sixteen. In theory, such ASIDs would not have to be trusted but could be changed without privilege, being treated as extending the virtual address space.

Segments have the advantage (and disadvantage) over register pairs of using a separate name space. This adds state, but the state would be less than for doubling the number of registers. This state could also be more easily treated as pseudo-constant, facilitating some storage/access optimizations. If associated with sets of registers (which could include having two registers linked to the code segment such as self-modifying code might be expressed by storing with address insets in one of these registers), the number of segments might eventually be increased to one per register and then merge the segments and registers to form double-width registers.

PAE is perhaps the cleanest address space extension from an application perspective, but only provides single-thread address space extension through system calls with the similar "overlay" semantics to segments. I think this makes PAE worse than segments; segments could provide the same transparent extension by having all segments be equal and if the most significant bits are used to specify the segment then the difference seems small. (Using the least significant bit(s) with assumed alignment of base pointers would be more problematic at 16-bits because only one bit might be affordable, which would probably be insufficient.)

I am not suggesting that segments are as clean as just doubling the size of registers, but as a half-measure under the requirement of keeping "native int size" the same segments do not seem that bad.