bds@lzaz.ATT.COM (Bruce Szablak) (12/28/89)
In article <3368@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) writes: > I think anyone who looks at the two processor families objectively will > have to agree that the 68000 family is a better architecture. I agree. > On the other hand, this certainly doesn't mean that all software for > the 68k is great or that all software for the 80x86 is bad. More importantly, will my 68000 software run on a 68020, 68030, 68040 etc? Sometimes yes, sometimes no... The real significance of the Intel chips are that they are upwardly compatible. Anyone who got on the PC bandwagon in the beginning has the satisfaction of being able to use their tried and true software on faster and more powerful platforms. The consistancy with which each generation of Intel micros maintain compatiblity while improving over the previous generation has to instill a certain degree of confidence in the future.
bcw@rti.UUCP (Bruce Wright) (12/29/89)
In article <899@lzaz.ATT.COM>, bds@lzaz.ATT.COM (Bruce Szablak) writes: > More importantly, will my 68000 software run on a 68020, 68030, 68040 etc? > Sometimes yes, sometimes no... The real significance of the Intel chips are > that they are upwardly compatible. Anyone who got on the PC bandwagon in > the beginning has the satisfaction of being able to use their tried > and true software on faster and more powerful platforms. The consistancy > with which each generation of Intel micros maintain compatiblity while > improving over the previous generation has to instill a certain degree > of confidence in the future. The Intel family tends to be upward compatible, but there has certainly been some software broken over the years going from one processor to another. This was especially true back when the 8088/8086 was upgraded to the 80186 (mostly only seen on the Tandy 2000) and then to the 80286 (which IBM endorsed with its AT): many programs which stupidly relied on timing or processor curios (undocumented instructions which did some obscure but mildly useful operation) or which relied on some obscure results (like the contents of the word on the top of the SP when you do a PUSH SP) broke when they were run on the newer chips. Nowadays people have been sufficiently burned that they usually don't do such things. There have also been incompatibilities introduced by the BIOS and interrupt structure on the PC's but that's a different issue. In general I think this sort of thing tends to be more a question of intelligent software design (both in the operating system and in the applications software), not so much a question of different levels of the chip or the BIOS (though I admit there are exceptions). Bruce C. Wright
poffen@molehill (Russ Poffenberger) (12/30/89)
In article <899@lzaz.ATT.COM> bds@lzaz.ATT.COM (Bruce Szablak) writes: >In article <3368@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) writes: >> I think anyone who looks at the two processor families objectively will >> have to agree that the 68000 family is a better architecture. > >I agree. > I disagree. The 68k architecture WAS better than the pre-386 architecture, but the 386 and up architectures blow the 68k out of the water when it comes to memory management. With a '386, you can run multiple foriegn operating systems AT THE SAME TIME. We are NOT talking emulation, but TRUE multiple operating systems co-existing. That's how the Sun 386i does their DOS compatibility. Just assign a chunk of memory, and away you go. >> On the other hand, this certainly doesn't mean that all software for >> the 68k is great or that all software for the 80x86 is bad. > >More importantly, will my 68000 software run on a 68020, 68030, 68040 etc? >Sometimes yes, sometimes no... The real significance of the Intel chips are >that they are upwardly compatible. Anyone who got on the PC bandwagon in >the beginning has the satisfaction of being able to use their tried >and true software on faster and more powerful platforms. The consistancy >with which each generation of Intel micros maintain compatiblity while >improving over the previous generation has to instill a certain degree >of confidence in the future. I don't buy this either, the 68k family is supposed to be upward compatible, at least as far as the opcodes go. Both processors have their plusses and minuses. It's all a matter of opinion. No more flame wars please, lets get to serious computing issues. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
ho@fergvax.unl.edu (Tiny Bubbles...) (12/30/89)
From article <899@lzaz.ATT.COM>, by bds@lzaz.ATT.COM (Bruce Szablak): > In article <3368@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) writes: >> On the other hand, this certainly doesn't mean that all software for >> the 68k is great or that all software for the 80x86 is bad. > > More importantly, will my 68000 software run on a 68020, 68030, 68040 etc? > Sometimes yes, sometimes no... The real significance of the Intel chips are > that they are upwardly compatible. THIS IS NOT A FLAME. Ah, now that the disclaimer's out of the way... 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 through the System software? I don't know. I'm just asking. It does seem odd to create an incompatible chip. Makes me wonder what the marketing department at Motorola is up to. --- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu USnail: 115 Nebraska Union BITnet: cosx001@UNLCDC3 Lincoln, NE 68588-0461
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/30/89)
In article <1989Dec29.165724.12683@sj.ate.slb.com> poffen@sj.ate.slb.com (Russ Poffenberger) writes: | I don't buy this either, the 68k family is supposed to be upward compatible, at | least as far as the opcodes go. In fact, the 68000 is NOT completely compatible with the later revisions, not even the plug-in replacement, the 68010. Witness the "68010 patches" which are used in the Amiga world. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon
tdrinkar@cosmos.acs.calpoly.edu (Terrell Drinkard) (01/02/90)
In article <1360@unocss..unl.edu> ho@fergvax.unl.edu writes: >From article <899@lzaz.ATT.COM>, by bds@lzaz.ATT.COM (Bruce Szablak): >> More importantly, will my 68000 software run on a 68020, 68030, 68040 >> etc? Sometimes yes, sometimes no... The real significance of the >> Intel chips are that they are upwardly compatible. > The reason older Macs cannot run some of the newer Macintosh software is NOT that the new processor have different instruction sets, it is because of upgrades in the ROMs. The same thing happens with the PCs. Remember the original PC? Could you run EGA graphics on it? Could you even run a hard-drive on it? No. But, with appropriate upgrades in the BIOS, it is now possible to run all this stuff and more. The same thing happens to the Macintosh; new features become available and are used by various applications. And since these features are not supported in the older ROMs (the Mac's BIOS if you will) the older Macs can't run those applications. >THIS IS NOT A FLAME. Ah, now that the disclaimer's out of the way... > >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? > >I don't know. I'm just asking. It does seem odd to create an >incompatible chip. Makes me wonder what the marketing department at >Motorola is up to. 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). > ... Michael Ho, University of Nebraska >Internet: ho@hoss.unl.edu USnail: 115 Nebraska Union >BITnet: cosx001@UNLCDC3 Lincoln, NE 68588-0461 I would also point out a much more complete answer to the questions about how to do xxx on the Mac in an earlier message. I'd reproduce it here, but it's New Years Day, and I'm wanted back in bed soon. :-) Terry Disclaimer et la Signaturo: Hell no, I'm not responsible for what I say! If everyone were responsible for what they said, we'd have had a balanced budget in 1984.
boyne@hplvli.HP.COM (Art Boyne) (01/04/90)
bds@lzaz.ATT.COM (Bruce Szablak) writes: >More importantly, will my 68000 software run on a 68020, 68030, 68040 etc? >Sometimes yes, sometimes no... It should, with one *important* exception: exception handling. The length and contents of the stack frame created by an exception (bus/address errors, interrupts, traps, etc.) changed between the 68000 and the 68010. Any code that handles 68000-style exception stack frames has to be modified to run on a 68010 or later. This would mean that any code that handles raw interrupts will not run unchanged. Art Boyne, boyne@hplvla.hp.com
jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) (01/04/90)
In article <1989Dec29.165724.12683@sj.ate.slb.com> poffen@sj.ate.slb.com (Russ Poffenberger) writes: >AT THE SAME TIME. We are NOT talking emulation, but TRUE multiple operating >systems co-existing. That's how the Sun 386i does their DOS compatibility. Just >assign a chunk of memory, and away you go. I thought the 386i ran a version of VP/ix. Hardly what I would call an operating system. DOS doesn't use virtual memory. Your statement would possible be true for any OS constrained as DOS is. I really don't think OS/2 and Unix would cooperate very well running at the same time. Just what is better about the 386 memory management as opposed to the 030? Specific examples of registers etc would be useful. I disagree with your conclusion at this point. -- +-----------------------------------------------------------+ | Michael Lodman Mike.Lodman@SanDiego.NCR.COM | | NCR Corporation - Distributed Systems Lab - San Diego | | 9900 Old Grove Rd. San Diego, CA. 92131 (619) 693-5353 | +-----------------------------------------------------------+
malloy@nprdc.arpa (Sean Malloy) (01/04/90)
In article <199@tw-rnd.SanDiego.NCR.COM> jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) writes: >Just what is better about the 386 memory management as opposed to the 030? >Specific examples of registers etc would be useful. I disagree with your >conclusion at this point. The 'virtual 8086' mode comes to mind -- it allows you to isolate a process so that it can't step all over any other process's memory space. It also permits the process in that space to crash without taking the rest of the system with it. |Applications programming is a Sean Malloy |race between software engineers, Navy Personnel Research & Development Center |who strive to produce idiot-proof San Diego, CA 92152-6800 |programs, and the Universe, which malloy@nprdc.navy.mil |strives to produce bigger idiots. |So far, the Universe is winning.
poffen@molehill (Russ Poffenberger) (01/05/90)
In article <199@tw-rnd.SanDiego.NCR.COM> jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) writes: >In article <1989Dec29.165724.12683@sj.ate.slb.com> poffen@sj.ate.slb.com (Russ Poffenberger) writes: >>AT THE SAME TIME. We are NOT talking emulation, but TRUE multiple operating >>systems co-existing. That's how the Sun 386i does their DOS compatibility. Just >>assign a chunk of memory, and away you go. > >I thought the 386i ran a version of VP/ix. Hardly what I would call >an operating system. DOS doesn't use virtual memory. Your statement >would possible be true for any OS constrained as DOS is. I am not sure what the roots are for the OS for the Sun 386i, but it is pretty much Sunos which is based on BSD unix. 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. >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. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) (01/05/90)
In article <5305@skinner.nprdc.arpa> malloy@nprdc.arpa (Sean Malloy) writes: >In article <199@tw-rnd.SanDiego.NCR.COM> jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) writes: >The 'virtual 8086' mode comes to mind -- it allows you to isolate a >process so that it can't step all over any other process's memory >space. It also permits the process in that space to crash without >taking the rest of the system with it. This is a feature of most memory management schemes I have seen. In fact, this is one of the basic reasons for having memory management in the first place. No, sorry, this doesn't make the '386 memory management unique or better. -- +-----------------------------------------------------------+ | Michael Lodman Mike.Lodman@SanDiego.NCR.COM | | NCR Corporation - Distributed Systems Lab - San Diego | | 9900 Old Grove Rd. San Diego, CA. 92131 (619) 693-5353 | +-----------------------------------------------------------+
johnl@esegue.segue.boston.ma.us (John R. Levine) (01/06/90)
Virtual 86 mode is indeed pretty handy, not because it offers any unusual
memory protection, which it doesn't, but because it lets you virtualize a
real-mode 8086 in which one typically runs MS-DOS or anything else that runs
on a 8086 based PC. Each process can have a bit mask determining what I/O
addresses it can refer to, which makes it possible to allow a virtual 8086 or
any other process direct access to an I/O device without compromising the
security of other shared devices.
The 386 has a bunch of other unusual stuff inherited from the 286, some quite
handy, some totally useless. There is considerable task-switching stuff
built right in; it is reasonable to write an interrupt handler as a process
rather than a subroutine and little or no extra glue code is needed to make
it work. The segmentation scheme lets a fair amount of work normally handled
by the kernel be done directly, for example user programs can directly call
privileged routines without needing a kernel trap handler and dispatcher.
It is also possible for the kernel to grant limited task switching privileges
to user processes so that you can call another process with an address space
separate from yours to perform some service. Within a process you can have
"call gates" which are indirect pointers to routine addresses that can be
snapped at runtime, aiding the implementation of shared dynamically loaded
libraries. Unfortunately, all of this stuff is implemented as special
segments, so you need a programming language that supports segmented
addressing, which few 386 languages do.
--
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."wsinrn@lso.win.tue.nl (Rob J. Nauta) (01/13/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): >>> More importantly, will my 68000 software run on a 68020, 68030, 68040 >>> etc? Sometimes yes, sometimes no... The real significance of the >>> Intel chips are that they are upwardly compatible. >> 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? >>I don't know. I'm just asking. It does seem odd to create an >>incompatible chip. Makes me wonder what the marketing department at >>Motorola is up to. >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). Hmm, consider a BYTE column by Jerry pournelle where he described that his copy of the Amiga game Populous wouldn't work on his A2500, the solution was to boot with the left mouse depressed which forces the A2500 to boot with the 68000 instead of ther default 68020. Makes you wonder why Commodore plugged in an extra 68000... There is an undocumented instruction in the 68000 which isn't supported in later models, but which gets used extensively by machine language programmers because it's so convenient... Luckily compilers are smart enough not to generate this one... flame away, I'm ready ! :-)) Rob J. Nauta