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.



> 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.