Programs larger than real memory on an 80286 ???

[Greg Woods]

[ I tried sending this my mail to jim, but I got this: 
	554 jim at fsc2086.UUCP... Unresolvable address jim < @ fsc2086 >

I also tried sending a similar reply to glenn at extro.ucc.su.oz:
	<smtp relay1.cs.net glenn at extro.ucc.su.oz -2>: 192.5.58.1: (BHST) Unknown host/domain name in "glenn at extro.ucc.su.oz"

With the current flux in the mail systems, I'm giving up waiting for
things to get fixed.  Everyone will probably enjoy this anyway :-)
-Greg. ]

In article <183 at fsc2086.UUCP> jim at fsc2086.UUCP writes:
> 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.
> 
> Mr. Geers' gripe is a legitimate one.  Apparently the 80286 has been able to
> support virtual memory systems, yet the 80286 OS designers chose to leave it
> out.  I would be interested in hearing why.  Surely you all bought the Intel
> book I mentioned, I don't think I paid more than $20 dollars for it, and I
> was just a curious programmer.
> 
> 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. :-)
> 
> Since there is all that demand paged code written for the 386, I don't 
> suppose anyone wants to retrofit it to the 286, now that we know it
> should be possible?

I'll give you an educated shot in the dark as to why 286 OS designers
don't bother with virtual memory implementation.

It wouldn't be worth it.  The resulting implementation would probably be
just too slow to use.

It may also be the case that full memory protection schemes wouldn't
work properly with virtual memory implementations.  I seem to remember
some concern about this possibility.  In fact, I'm quite suprised that
286 OS implementations can trap all possible illegal memory accesses.
(Maybe they don't :-)

The Intel CPU designers (or marketers :-) have a bad reputation for
making claims about what their chips can do.  I specifically remember
being told that everyone would use only large model (ie 32 bit pointers)
compilers in the future and that the current (ie Intel's first version)
compilers supplied small model only for standalone code and for those
applications which proved difficult to make work in environments where
sizeof(int) != sizeof(char *).  As it turned out, large model suffers
too much of preformance penalty, AND too many arbitrary restrictions (ie
huge model is very difficult to make work and use, as well as being even
slower); so we live with small model for most things, and are not much
better off (software wise) than users of PDP 11's were 10 years ago!

I doubt the 386 demand-paging code would be worth 2 cents towards making
a 286 virtual environment work.

NOTE:  ISC did complete a port of Unix System V Release 3.0 to the 286,
including STREAMS and RFS.  I understand however that it did not work
reliably under load.  There was some mention about SysVR3 requiring
atomic 32 bit operations in the kernel.  Not sure why this is required...

I can't say for sure whether the ISC port supported demand paged virtual
memory or not either....  They did say that it was a dog though :-)

[ I added the following to glenn at extro.ucc.su.oz: ]

I guess it's much the same problem Motorola had when they tried to claim
that the 68000 was a 32/16 bit CPU.  Sure, you could even write a C
compiler for the 68000 that used 32 bit ints, but you didn't get much
preformance, since the 68000 had a 16 bit ALU.  (It was still faster
than your average 286 @ 6MHz though :-)

I'm curious as to why you find the 386 out of your price range.  Here in
Canada, the 386 clones are cheaper than 286's were a year ago, and the
286's aren't much cheaper than 386's currently.  When you look at the
overall economics, I see no reason for anyone to buy a 286 for anything.
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: (416) 242-7572 [h]		LOCATION: Toronto, Ontario, Canada