ford@elgar.UUCP (Mike "Ford" Ditto) (06/11/88)
Speaking of 68020/881 emulation, has anyone ever implemented a complete 68020-instruction emulation on the 68010? The reason I ask is that I encountered a surprising inconsistency in the handling of illegal opcodes on the 68010. I compiled some C code using GNU CC with the 68020/68881 option on, and ran the executable on an AT&T Unix PC (68010). Most of the 68020/881 instructions resulted in the expected result (illegal instruction in the case of new 020 ops, f-line emulator trap for 881 instructions). These resulted in SIGILL (illegal instruction) and SIGEMT (emulator trap) exceptions under Unix. What doesn't seem right is what happened for an instruction that used the new scaled index 68020 addressing mode. The opcode looks almost the same, except where there were required zeroes on the 68010, the 68020 has two bits to specify a scale amount for the index register. When I ran this opcode (with a scale value of 4, incompatible with the 68010) on the 68010, the result was a *bus error*. Now, all I know is that Unix sent the process a SIGBUS (bus error), so I don't know for sure what the 68010 exception number was. But I don't think Unix would have any reason to turn an illegal instruction exception into a SIGBUS. Is it possible that the 010 gives a bus error for some illegal opcodes? I do remember reading in the 68000 spec that ALL unimplemented opcodes are supposed to give an illegal instruction exception or an emulator trap exception. Does anyone know whether the 68010 is consistent in reporting illegal instructions? If not, it would seem difficult to emulate the 020 instruction set (having to check bus errors for illegal addressing modes would be pretty bogus). -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads
chrisj@cup.portal.com (06/12/88)
In Message-ID: <182@elgar.UUCP>, ford@elgar.UUCP (Mike "Ford" Ditto) writes: >Speaking of 68020/881 emulation, has anyone ever implemented a >complete 68020-instruction emulation on the 68010? The reason I ask >is that I encountered a surprising inconsistency in the handling of >illegal opcodes on the 68010. [a paragraph about stuff that worked ok deleted] >What doesn't seem right is what happened for an instruction that used >the new scaled index 68020 addressing mode. The opcode looks almost >the same, except where there were required zeroes on the 68010, the >68020 has two bits to specify a scale amount for the index register. >When I ran this opcode (with a scale value of 4, incompatible with the >68010) on the 68010, the result was a *bus error*. As indicated in appendix D, pp D-6,D-7 of the 68020 User's Manual, all members of the 68000 family fully decode the opcode word, and generate an illegal opcode exception when appropriate. However, earlier members of the family DO NOT necessarily validate the contents of unused fields in extension words, especially those required for indexed addressing. You will not necessarily get stopped if "should-be-zero" bits aren't: instead they may be treated as zeroes. The opcode IS legal, it's the extension word which is bad. For example, suppose that the compiler generated ADD.L disp16(A6,D7.L*4),D6 for the 68020. The index word will be D/A RRR W/L Scale brief/full BS IS BDSize 0 I/IS 0 111 1 10 1 0 0 10 0 000 The 68010 will ignore the scale and brief/full bits, treat the right 8 bits as a displacement of 32 (decimal), and use the index register contents without scaling. Assuming that A6 contains an even address, there are two cases, depending on whether D7 is even or odd. If it is even, you will fetch the wrong word, add it to D6, and then the 68010 will treat the displacement word as the opcode of the next instruction. Depending on exactly what the displacement happens to be, anything can happen (including an illegal opcode trap). If D7 is odd, then the source address will also be odd, so the instruction will trap out with an address error, and the processor will never get to misinterpret that displacement word as an opcode. For other 68020-030 addressing modes which look like plain indexed modes to the 68010, even stranger things may happen. For example, with some of the memory-indirect modes, the rightmost 8 bits of the extension word may look to the 68010 like an odd displacement. The bottom line is that the 68K product line IS generally UPWARD compatible (except for the MOVE SR,xxx vs MOVE CCR,xxx mistake and the differences in the formats of exception frames), but is downward compatible ONLY w.r.t. opcode words, NOT extension words. That means that there is NO guarantee that you can simulate 68020 execution on a 68010; in the general case you cannot do so. There are good reasons why the 68020 manual suggests that a program which contains 68020-only object code start with the trap-if-false instruction, which is a no-op to the 68020 but illegal on the earlier members of the family. It can save you some time trying to debug a problem if you mistakenly run a 68020 program on a 680xx for xx < 20. And of course, a word or long reference on an odd address is legal on the 68020, but illegal on the 68010: if you wanted to simulate a 68020 on a 68010, you'd have to simulate every odd word or long reference. Since you cannot do the emulation anyway, I guess that doesn't matter. Christopher Jewell chrisj@cup.portal.com sun!cup.portal.com!chrisj "In the country of the blind, the one-eyed man is, as we all know, king. And across the way, in the country of the witless, the half-wit is king." _The_Graves_of_Academe_ by Richard Mitchell
alan@pdn.UUCP (Alan Lovejoy) (06/13/88)
In article <182@elgar.UUCP> ford@kenobi.UUCP (Mike "Ford" Ditto) writes: >What doesn't seem right is what happened for an instruction that used >the new scaled index 68020 addressing mode. The opcode looks almost >the same, except where there were required zeroes on the 68010, the >68020 has two bits to specify a scale amount for the index register. >When I ran this opcode (with a scale value of 4, incompatible with the >68010) on the 68010, the result was a *bus error*. The 68010 was not implemented to detect scaled index addressing as an unimplemented instruction exception. The bus error you got was probably just that (due to virtual to physical address translation of a bogus logical address). Motorola fucked this up royally. One of their rare lapses, so I guess we shouldn't complain too loudly. A little light ribbing may be in order. Howerver, there is the mc68012, which if I remember correctly is completely software compatible with the 68020 but pin-compatible with the 68010. But my memory is rather vague on this part. Perhaps someone else has more authoritative info? -- Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida. Disclaimer: Do not confuse my views with the official views of Paradyne Corporation (regardless of how confusing those views may be). Motto: Never put off to run-time what you can do at compile-time!
kim@mcrware.UUCP (Kim Kempf) (06/13/88)
In article <182@elgar.UUCP>, ford@elgar.UUCP (Mike "Ford" Ditto) writes: > Does anyone know whether the 68010 is consistent in reporting illegal > instructions? If not, it would seem difficult to emulate the 020 > instruction set (having to check bus errors for illegal addressing > modes would be pretty bogus). > The 68020 manual from Motorola points out the fact that while the 68010 does indeed fully decode all 65536 possible opcodes, it does not fully decode the addressing mode modifier word. They give numerous examples of how a 68010 can totally botch 68020 instructions until it runs an illegal opcode. ---------------- Kim Kempf, Microware Systems Corporation ...!sun!mcrware!kim
daveh@cbmvax.UUCP (Dave Haynie) (06/14/88)
in article <3447@pdn.UUCP>, alan@pdn.UUCP (Alan Lovejoy) says: > > Howerver, there is the mc68012, which if I remember correctly is > completely software compatible with the 68020 but pin-compatible with > the 68010. But my memory is rather vague on this part. Perhaps someone > else has more authoritative info? The fact that the 68012 and 68010 are in the same Technical Note was my first clue. The 68012 is basically a 68010 in a larger package. It brings out a few more pins, like an extra address line or two, and I think the '020 style RMC pin, but it doesn't do any 68020 style op-codes. The other thing to consider with all this backward compatibility talk would be how much '020 software do you really have available. If there's lots, maybe a '020 in a 68000 compatible package of some kind would be nice, and it would also be a nice way to support math in a 68000 based system. The 68020 at the same speed would run slower than the 68000 on a 16 bit bus, though, for many operations. All that 32 bit prefetching. So if you're running 68000 code with no floating point, a plain 68020 drop in will often hurt your performance and give you little in return (ok, it does get something back on tight loops if your OS lets you run with the cache on). > Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
adh@anumb.UUCP (a.d.hay) (06/14/88)
In article <3447@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: [ deletions ] >Howerver, there is the mc68012, which if I remember correctly is >completely software compatible with the 68020 but pin-compatible with >the 68010. But my memory is rather vague on this part. Perhaps someone >else has more authoritative info? the other way around! the 68012 is a 68010 chip in a package with more leads (i don't know how it compares to the 68020) so more address lines are brought out. it has no software enhancements over the 68010. -- Andrew Hay +------------------------------------------------------+ Lunatic By Birth | "Don`t try to out-wierd ME, three-eyes!" | AT&T-BL Ward Hill MA | I can't be bought, but I can be had... | ihnp4!mvuxq!adh +------------------------------------------------------+
nerd@percival.UUCP (Michael Galassi) (06/15/88)
In article <3447@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: [ommited other points on which I have no comments and which do not realy pertain to the mc68012] >Howerver, there is the mc68012, which if I remember correctly is >completely software compatible with the 68020 but pin-compatible with >the 68010. But my memory is rather vague on this part. Perhaps someone >else has more authoritative info? In software the mc68012 is almost identical to the mc68010, the diferences occur in hardware, the 012 has aditional address pins a25-a29 and a31, additionaly there are a couple of additional ground pins to support the additional current sink from the wider address bus, and there is a RMC\ pin which is active during a read/write/modify cycle intended for buss locking purposes (semaphore updating etc...). This info is gleamed from "mc68010/mc68012 16-/32-bit virtual memory microprocessors" printed by Motorola in May, '85, this document is labeled as "Advance Information" so may be inacurate or incomplete. Personaly I have never seen the 012 and do not recal even reading of any products using it. Maybe the 012 never made it out of sample phase? I also checked the fourth edition of the MC68000's programmer's ref. manual which also covers the 010 and 008 but found no reference to the 012 (not even mention that it is/isn't identical to some other part). I may very well be wrong in some or all of what I say, if this is the case I would apreciate someone correcting me. Spelling errors along with any other errors are my own. -michael -- Michael Galassi | If my opinions happen to be the same as ...!tektronix!tessi!percival!nerd | my employer's it is ONLY a coincidence, ...!uunet!littlei!percival!nerd | of course coincidences DO happen.
allen@ccicpg.UUCP (Allen Brumm) (06/16/88)
In article <182@elgar.UUCP> ford@kenobi.UUCP (Mike "Ford" Ditto) writes: >What doesn't seem right is what happened for an instruction that used >the new scaled index 68020 addressing mode. The opcode looks almost >the same, except where there were required zeroes on the 68010, the >68020 has two bits to specify a scale amount for the index register. >When I ran this opcode (with a scale value of 4, incompatible with the >68010) on the 68010, the result was a *bus error*. > >Now, all I know is that Unix sent the process a SIGBUS (bus error), so >I don't know for sure what the 68010 exception number was. But I >don't think Unix would have any reason to turn an illegal instruction >exception into a SIGBUS. Is it possible that the 010 gives a bus >error for some illegal opcodes? I do remember reading in the 68000 >spec that ALL unimplemented opcodes are supposed to give an illegal >instruction exception or an emulator trap exception. > >Does anyone know whether the 68010 is consistent in reporting illegal >instructions? If not, it would seem difficult to emulate the 020 >instruction set (having to check bus errors for illegal addressing >modes would be pretty bogus). > I suggest that anyone attempting to emulate 68020 opcodes on a 68010 or lesser processor carefully read Appendix D of "MC68020 32-Bit Microprocessor User's Manual", Second Edition. In particular, Section D.3 Extension Words. All 680x0 processors fully decode all 65,536 operation words, so if an opcode for a newer member of the 680x0 family is executed on an earlier processor it will be "trapped out." Only the first word of an instruction is checked for legality by the processor, any extension words of the instruction are NOT checked. I would suspect that you are getting a legitimate bus error due to an address calculation gone astray from the use of an extension word. In summary, you can emulate the new opcodes, but you can't always emulate new addressing modes since you are not notified of there use. However, you could probably write an object code translator to do it for you! Allen Brumm ccicpg!allen
rroot@edm.UUCP (Stephen Samuel) (06/17/88)
From article <4015@cbmvax.UUCP>, by daveh@cbmvax.UUCP (Dave Haynie): > it would also be a nice way to support math in a 68000 based system. The > 68020 at the same speed would run slower than the 68000 on a 16 bit bus, > though, for many operations. All that 32 bit prefetching. So if you're > running 68000 code with no floating point, a plain 68020 drop in will > often hurt your performance and give you little in return (ok, it does > get something back on tight loops if your OS lets you run with the cache > on). My understanding (last thing I heard) was that the '20 runs about 50% faster with 16 bit mem than a 68000. This makes some sense.. Although the '20 tends to prefetch in 32 bit blocks, this doesn't really cause a big hit, in most cases, since you get it back on the next instruction (I assume you get at least THAT much even with the cache disabled). The time you'll get a REAL performance hit is when you have a program that consists primarily of short (8 bit) branches all over the place with no real work done anyways. -- ------------- Stephen Samuel Disclaimer: You betcha! {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve BITNET: USERZXCV@UQV-MTS
ford@elgar.UUCP (Mike "Ford" Ditto) (06/17/88)
In article <6443@cup.portal.com> chrisj@cup.portal.com writes: >In Message-ID: <182@elgar.UUCP>, ford@elgar.UUCP (Mike "Ford" Ditto) writes: > >>Speaking of 68020/881 emulation, has anyone ever implemented a >>complete 68020-instruction emulation on the 68010? The reason I ask >>is that I encountered a surprising inconsistency in the handling of >>illegal opcodes on the 68010. > >As indicated in appendix D, pp D-6,D-7 of the 68020 User's Manual, all >members of the 68000 family fully decode the opcode word, and generate >an illegal opcode exception when appropriate. However, earlier members >of the family DO NOT necessarily validate the contents of unused fields >in extension words, especially those required for indexed addressing. Well, I'm disappointed; shame on Motorola! But thanks, Chris, for pointing out the fine print. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford@kenobi.cts.com This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads At least one of the programmers of the news software was a total idiot at the time. I wonder if he still is? Look at all this wasted space.
ford@elgar.UUCP (Mike "Ford" Ditto) (06/17/88)
In article <3447@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: >Howerver, there is the mc68012, which if I remember correctly is >completely software compatible with the 68020 but pin-compatible with >the 68010. But my memory is rather vague on this part. Perhaps someone >else has more authoritative info? I'm pretty sure the 68012 is identical to the 010 other than having the different case style which allows the 7 additional address lines (and the RMC line) to be brought off the chip. It mignt even be the same chip inside the package. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford@kenobi.cts.com This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads
michael@mcdchg.UUCP (Michael Bodine) (06/20/88)
Michael Galassi (nerd@percival.UUCP) writes: > This info is gleamed from "mc68010/mc68012 16-/32-bit virtual memory > microprocessors" printed by Motorola in May, '85, this document is > labeled as "Advance Information" so may be inacurate or incomplete. Motorola only changes the "Advance Information" part of a data sheet when it gets reprinted *AND* there are functional changes to the document. Your info re: 012 is accurate. > Personaly I have never seen the 012 and do not recal even reading > of any products using it. Maybe the 012 never made it out of sample > phase? The 012 was essentially a special product for a particularly large company who was interested in a) making the 68000 family fit into the I/O type instructions of intel, thus the A0-A29 + A31 pin-out -- the A31 was used to distinguish memory accesses from i/o accesses and b) putting the 68000 into a virtual, multi-processor environment, thus the 68010 to give the virtual part, and the RMC pin to inform the complementary part of the forthcoming indivisible cycle. The 012 is indeed being used for its intended purpose but in very small quantities. No doubt due to these tiny quantities, it's no longer listed in the Motorola Semiconductor price book; I would suspect that today's 12 MHZ 68020 is about on a par cost with what the 68012 would cost. Unless you're already locked into using the 012, the 020 is the right part to use. -- [ Michael Bodine, michael@mcdchg.UUCP Opinions expressed are mine and haven't ] [ been seen, commented on or in any way approved or even allowed by Motorola ] [ MicroComputer Division, Motorola General Systems Group or Motorola, Inc. ] [ No one else agrees with me; why should my employer? ]
daveh@cbmvax.UUCP (Dave Haynie) (06/21/88)
in article <3142@edm.UUCP>, rroot@edm.UUCP (Stephen Samuel) says: > > From article <4015@cbmvax.UUCP>, by daveh@cbmvax.UUCP (Dave Haynie): >> The 68020 at the same speed would run slower than the 68000 on a 16 bit bus, >> though, for many operations. All that 32 bit prefetching. > My understanding (last thing I heard) was that the '20 runs about 50% > faster with 16 bit mem than a 68000. I've never seen any statictics on it, or seen any predictions made by Motorola. I have, however, actually used 68020s running only 16 bit memory in Amiga systems. And with the cache off, they do run slower. Somewhere around 20% slower overall; I didn't really try to find out what was causing the slowness, as I had no intention to ever really use the system with the cache off. Or without 32 bit wide memory, either. But I was interested in seeing the effects of 32 bit over 16 bit memory, and it does make a difference. The '020 slowdown was initially a surprise, but since then, in learning more about the '020 and seeing other systems behave similarly, I'm comfortable with it. > Although the '20 tends to prefetch in 32 bit blocks, this doesn't really > cause a big hit, in most cases, since you get it back on the next instruction > (I assume you get at least THAT much even with the cache disabled). I think if the cache is off, unused prefetched stuff is just thrown out. With the cache on, I see maybe an overall 20% increase in speed. With 32 bit memory in this system (14.3MHz vs. 7.2MHz) I see maybe a 300% total increase in most operations (there's still some 16 bit memory that has to be used by the OS). > The time you'll get a REAL performance hit is when you have a program that > consists primarily of short (8 bit) branches all over the place with > no real work done anyways. That's one of 'em, anyway. > Stephen Samuel Disclaimer: You betcha! > {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve > BITNET: USERZXCV@UQV-MTS -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
jeff@wdl1.UUCP (Jonathan J. Jefferies) (06/24/88)
/ wdl1:comp.sys.m68k / michael@mcdchg.UUCP (Michael Bodine) / 8:30 am Jun 20, 1988 / The 012 was essentially a special product for a particularly large company who was interested in a) making the 68000 family fit into the I/O type instructions of intel, thus the A0-A29 + A31 pin-out -- the A31 was used to distinguish memory accesses from i/o accesses and b) putting the 68000 into a virtual, multi-processor environment, thus the 68010 to give the virtual part, and the RMC pin to inform the complementary part of the forthcoming indivisible cycle. -- [ Michael Bodine, michael@mcdchg.UUCP Opinions expressed are mine and haven't ] [ been seen, commented on or in any way approved or even allowed by Motorola ] [ MicroComputer Division, Motorola General Systems Group or Motorola, Inc. ] [ No one else agrees with me; why should my employer? ] ---------- Michael: I have a multi-bus cpu card built by Callan - an early rival of sun that uses the 68012 and I am trying to figure it out. I would appreciate any additional light that you can shed on the product, i.e. any other ways it may differ from the standard 68010. By the way can you say who the large company was and do they still use the 68012. At this point I don't even know if the card/chip is still alive. It was sent to me by a fellow on the east coast for entertainment value. Mine? trying to make it work or his? enjoying my frustration. Anyways would appreciate any info's. jeff@wdl1