Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!van-bc!johna From: johna@van-bc.UUCP (John Altstadt) Newsgroups: comp.sys.ibm.pc Subject: Re: processor wars. Message-ID: <145@van-bc.UUCP> Date: 7 Jan 90 05:06:14 GMT References: <899@lzaz.ATT.COM> <1360@unocss..unl.edu> <1990Jan1.202916.13637@polyslo.CalPoly.EDU> Reply-To: johna@van-bc.UUCP (John Altstadt) Organization: Wimsey Associates Lines: 37 +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 ;-)