jca@pnet01.cts.com (John C. Archambeau) (07/21/89)
Leisner.Henr@xerox.com (marty) writes: >Having a C compiler which understands segmentation is part of the problem. > >Having an operating system which understands segmentation is another >problem. > I never said it would be easy now, did I? The iAPX 286 manual should tell you everything you ever wanted to know about 286 protect mode but were afraid to ask. The problem is that there's LITTLE documentation on 286 protect mode. The 286 protect mode linker has to juggle these descriptor tables that are ambiguous enough to people who wright extended memory ramdisk drivers. The memory manager system task will also have to handle context switching and multiple code and data segments, but the moral is that it CAN be done. It just takes somebody stubborn enough not to give into the fact that it's more trouble that it's worth. This might be the case for you, but it's not the case for me. I am stubborn enough to write the linker myself if need be as I stated before. You and I both know that all problems with segmentation will disappear when you go to a 386 or 486, well that's fine and dandy, but it's a waste with 286 protect mode and I HATE waste. With 16 Mb of physical memory, you will fill up the process table before you fill up physical memory, in fact, I'm sure that this will happen with only 8 Mb or perhaps 4 Mb of memory. 128K is a small piece of memory when you stop to think about it which is the maximum size of PC Minix processes under the current C compiler. /*--------------------------------------------------------------------------* * Flames: /dev/null (on my Minix partition) *--------------------------------------------------------------------------* * ARPA : crash!pnet01!jca@nosc.mil * INET : jca@pnet01.cts.com * UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca *--------------------------------------------------------------------------*/
Leisner.Henr@xerox.com (marty) (08/16/89)
Having a C compiler which understands segmentation is part of the problem. Having an operating system which understands segmentation is another problem. How does brk work on a segmented system? Think about it. The 286 malloc/brk systems are somewhat bizarre (compared to linear address space machines). I tend to think the 286 is a collossal blunder which is incredibly difficult to deal with. Xenix 286, MicroPort and Ms-Dos vendors have a large market to target at of people who have 286 machines. I spent a lot of time with the 286 and kinda feel it wasn't worth it since to get take advantage of the 286 hardware its hard to have a generic operating system. I feel protected mode buys you significant OS features (well, protection for one). A mixed model C compiler in a non-linear address space just causes grief. It would be relatively simple to generate large data model code with 1 code, 1 data, 1 stack segment -- on the surface this fits Minix'es memory models but I found it would require extensive changes to the system to implement (there is a implicit assumption S and D are in the same data space and all messages are passed in D space). marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
ast@cs.vu.nl (Andy Tanenbaum) (08/26/89)
In article <20050@louie.udel.EDU> Leisner.Henr@xerox.com (marty) writes: >It would be relatively simple to generate large data model code with 1 >code, 1 data, 1 stack segment -- If you pass the address of a variable to a procedure, you also have to pass one extra bit saying whether it is a data space address or a stack space address. Thus all pointers must be 32 bits. This will slow down execution considerably. Andy Tanenbaum (ast@cs.vu.nl)