From: | jgd@cix.compulink.co.uk |
Newsgroups: | comp.compilers,comp.arch |
Date: | Sat, 06 Dec 2008 15:35:47 -0600 |
Organization: | Compilers Central |
References: | 08-12-025 |
Keywords: | architecture |
Posted-Date: | 06 Dec 2008 17:25:30 EST |
tony@my.net (Tony) wrote:
> I looked into this 10 years ago and convinced myself that the
> segmented architecture is still there but that the segments are
> just now very large (move from 16 to 32 bit?). (Is that the case?).
Yes. As the moderator of comp.compilers pointed out, every x86
processor, including the 64-bit ones, has a segmentation system that
nobody uses, except for operating system writers. Segments are 32-bit
sized in 32-bit mode, and 64-bit sized, really huge, in 64-bit mode.
I've done programming with segments on 16-bit systems, and found it very
painful, even if one wasn't hitting segment size limits. I've also
programmed bank-switched memory systems, which have a certain amount in
common with segmentation, and they're horrible too.
It is easy to construct scenarios where segmentation is advantageous,
but proponents of the idea tend to neglect the cases where it is no use,
and the ones where it's a complete pain.
Segmentation is fine as a means for isolating processes from each other,
and that's how it gets used. If a means could be created for it to
enforce memory protection of objects from bad pointers, without
requiring large hardware or performance overheads, that would be
interesting. But it's going to take more cleverness than is so far
visible to make that work.
Bringing back segmentation for everyday programming because the idea
appeals ... it's like claiming that airliners should have piston engines
again because they make a cool noise. The idea only makes any sense if
you don't understand the issues.
--
John Dallman, jgd@cix.co.uk, HTML mail is treated as probable spam.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.