feustel@netcom.UUCP (David Feustel) (12/03/90)
In a previous posting, citing the 386/486 inability to use full sized 32 bit segments, I suggested a hardware modification for the Intel 80586 chip which would permit the use of segments of length 2**32. I have since discovered a method which permits the use of multiple 4 gigabyte data segments with the 386/486. The method is to mark the descriptors of all full sized segments as not present. Since the segment is not present, its address space is not mapped into the 32 bit virtual address space. When a reference is made to an address in one of these full sized segments, a segment fault occurs. The kernel analyses the instruction and simulates the faulting instruction after accessing a file containing the (sparse) segment data and either reading from or writing to the file the operand specified by the faulting instruction. The kernel then updates the ip and other registers involved and restarts the faulting task. This method permits the use of almost all data segments except stack segments as 32 bit segments; it is a *little* slower than the previously suggested hardware modification but does vastly increase the available address space. If you would rather have (faster) hardware support which would also permit 2**32 bit code and stack segments, speak to Intel about it. -- David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631 EMAIL: netcom.uucp
johnl@iecc.cambridge.ma.us (John R. Levine) (12/03/90)
In article <17945@netcom.UUCP> you write: >[mark extra data segments as not available and emulate instructions that >reference them] >This method permits the use of almost all data segments except stack >segments as 32 bit segments; it is a *little* slower than the previously >suggested hardware modification ... A little slower, huh? On a 486, an add from memory, a typical memory reference instruction, takes 2 cycles. Just the trap on a page fault takes about 100. In fact, what you're proposing is the same as loading and storing your data via a system call, and it's at least two orders of magnitude slower than normal loads and stores. Any scheme that tries to provide more than 32 bits of VM on a 386 or 486 is doomed to terrible performance, because you have to take traps and get the operating system involved each time you refer to some of the overcommited memory. The only thing I can see that has any chance of working is to allow each segment to grow to 29 bits, since that way you can always easily map all 6 addressable segments, put each file or whatever in a segment, and use relatively infrequent segment loads analogously to file opens. Regards, John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
peter@ficc.ferranti.com (Peter da Silva) (12/03/90)
Actually, the segments on the 80x86 are just fine for catching memory overruns, with minimal O/S support. Just make malloc give you a new segment each time... just the right size, of course. It's gonna be slow, reloading all those segment registers all the time, but not as slow as other methods of building a bondage- and-discipline runtime. (Just don't forget to link with the real malloc before you ship :->) -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com