randy@umn-cs.cs.umn.edu (Randy Orrison) (02/23/88)
I have noticed people posting in here talking about programming and using
various models. Is this for real? Doesn't Unix use the full address space
capabilities of the 286 & 386? For that matter, do the 286 & 386 allow you
to get away from the silly 64K segments? I'm programming under MeSs-DOS now,
and had really hoped not to have to think about segments (yech) when I
got unix (which i am hoping to do...).
-randy
--
Randy Orrison, University of Minnesota School of Mathematics |
UUCP: {ihnp4, seismo!rutgers, sun}!umn-cs!randy | (hello?)
ARPA: randy@ux.acss.umn.edu BITNET: randy@umnacca |
(Applications currently being taken: short text, for last line of .sig)hedrick@athos.rutgers.edu (Charles Hedrick) (02/26/88)
randy@umn-cs.UUCP (Randy Orrison) expressed surprise that people were talking about memory models on Unix. He had hoped that under Unix, 64K would no longer be a magic number. Sorry to break it to you, but... The only way to get around the silly segments (as you put it) is to get a machine that uses a decent chip. I haven't played with the 386, so I can't comment on it, but the 286 isn't one. The 386 does allow arbitrarily large segments, so 64K is no longer a problem there, but on the 286, it certainly is. Changing OS's from MS-DOS to Unix can't fix that. Unix runs in protected mode. The problem is that the address space in protected mode contains 3 bits of access mode right in the middle of the address. So you go from address 2fffff to 37ffff. (One wonders why they didn't put the magic bits at the other end of the word. Were they *trying* to make the machine unusable?) There's no way to get a big linear address space. Microport supports small and large models. Small model is 64K each for code and data. Large model lets both code and data be as big as you like. But no one object (subroutine, array, struct, or malloc'ed block) can cross a 64K block, which means they can't be bigger than 64K. Microport doesn't support the huge model. The huge model emulates a linear address space. I'm not sure quite how it would be done. Probably you'd store addresses with the high-order 16 bits right-shifted by 3 bits, so that you had a continuous address. Then when you needed a real machine pointer, you'd shift the high-order word left and supply the dratted access mode bits. Fortunately none of the software I've tried to port so far has really needed more than a 64K block of memory. But if I were trying to do big Fortran things, or tried to port the real (Gnu) Emacs, I'd be really in trouble. Fortunately, for a great majority of C code, there is no problem. I used to think a 286 would be lousy for Lisp, but there should be no problem doing a Lisp for the 286, since Lisp typically has lots of fairly little blocks of memory. What protected mode does give you is in effect an MMU. Your programs don't have to know where they are in memory. In MS-DOS, the segment registers have to be set up by the OS based on your physical location, and if you change them you can write over somebody else's memory. Also, your program has to be contiguous in memory. In Unix (or any system that uses protected memory), each 64K chunk can be anywhere in physical memory, and the OS can move them without your program knowing anything. But the fact that there are 64K chunks is still visible. (Actually, they needn't be 64K. 64K is a maximum. They can be smaller. If you have some reason to do so, you can use just 512 bytes in each segment, and have something like 8000 segments. Microport allocates physical memory in units of 512 bytes. As far as I can tell, you can even allocate segments 1, 23, and 7000. For languages such as Lisp, this can be quite handy.) Also, int's are 16 bits in C on the 286. This can be a portability problem since a lot of code these days is written for 32-bit machines. Note that the large model is potentially a portability problem. The small model is more or less just like a PDP-11 with separate I&D space. This is one of the classic machine that Unix supports, so lots of code will work that way. But the large model gives you 16 bit int's and 32 bit pointers. This is really an inconsistency. The language spec assumes implicitly that a pointer will fit into an int, and some existing C code relies on this. I've ported several C programs and so far I haven't run into any problems for this reason, but one could imagine programs that would work with the small model (which while limiting at least has self-consistent semantics), but not in the large model. I'm inclined to think there should be a compiler option that defines int as 32 bits, even though it would be slow. Unix buys you a number of things, including multiple processes and a clean separation between processes, kernel, devices, etc. But it can't create a silk purse from a sow's ear. And the 286 is a sow's ear. (It's still a lot better than the 8086 or 186, since the 286 adds protected mode.) The trade press is singing the praises of the 386 these days. Does anybody know if it is really true? If the 386 is a 286 extended to 32 bits, there is a potential problem. 680x0-based Unix systems all have MMU's. These typically break your address space up into pages, which the OS can put anywhere in memory that they like. If you want a large linear address space in the 386, do you have to make your whole program one big segment? If so, doesn't that mean it all has to be placed in physical memory in one big contiguous piece? Or are machines using external MMU's in addition to the 386's segment-mapping mechanism? (The problem with requiring a program to be in memory contiguously is that when programs ask for more memory you normally have to swap something out or reshuffle memory, which involves copying programs around in memory.)
clewis@spectrix.UUCP (Chris R. Lewis) (03/01/88)
In article <4022@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes: >I have noticed people posting in here talking about programming and using >various models. Is this for real? Unfortunately yes. But only on a 286. The 386 doesn't need this dreck in UNIX (386/ix, uPort). All pointers are 32 bits on 386 UNIX (unless you're running 286 UNIX on a 386 - then you get what you deserve). -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Phone: (416)-474-1955
kennedy@tolerant.UUCP (Bill Kennedy) (03/02/88)
In article <473@spectrix.UUCP> clewis@spectrix.UUCP (Chris R. Lewis) writes: >In article <4022@umn-cs.cs.umn.edu> randy@umn-cs.UUCP (Randy Orrison) writes: >>I have noticed people posting in here talking about programming and using >>various models. Is this for real? > >Unfortunately yes. But only on a 286. The 386 doesn't need this dreck >in UNIX (386/ix, uPort). All pointers are 32 bits on 386 UNIX (unless >you're running 286 UNIX on a 386 - then you get what you deserve). It's actually even worse than that. It seems that there are different file formats as well. I have V/AT DWB and went to V/386 and it doesn't work because V/AT DWB is in "STL" format which V/386 thinks means try to run it with Merge... So even though the binaries are allegedly transparent, there are at least some that won't work. The pain here is that a lot of stuff is either not yet available for the 386 or the 386 version is frightfully more expensive than its 286 kin. Further I have not seen a flood of stuff to take advantage of the 386 and the way it is implemented in V/386, nor anything to ease conversion from working Vr2 code to Vr3 (read as "anything that worries about signals"). So there's still good reason to stick with the 286 brain damage. If you grew up with it it's no worse than any other impediment. The above are my own opinions, I'm a contractor at Tolerant, they were nice enough to let me use their stuff so don't be mean and confuse them with me. Bill Kennedy ...{rutgers,cbosgd,ihnp4!petro}!ssbn!bill or bill@ssbn.WLK.COM
root@elric.UUCP (root) (03/04/88)
In article <1015@athos.rutgers.edu>, hedrick@athos.rutgers.edu (Charles Hedrick) writes: > The only way to get around the silly segments (as you put it) is to > get a machine that uses a decent chip. I haven't played with the 386, > so I can't comment on it, but the 286 isn't one. I have the uPort '386 system and it *does* have a single model cc.. Thank goodness -- I was getting ***Really*** tired of hacking and fighting with various combinations (or is it permutations? (:-)) of cc -options to get programs to compile on xenix (with a multi-model cc). I imagine that uPorts '286 compiler is the same way. -- Derek Terveer root@elric.UUCP ..!clyde!lily!elric!root