16bitPM wrote:
nexos wrote:
The real show-stopper for segmentation is the lack of toolchain support. GCC / Clang / CL, which are by far the three dominant compilers of the day, have no support for segmentation whatsoever. The only production-quality C compiler I can think of that does support segmentation is Open Watcom.
True, but it's not very well documented if you ask me.
nexos wrote:
For example; it's much easier to work with a flat address space than a segmented one.
I'm guessing that also has to do with OS design. For me, the logical distinction comes natural (and it did so too when Multics was designed).
nexos wrote:
Not to mention that it's much faster too; on modern CPUs with PCID support, switching page mappings is very fast. On segmented system, you have to re-load the LDT every time, which isn't too expensive when segmentation is used lightly, but gets very expensive very quick when you have many segments in your address space.
First of all, there is also overhead in maintaining a paged system even with PCID. Secondly, reloading the LDT is just loading the appropriate LDT selector, putting the data in LDTR and do some checks.
This is independent of the number of selectors. The timings for the LLDT instruction on old CPU's (I only have those readily available atm, but they should be within the same order of magnitude for newer CPU's) are :
80286 : 17-19 cycles
80386 : 20 cycles
80486 : 11 cycles
Pentium : 9 cycles
That's not so bad. Of course, the LDT has to be filled, but that's probably mostly at the start of the process.
nexos wrote:
It also is much more granular; you control memory down to the page, which is very useful for swapping, memory protection, and other things. It also provides clean separation of physical memory and the address space, which is very useful to user applications.
You are confusing both. For segments <1MiB, the granularity is 1 byte, and for big (1MiB-4GiB) segments, it's 4096 bytes : the same as paging.
As far as I know, the minimum page size is still 4096 bytes.
The point is, if you have *only* segmentation, without paging, then a segment can only be swapped in or out as a unit. If the segment is 1 kB, that's fine. If the segment is 1 MB, that's probably not too much of a problem, at least on modern systems. If the segment is 1 GB, that's a problem. With paging, a 1 GB chunk of address space can be partially swapped out.
Quote:
nexos wrote:
If you are not convinced that paging is better, look at the mess that C development became in the old days of Win16. Any developer who values their time would not want to mess with that.
That was only a problem because of the 64KiB limit,
not of the segmentation concept per se.
Also, if you ask me, paging has become a mess. Just looking at all the features that have been added in the past 20 years...
Many of the performance-related criticisms have also more to do with chip developers putting all their money on paging. They COULD have added a descriptor cache, but they didn't.
They also could have added a TSS cache, but... they didn't.
Given the nature of Intel segmentation specifically, one of the issues is that it adds an addition to every memory access (thus putting more load on the ALU or requiring a dedicated adder in the address logic), and that that addition must precede anything that depends on knowing the logical address of the memory access, whereas paging gives more room for certain types of speculative access.
Quote:
A lot of things that come automatically with the concept of segmentation, have to be done in software instead : position independent code,
PIC can be enabled by other architectural features (such as IP-relative addressing modes being readily available).
Quote:
oh yeah, and it's possible to address more than 4GiB on a 32-bit system within 1 process space.
For a general segmented system, yes, it is possible to design the system this way. On Intel, yes, you can do this, but with some significant limitations:
1) The process can have segments totaling more than 4GB, yes, but only 4GB can be accessible at any one time (logical address space, whether paging is on or off, is only 4 GB). If you're copying data from a 3 GB segment to another 3 GB segment, you won't be able to have both present at the same time and any instruction that tries to access both simultaneously will take a fault on whichever segment is currently not present, you'll swap in that segment, but in the process boot out the other segment, so when you restart the instruction it will fault on the other segment, and so forth.
2) If you wan't to keep all of a program's data in memory (even though it isn't all in the 4GB logical address space) you'll need paging, and in fact, will need PAE paging. If you use segmentation only, without paging, then anything more than 4GB, on either the system or the program level, will require swapping to disk.