glenn@extro.ucc.su.oz (G. Geers [ext 3241]) (09/08/88)
I am curious to know why Xenix 2.1.3 sets a maximum user process size restriction (329 kb with 640 kb installed on an AT). This seems to indicate to me that Xenix does not support the "advanced" features of the 80286 as described in the "Advanced Features" chapter of the 80286 Programmers Manual. Does microport also have this restriction ??? In particular, 'compress' (16 bit) has a bss of about 400 kb so will this run on either microport or xenix on an 80286 machine with only 640 kb of real memory ? I know that the best solution is to get a 386 machine but we pay the same price for a 286 as you guys (in the US) pay for the 386. Anyway any info could either be put on the net (unix.xenix or unix.microport) or mailed to me at the address given in the header. Thanks Glenn
plocher@uport.UUCP (John Plocher) (09/11/88)
In article <235@extro.ucc.su.oz> glenn@extro.ucc.su.oz (G. Geers [ext 3241]) writes: >I am curious to know why Xenix 2.1.3 sets a maximum user process size >restriction (329 kb with 640 kb installed on an AT). >Does microport also have this restriction ??? >In particular, 'compress' (16 bit) has a bss of about 400 kb so will this >run on either microport or xenix on an 80286 machine with only 640 kb of >real memory ? 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. On a 640K system, the kernel uses most (if not all :-) of the memory in the system and leaves very little for user programs. The quick and easy solution is to add more memory (compress runs with 1Mb albeit very slowly) - Microport recomends a minimum of 1Mb, with 1.5 to 2Mb giving even better performance. Sure, Unix runs in 640K, but when `size /unix` gives you a number near 250K and there are 50K of disk buffers, that leaves you with about 340K of user memory. This means that you *can* run unix, and quite a few programs, but vi, compress, and other "big" programs just won't fit. Compress, when compiled for 12 or 13 bits max, is smaller and may run in a 640K machine. But in any case I'd recomend adding at least 512K, if not 1Mb of memory to your machine. -John Plocher
jim@fsc2086.UUCP (Jim O'Connor) (09/11/88)
In article <466@uport.UUCP>, plocher@uport.UUCP (John Plocher) writes: > In article <235@extro.ucc.su.oz> glenn@extro.ucc.su.oz (G. Geers [ext 3241]) writes: > >I am curious to know why Xenix 2.1.3 sets a maximum user process size > >restriction (329 kb with 640 kb installed on an AT). > >Does microport also have this restriction ??? > > 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. On a 640K system, the kernel On page 9-1 of the Intel _80286 Operating Systems Writer's Guide_, it states: "The memory legitimately addressed by the tasks running on an 80286 (the [italics] virtual memory) may exceed the actual memory available. . . . Virtual memory isolates programmers from the amount of real memory in a computer system. . . . The 80286 provides the essential hardware mechanisms without which virtual memory systems would not be possible. . . In each segment descriptor, the 80286 architecture provides an [italics] accessed bit [ei] and a [italics] present bit [ei] to aid the operating system in simulating the virtual memory space with available RAM. . . ." 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?
woods@gpu.utcs.toronto.edu (Greg Woods) (09/12/88)
[ 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: <smtp relay1.cs.net glenn@extro.ucc.su.oz -2>: 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
vandys@hpisoa1.HP.COM (Andrew Valencia) (09/12/88)
>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. If memory serves (unlikely, but what the heck), there are generations of the '286 which would corrupt certain registers when taking a "segment not present" fault, thus making instruction restart impossible. Perhaps someone from Intel could give us the lineage of this bug (if any)? Andy
chapman@sco.COM (Brian Chapman) (09/14/88)
In article <1988Sep11.222005.14450@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes:
< 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.
I asked the same question about 2 years ago when I read that
same section of the 80286 chip book. I was told that there
was a chip bug where not all the instructions were restartable
when you got a "segment not present" fault.
I cannot be more exact that this. I do not know which instructions
are not restartable and I have never seen anything in writting from
Intel admitting this error.
--
Pay no attention to the man behind the curtain.
Brian Chapman uunet!sco!chapman UNIX Developmentrcd@ico.ISC.COM (Dick Dunn) (09/14/88)
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..."
jim@fsc2086.UUCP (Jim O'Connor) (09/15/88)
In article <9391@ico.ISC.COM>, rcd@ico.ISC.COM (Dick Dunn) writes:
: 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...
:
: 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.
:
: 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".
First of all, the statement above was not meant as a put-down. I worked with
that article with the intent of NOT making it sound like a flame.
Mr. Dunn has a point, however. In my analysis of uport's design decision, I
mixed the terms "virtual memory" and "demand paging", which I am aware are
not the same thing, and as such, was not correct in my own statements.
The 80286 does not directly support "demand paging", which is the easiest way
to provide "virtual memory". However, my original intent was to offer evidence
that the 80286 *does not require a process to be completely in RAM* in order to
execute. My reading of the original article lead to me believe that Mr. Plocher believed that it did. For not clearly stating this intent, I do apologize.
However, unless the hardware bug several people mentioned (which inhibits
restartable instructions) has still not been fixed, I believe that some form of
virtual memory can be had with the 80286. As several people have pointed out,
it would probably not be worth the effort, but it cannot be said that it is
impossible.
---
James B. O'Connor +1 615 821 4090 x651
Filtration Sciences Corp. UUCP: uunet!fsc2086!jim
105 West 45th Street or jim@fsc2086.UUCP
Chattanooga, TN 37411johnl@ima.ima.isc.com (John R. Levine) (09/15/88)
In article <9391@ico.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: > - 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-- ... Sure there is, the B5000 series had an addressing architecture somewhat like the 286 with lots of segments of various sizes, and they got its virtual memory to work around 1960. Then again, given that a 286 segment can and usually will consume an appreciable part of physical memory, that some 286 chips don't take page faults reliably, and that the cost difference between a 286 system and a 386 system is rapidly vanishing, I won't argue that it's a waste of time to try to make a virtual memory 286 Unix. -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { bbn | think | decvax | harvard | yale }!ima!johnl, Levine@YALE.something Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw
plocher@uport.UUCP (John Plocher) (09/16/88)
In article <249@fsc2086.UUCP> jim@fsc2086.UUCP (Jim O'Connor) writes: >However, unless the hardware bug several people mentioned (which inhibits >restartable instructions) has still not been fixed, I believe that some form of >virtual memory can be had with the 80286. As several people have pointed out, >it would probably not be worth the effort, but it cannot be said that it is >impossible. Even if the bug was fixed, it still would not be possible for a company to implement "virtual" memory on a 286 for the simple reason that there is NO way to insure that the customer who buys your software has a good version of the CPU. Most (All ?) the ATs shipped by IBM have a "bad" CPU - by IBM's choice. >James B. O'Connor +1 615 821 4090 x651 >Filtration Sciences Corp. UUCP: uunet!fsc2086!jim -John Plocher
woods@gpu.utcs.toronto.edu (Greg Woods) (09/16/88)
In article <544@sysco> chapman@sco.COM (Brian Chapman) writes: >In article <1988Sep11.222005.14450@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: > >< 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. WRONG! I included those lines in my reply to the original author however. I'm too tired to go searching down the original author's name, sorry. -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada