OSDev.org

Far be it from me to defend C, but I really don't think you are right in this, for a number of reasons.

First, the main complaint you make has no applicability to long mode, nor to CPU architectures which have never had memory segmentation to begin with. Memory segmentation is a peculiarity of the 8086 borne of the cost of memory addressing hardware at the time it was designed - memory protection wasn't a significant consideration, as the 8086 was only meant to be a short-term design primarily intended for embedded controllers anyway - and one which even Intel has admitted was a mistake. The only other segmented-memory CPU architecture of any note, the IBM System/360, similarly abandoned segmentation as a bad design choice in the mid 1970s.

Second, segmentation is actually significantly slower than page-based memory protection for 32-bit protected mode in most current x86 models. Now, admittedly, this is because Intel has de-emphasized support for segmentation since the 80386, and not an inherent aspect of the segmented model, but it is still the case.

Third, the question of segmentation had nothing to do with the C language at all. While the current dominant implementations (GCC and Visual C++) only work with a flat memory model, both the Borland and Watcom C compilers handled segmentation quite satisfactorily, and AFAIK their successors still do. The Amsterdam Compiler Kit C compiler used in early versions of Minix had no problems providing for a segmented OS written in C.

Fourth, the issue of monolithic vs. micro-kernel is orthogonal to the issues of languages and memory models. Both micro kernel systems (such as the above mentioned Minix) and monolithic kernel designs (e.g., Xenix, Coherent, UCSD Pascal) have been written for x86 real mode, using assembly, C, or even some other languages (e.g., Pascal, Parasol, Modula-2), so arguing about the kernel design methodology is pretty meaningless here.

(As an aside, I would like to remind you that the original impetus for developing the micro-kernel model in the late 1970s was to provide better process isolation in systems with no hardware memory protection - such as the 8086.)

Finally, segmentation does not actually provide any improvement in the level of memory protection from paged protection in 32-bit protected mode, and in fact, IIUC more recent 32-bit x86 processors (by AMD, at least, and possibly those by Intel) don't actually implement segmentation in hardware at all - it is actually emulated in firmware using the page protection mechanisms (which may be related to point two above). If anyone knows more details about this, please speak up, as I am not entirely certain if I am right on this point. Whether this is the case or not, however, what does matter is that segmentation is both less flexible than paging, and provides no protections which paging doesn't - it provides fewer, in fact, as the read-only limitations on user-space memory in a given segment are all-or-nothing, whereas page protection can be set on a per-process and per-page basis. While it is true that a given segment can be as small as a page or as large as the full addressing space, whereas paging requires all pages to be the same relatively small size, using segments in a fine-grained manner would, in effect, be using the segmentation to emulate paging - there would be no significant advantages.

While it is true that C compilers running in flat mode rarely take proper care in handling the page settings, and for that matter few operating systems give the compilers fine-grained control over setting page protection to begin with, that is a flaw in the OS and/or the compiler, not in the language itself, I would say.

Hi,



I can't see how it could be possible to emulate segmentation (using paging) in firmware, or in micro-code. There's 2 problems - the first is that an OS could use both segmentation and paging at the same time (so firmware can't use paging to emulate anything without interfering with the OS); and the second problem is granularity (e.g. you can have a segment with "base = 3, limit = 11" which can't be emulated use "aligned 4 KiB chunks only").

As far as I know; all modern CPUs implement segmentation (for loads/stores) as part of their pipeline, except that parts are disabled/skipped in certain cases (e.g. the "address = offset + segment base" gets skipped if segment base is zero or you're in long mode, and similar for the limit check). Segment register loads (which are infrequent and messy/complex) are done by micro-code.

More specifically; I'd assume that a modern CPU can be split into 2 logical parts - the pipeline itself, and "pipeline control"; where the pipeline itself knows very little (e.g. only knows that the current default code size is 16-bit, and doesn't know or care if the current CPU mode is real mode or protect mode or virtual8086 mode or long mode or system management mode), and where "pipeline control" is mostly done with micro-kernel and handles everything that the pipeline doesn't (e.g. segment register loads, interrupts, CPU mode switches, etc).


Cheers,

Brendan

Your efficiency claims are as good as fiction without proof.

Hi,



You only need to see the "small address spaces" research done by L4 to see that there's some potential benefits in using segmentation to reduce task switch costs (at least for artificial micro-benchmarks that may or may not have any practical value, for systems that don't use asynchronousity to reduce the number of task switches).

Of course that has nothing to do with "C vs. assembly" and nothing to do with the relatively bizarre (and likely very erroneous) "assembly is less error prone because it can use segmentation while most C compilers can't" issue.


Cheers,

Brendan

I must have misunderstood what I'd read, then. Thank you for pointing that out, I feel embarrassed for missing what should have been an obvious point.