gnu@hoptoad.uucp (John Gilmore) (08/04/86)
In article <259@cci632.UUCP>, rb@cci632.UUCP (Rex Ballard) writes: > ...did you > fix the perverse usage of the high address bits so that a 68010 or 68020 > could be used in place of the 68000? This is a red herring. First, a 68010 has the same address space as a 68000. Second, a 68020 just feeds those bits out on pins; if you have less than 16 megs of stuff to address, you're free to ignore the pins. Third, if what they are doing is putting the vector number in the high byte of the interrupt vector address, this is no problem. They will have to rewrite the interrupt vector code in a minor way for the 68010/20 anyway; in fact, their trick lets them use the same assumptions (e.g. that multiple interrupt vectors can point to the same routine, but the routine can tell which interrupt actually happened) in the 68000 as well as in the later models. I wish I'd thought of it! It's not hard to write code that figures out which CPU it's on and copes with the stack frame differences. I wrote that code when I first got a sample 68010. The system can, at boot time, cause a software trap and look at the size of the resulting stack frame (6 bytes on 68000, 8 on 68010/20). That test can set a flag that anybody who cares can check. The test for 68020 is even easier; user programs can do it. Use an instruction that does scaled indexing. The scaling bits are ignored on 68000/68010 and used on 68020. (I used "moveq #4,d0" followed by "jmp pc@(4,d0*2)", which either jumps to pc+8 or pc+12. You can adjust the constant to suit.) For example, you could stick a 2-instruction test on the front of a multiply routine that, if run on a 68020, would jump to a 32-bit multiply instruction but on the older models would do it the hard way. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!