sr (nobody.delete@this.nowhere.com) on September 25, 2021 11:11 am wrote:
>
> Am I understand 386 segmentation wrongly? Process have all rights and you
> could segment it pretty much without limits to any wanted slices, dynamically.
> Page size isn't limiting factor, segments can go smaller than pages.

You are wrong in some details, but not in the big picture (*).

But what you are missing is that the i386 segments are very expensive.

They are expensive to set up, they are expensive to load, and they are expensive to use in code (because of the extra segment selector you have to carry atound).

> And about costs -x86 segmentation is basically free.

Not even close.

x86 segmentation is "free" only if you don't actually use them at all, and use only a small fixed set of segments that you can keep in the very limited segment cache (ie the four segment registers, plus CS/SS).

> Yes, modern designs have one cycle additional latency when segment offset is non-zero
> but that's only hardware limitation [..]

No, it's somewhat fundamental.

You are right that you wouldn't have the extra cycle if people used segments with non-zero bases more, but that's not because you can make it go away - that's because you'd just never implement the "zero base" optimization. Instead, you'd be forced to do the base addition every single time, and have it as a cost in the most critical path of the most critical part of your CPU.

But that single-cycle cost (which would be just a partial-cycle FO4 cost if it was done all the time) is the least of the problems.

The much bigger problem - and the much bigger cost - of actually using segments is h ow you have to carry the segment selector around with your pointers, and how you have to load the segmenty registers when using it. Those are the big costs. And they are why nobody uses segmentation.

Once the segment information is cached, it's (almost) "free". But it's only cached if you never use segments, and never switch them around.

And it's entirely useless as a debug functionality. The performance overhead of setting up and using multiple segments, the overhead of passing pointers around as 16-bit selector plus 32-bit offset, that would all be acceptable in a debug build.

But it's completely unacceptable from a software overhead standpoint, and you couldn't reasonably ship that same binary that you used for debugging as a production binary. So the debug code would be something completely different from what you actually run in production, which makes it almost worthless. There are much better models for debugging.

A debug build needs to basically be able to run the same binary without any major changes. So maybe you link in a different malloc() library or something like that. But not the complete code changes that using segments requires.

> I always adored 386's MMU - it really seem to be great achievement.

It's an "achievement" all right.

It took the ungodly garbage that was introduced in the 286, and made it still be usable in a 32-bit environment.

It's a masterclass in backwards compatibility, and it should be admired for that. It made the 386 successful, in that it allowed a seamless upgrade path from one of the worst architectures ever designed, to one that wasn't bad, but can obly be called "baroque" in the details.

So the 386 segmentation was very much what made the architecture. It was hugely important. It was technically the right thing to do at the time, and the 80386 designers should get huge kudos for it. No question about that.

But it should be admired from a distance, and as a warning to others.

Linus