jr@foros1.UUCP (John Rogers) (10/23/84)
Hi. I'm interested in how to detect the processor type (MC68000, MC68010, or whatever) in a user mode program (in assembler language, of course). I realize that I could execute one of the new instructions and see if I get trapped, but that doesn't sound too efficient (especially since I'm thinking about using this in some library subroutines). I don't have a MC68010 manual right now, so this might be an RTFM question; sorry if it is. Thanks in advance, as they say... Happy hacking! -- JR (John Rogers) ...ihnp4!fortune!foros1!jr also fortune!jr and proper!jr
gnu@sun.uucp (John Gilmore) (10/24/84)
I know of no way for user code to distinguish a 68000 from a 68008 or 68010 or 68012. This is deliberate, like on a 360 or 370, since it means you CAN'T write a program that won't transport from one to the other. Long long ago in a garage far away I made some Sun-1 boot proms that figured out the difference but they did it by causing a trap and seeing how long the stack frame was. Supervisor programs can do this to tell a 68000 from a 68010, but there's no way to tell a 68010 from a 68012, or a 68008 from a 68000. On the other hand, the 68020 offers a way to tell. It now decodes some bits in the index word that were ignored by previous models. So all you need to do is tell it to do something using those bits, and if it does it (eg scale the index reg) it's a 68020 and if it doesn't, it's a previous model. This is handy since there are lots of useful instructions you can use if you know it's a 68020. What would your library routine do differently if it knew it was on a 68000 versus 68010? There really isn't that much difference.
guy@rlgvax.UUCP (Guy Harris) (10/26/84)
> I know of no way for user code to distinguish a 68000 from a 68008 > or 68010 or 68012. This is deliberate, like on a 360 or 370, since > it means you CAN'T write a program that won't transport from one > to the other. Why won't trying to execute an RTD instruction separate the 68010s from the 68000/68008s? > What would your library routine do differently if it knew it was > on a 68000 versus 68010? There really isn't that much difference. I seem to remember some discussion a while ago on the fastest way to do a block move, which implied that the MOVE.L/DBcc pair was faster on the 68010, but not on the 68000. (Not that the library routine should burn up a goodly number of the cycles saved by trying to do an RTD and catching the illegal instruction trap...) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
geoff@desint.UUCP (Geoff Kuenning) (10/29/84)
In article <217@rlgvax.UUCP> guy@rlgvax.UUCP (Guy Harris) writes: >I seem to remember some discussion a while ago on the fastest way to do >a block move, which implied that the MOVE.L/DBcc pair was faster on the >68010, but not on the 68000. (Not that the library routine should burn >up a goodly number of the cycles saved by trying to do an RTD and catching >the illegal instruction trap...) Actually, on both the 68000 and the 68010 a series of MOVEM instructions beats a DBRA loop all hollow. This is because the MOVEM instruction makes use of the processor's instruction prefetch buffer to speed up the operation. (This is the reason the 68K makes one extra fetch at the end of a MOVEM into the registers, a source of chagrin to anyone who MOVEM's too close to the end of accessible memory!). -- Geoff Kuenning First Systems Corporation ...!ihnp4!trwrb!desint!geoff
gnu@sun.uucp (John Gilmore) (11/02/84)
> > I know of no way for user code to distinguish a 68000 from a 68008 > > or 68010 or 68012. > Why won't trying to execute an RTD instruction separate the 68010s from > the 68000/68008s? The trap caused by attempting RTD on a 68000 cannot be caught by *user* code. It takes cooperation from the supervisor. I believe that an unrolled move loop is faster than a one-instruction dbcc loop anyway, on all 68000 family chips. The one-instruction loop is just more convenient, e.g for a compiler to generate.