Re: Memory issues and USB support? (and OpenWatcom)

[Alan Cox <alan@llwyncelyn.cymru>]

> 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