Programs larger than real memory on an 80286 ???

[Dick Dunn]

In response to a question about requiring the whole process to be in memory
on a 286, John Plocher wrote:
> > Microport Unix V/AT requires that the complete image of a process be in
> > memory while it is being executed.  This is because the 286 does not 
> > support demand paging like the 386 does...

Note carefully what he said, and he is correct.

Jim O'Connor responded, from the 80286 OS Writer's Guide:
> "The memory legitimately addressed by the tasks running on an 80286 (the
> [italics] virtual memory) may exceed the actual memory available...
and then claims:
> The rest of the chapter goes on to explain, in quite a bit of detail, how to
> support demand paging.  I believe your statement above to be incorrect.

This is completely false.  The only discussion of paging in the chapter is
to explain how it doesn't apply to the 286!  For example (p. 9-6):
    "There is, however, a distinction between _segmented_ architectures and
    _paged_ architectures.  The 80286 has a segmented architecture.  Liter-
    ature that deals with paged architectures may not apply to the 80286..."

I don't know how much plainer they could be!

Mr. O'Connor finished with the put-down:
> In the future, it would be appreciated if you had all your facts straight when
> justifying design decisions.  Of course, if the data published by Intel is
> incorrect, the pie is on my face instead. :-)

The data published by intel is not (in this case:-) incorrect, but the egg
is certainly on your face.  You owe John Plocher an apology, and YOU need
to have YOUR facts straight before you flame.  The 286 provides limited
support for virtual memory, but no support for paging.  "Virtual memory"
is *not* the same as "demand paging".

Various people have explored how you might do various things to make a
286 virtual memory mechanism shuffle program memory in and out.  Although
the 286 can have a large number of segments (8k of them), it's not
practical to try to treat segments as pages, for various reasons...
  - Unlike pages, segments are *not* transparent.  Crossing a segment
    boundary (in either code or data) involves reloading a register.
    Also, the segmentation makes the address space only piecewise-linear
    even if you treat it as a 32-bit address space (really 29).  You would
    effectively limit procedure size to the limit you chose for your pages
    (unless you wanted to try the 370 game--and even that won't work 'cause
    you only have one code base register).
  - There's no good choice of segment size:
     - For effective demand paging, you want a large-ish number of
       relatively small pages.  (Page size should be about the square root
       of physical memory size, as a very rough guess.)
     - For effective segment utilization and efficient code, you want a
       small number of large segments.
     - It's not practical to have mixed sizes of demand-pageable memory
       chunks:  It immensely complicates swap-space allocation and page-
       scheduling algorithms.  It's likely to cause serious fragmentation
       of physical memory.  There isn't even any significant body of know-
       ledge about how it would work--which certainly means you don't want
       a small company, selling a commodity-market system, to try to invent
       it.
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...Worst-case analysis must never begin with "No one would ever want..."