johnl@esegue.segue.boston.ma.us (John R. Levine) (01/05/90)
In article <1990Jan4.172835.2493@sj.ate.slb.com> poffen@sj.ate.slb.com (Russ Poffenberger) writes: >In the 386 architecture, you can partition the memory to look like a number >of independent '86 machines. It is called virtual '86 mode. By assigning >a chunk of memory (640K) in this virtual mode, you can run MSDOS in it >without it knowing that other operating systems are also running on the same >machine. Jeepers, get your facts straight. The 386 lets you put any user mode process into virtual 86 mode which makes that process execute 8086 instructions rather than 386 instructions. The DOS under Unix packages, VP/ix and DOS Merge use that mode but depend on the Unix operating system to do disk and terminal I/O. The DOS process is a user mode process subject to the same protection, preemption, and paging as any other Unix user process. Virtual 86 mode is very handy for running all the useful software that depends on DOS while really running Unix, but it critically depends on the operating system that is in charge. (We disregard here the DOS EMS managers that use V86 mode solely to get access to the page mapping tables, they hardly count.) It is in no sense a partitioning scheme. >>I really >don't think OS/2 and Unix would cooperate very well running at the >>same time. >Certainly a small amount of work might have to be done when it comes to >sharing peripherals, but it could be done. Virtual 86 mode gives you an 8086, not a 286, so you can't run OS/2 in a process. Furthermode, OS/2 and Unix both expect to control all of the memory management, segmentation, I/O addresses, devices, and interrupts, and a huge amount of surgery would be necessary to both to allow them to get out of each other's way. Don't hold your breath. I expect that what you will see is a Posix-compliant interface under OS/2-386, and OS/2 will evolve into yet another flavor of Unix, shortly after V.4 heals the 15 year schism between USG and Berkeley Unix. Just what we need. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl "Now, we are all jelly doughnuts."
johna@van-bc.UUCP (John Altstadt) (01/07/90)
+In article <1990Jan1.202916.13637@polyslo.CalPoly.EDU> tdrinkar@cosmos.acs.calpoly.edu.UUCP (Terrell Drinkard) writes: +>In article <1360@unocss..unl.edu> ho@fergvax.unl.edu writes: +>>From article <899@lzaz.ATT.COM>, by bds@lzaz.ATT.COM (Bruce Szablak): +>>Is this because of the processor chip itself, or an incompatible +>>platform? Are there actually 68000 instructions that don't work the +>>same on an 030, or is it just that the Mac {SE, II, SE/30} has a +>>different structure which is (usually) shielded from ("polite") +>>applications throught the System software? +> +>In a slightly different vein: the instruction sets for the 68010, +>68020, 68030, and even the 68040 all contain the instruction set of +>the 68000 as a subset. Each revision of the processor *added* more +>features. The only variation on this that I'm aware of is with the +>68030's MMU command set differs with the 68020 + 68851 (PMMU) +>instruction set by one or two commands (depending on which +>direction you are looking from). > Add to the incompatability list the fact that the various versions of 680xx stack different things at interrupts. Note however that for most code, even programs that contain interrupt handlers, this is a non sequitur. Only OS and debugger writers (in general) have to worry about such things. Regular interrupt handlers don't (in general) care about what they interrupted, so they don't have to worry about the order (and number) of things on the stack. About 2 years ago, somebody in some other newsgroup posted a short assembly language routine that would allow a program to determine what sort of 680xx it was running on (a self aware computer?). I might still have that article archived somewhere around here. If anybody is interested you can drop me a line. (Note that since the article was from 2 years ago, it only covered chips up to the 68020, but it shouldn't be hard to extend it.) Note: the above comments come from someone that lost track of the 680xx family after the release of the 68020, who also hated everything that intel produced until they released the 80386. Now I just program whatever is plopped down in front of me. I have no pride ;-)
johna@van-bc.UUCP (John Altstadt) (01/07/90)
Damn, I had a new .signature that was longer than 4 lines. For those that might want the info I mentioned in my last message, I hope that my new .signature follows... -- John Altstadt | USENET: !ubc-cs!van-bc!johna || !uunet!van-bc!johna 6135 Carson St. | INTERNET: johna@wimsey.bc.ca Burnaby, B.C. | CIS: 76066,1015 CANADA V5J 2Z8 | CIS@INTERNET: 76066.1015@compuserve.com