sr (nobody.delete@this.nowhere.com) on October 1, 2021 12:22 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on September 25, 2021 3:29 pm wrote:
>
> > That's missing the whole point. You can't do any addressing without dragging the segment
> > IDs ("selectors") along. So you end up with 48 bit pointers with the 386 segmented model,
> > or you go back to a mixed memory model where some pointer are short ("near"), with an implied
> > segment, and others long (far") with an explicit selector dragged along.
>
> I might be wrong again, but as I recall 386 didn't have 48 bit virtual address space but
> 32 bit. So segmentation wasn't used to increase virtual address space like with 16 bit systems.
> So near pointer can cover whole address space as it should and segmentation is only used to
> slice that address space into smaller subsets where addressing starts from zero.


The 386 had a 48(-ish*) bit virtual address space, but that was mapped into a 32 bit linear address space. Increasing the size of the linear address space would be been fairly trivial, and essentially invisible from the application layer (given the era, it's obvious why they wouldn't have initially defined the linear address space bigger than 32 bits). Not really unlike how the 286 had a 32(-ish*) bit virtual address space mapped into a 24-bit physical address space (and how a 16-bit OS could have used the 386 enhancements to address more than 24-bits worth of memory, without using any "32-bit" feature of the CPU - just extra, previously unused, bits in the descriptor tables).

I don't think anyone ever actually did it, but ideas for mapping more than 4GB worth of segments into a process using PAE hacks were tossed about in the late x86-32 era.

*A bit in the selector to pick the GDT or LDT, 13 bits to pick a segment descriptor within one of those tables, and a 32 (16 for 286) bit offset within the segment. So 46 or 30 bits. Practically somewhat less, assuming some inefficiency in using the structured address.


> > There are other imaginable ways to do this (most obviously packing the selector into the high bits of a
> > 64-bit pointer), but that doesn't solve all the problems, and is not anything you can actually do on x86.
> > On the other hand, if you're just using the high bits of the pointer as a selector, you can do almost as
> > well with a sparse-ish address space and 4KB pages (IOW, any allocated object has guard pages around it).
> > Heck, we could tweak C malloc() to do that in about 15 minutes - storage allocation would just get a fair
> > bit slower (although using that allocated storage would not).
> > Neither approach really gets you to a capabilities-like
> > model where you can pass a *protected* subset of an allocated object to someone.
>
>
> Don't confuse simple segmentation to more complex software ways to protect memory segments.
> With segmentation you can segment your data structures and let hardware do boundary checking.
> Like with that Linus null pointer chaser example, with software every round of loop need to
> checked against table boundaries but if that table was segmented into it's own space that won't
> be necessarily. Algorithm can't go out from it's segment if some reason NULL check fails.


Sure, and that way lies capabilities.

A problem with x86 segments in that role is that establishing "sub" segments is going to be fairly painful, and the limited size (8K entries) of the descriptor tables puts a pretty hard limit to how much of that you can actually do. Even if you don't subset segments, and just assign segments to memory allocations, you don't really have enough. And as I mentioned, if you're just trying to catch allocated area overruns, you can do almost as well just by assigning guard pages around allocations. The quite high overhead of loading segment registers would have been an issue for all actual implementations (clearly at least some optimizations would have been possible for that problem).