Xref: utzoo comp.unix.xenix:3286 comp.unix.microport:1520 Checksum: 33919 Path: utzoo!utgpu!woods From: woods@gpu.utcs.toronto.edu (Greg Woods) Date: Sun, 11-Sep-88 22:20:05 EDT Message-ID: <1988Sep11.222005.14450@gpu.utcs.toronto.edu> Organization: G. A. W. Consulting Newsgroups: comp.unix.xenix,comp.unix.microport Subject: Re: Programs larger than real memory on an 80286 ??? Summary: not worth the bother References: <235@extro.ucc.su.oz> <466@uport.UUCP> <183@fsc2086.UUCP> Reply-To: woods@gpu.utcs.Toronto.EDU (Greg Woods) [ I tried sending this my mail to jim, but I got this: 554 jim@fsc2086.UUCP... Unresolvable address jim < @ fsc2086 > I also tried sending a similar reply to glenn@extro.ucc.su.oz: : 192.5.58.1: (BHST) Unknown host/domain name in "glenn@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@fsc2086.UUCP> jim@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@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