> That kind of leads me to something else I wanted to ask about: I take > it the requirement to use small mode is because of the bcc compiler? Moving to large code isn't a problem, but large data means far pointers and that means a huge slowdown in performance. Instead ELKS has some facilities to allow things like disk cache to be in a different segment. For userspace large models also mean you can't do swapping until you have 286 protected mode. > > In the Linux 8086 case the big problem is the kernel stack for each > > process comes from that 64K. > > On entry to the kernel, couldn't one change SS:SP to point to some > other memory area? It looks like the parameters to system calls are > in registers rather than on the stack. Is it just a case of not > having done this extra work of managing more bits of memory yet, or is > there an architectural limitation here? SS and DS have to be the same in small and tiny mode. A syscall switches to the kernel code and data so the kernel has 64K of data to play with. It uses a load of it on kernel stacks it could avoid at a small cost on context switches. If that were fixed there would be plenty of kernel data space. > I was kind of thinking that a process whose pages are in EMS are > unlikely to get corrupted by a process running off the end of an > array. I realise that I shouldn't have used the term "memory > protection" though! It's less likely one would be scribbled on, but in fact if you give a 16bit process 64K code and 64K data it has to corrupt segment registers to scribble outside of its space and that makes it more reliable than you might expect. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
