jk@apple.UUCP (John Kullmann) (12/15/87)
The third paragraph of section 8.4 (page 8-22) in a current 680x0 manual states, and I quote, "The system software should not depend on a particular exception generating a particular stack frame. For compatibility with future devices, the software should be able to handle any type of stack frame for any type of exception." HELLO?? WHAT THE HELL DOES THAT MEAN???? Seems just a bit "too" general for me. Isn't it a bit late in the game to publish such a general disclaimer on the part now??!?!! Does this mean I have to go back and rewrite all the exception handlers I've ever written for the 680x0 parts and turn them into psychic AI modules? How can I write an exception handler and NOT depend on what the exception stack frame looks like? Does this mean something to anyone? Am I on drugs? Or what?
jwhitnel@csi.UUCP (Jerry Whitnell) (12/17/87)
In article <7006@apple.UUCP> jk@apple.UUCP (John Kullmann) writes: ----- >HELLO?? WHAT THE HELL DOES THAT MEAN???? >Seems just a bit "too" general for me. Isn't it a bit late in the game >to publish such a general disclaimer on the part now??!?!! Somebody from Apple flaming about changing the rules in mid-game? A case of the pot calling the kettle black. Remember switcher? Please don't expect any sympathy (or any help) with an attitude like yours. > Does this mean >I have to go back and rewrite all the exception handlers I've ever >written for the 680x0 parts and turn them into psychic AI modules? >How can I write an exception handler and NOT depend on what the exception >stack frame looks like? > >Does this mean something to anyone? Am I on drugs? Or what? But in spite of your attitude I tell you what it means. All it means is that the exception frames vary between different members of the 680x0 family. Hence an exception handler may require a rewrite to work with a 68020. The 68000 and 68008 use the same stack frames, the 010 has a few changes and the 020 has a number of new frames. I believe the 030 has same set of frames as the 020. Jerry Whitnell Lizzi Borden took an axe Communication Solutions, Inc. And plunged it deep into the VAX; Don't you envy people who Do all the things You want to do?
mmengel@cuuxb.ATT.COM (Marc W. Mengel) (12/17/87)
In article <7006@apple.UUCP> jk@apple.UUCP (John Kullmann) writes: > "The system software should not depend on a particular > exception generating a particular stack frame. For compatibility > with future devices, the software should be able to handle > any type of stack frame for any type of exception." > >HELLO?? WHAT THE HELL DOES THAT MEAN???? >Seems just a bit "too" general for me. Isn't it a bit late in the game >to publish such a general disclaimer on the part now??!?!! Does this mean ... >Does this mean something to anyone? Am I on drugs? Or what? I think what they mean is that your interrupt routine should alwas accept any of the 4 or 5 standard interrupt frames by checking the type field in the frame to see which format it is -- i.e. if you get a illegal instruction fault, you *could* get any of the legal stack frames, and if you want to know which one you got you have to look at the type nybble in the stack frame. -- Marc Mengel attmail!mmengel ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmengel
jjg@walden.UUCP (John Grana) (12/17/87)
In article <7006@apple.UUCP> jk@apple.UUCP (John Kullmann) writes: >The third paragraph of section 8.4 (page 8-22) in a current 680x0 >manual states, and I quote, > > "The system software should not depend on a particular > exception generating a particular stack frame. For compatibility > with future devices, the software should be able to handle > any type of stack frame for any type of exception." > >HELLO?? WHAT THE HELL DOES THAT MEAN???? I think they are refering to the stack frame format field. This is the 4 bit field (bits 15-12) in the word SP+$06. This indicates the type of exception and length of the stack frame: Format Stack Length (bytes) ======== ====================== 00 8 01 8 02 12 09 20 $0a 32 $0b 92 >Seems just a bit "too" general for me. Isn't it a bit late in the game >to publish such a general disclaimer on the part now??!?!! Does this mean >I have to go back and rewrite all the exception handlers I've ever >written for the 680x0 parts and turn them into psychic AI modules? I'm not sure if I agree in total. Yes, they did "sneak" it in when Mot brought out the 68010. This did cause problems when running 68000 code on a 680[12]0, but at least they added the "Vector Offset" field. Thus, from the 68010 on (68020 and 030), one exception handler could tell the type of exception (via the Vector Offset field and length of the stack frame). Seems like a pretty good idea! On the other hand, I must agree that it was "published" a little late! I thought Motorola warned about this in the 68010 manual? >How can I write an exception handler and NOT depend on what the exception >stack frame looks like? > Again, based on the information IN the stack frame, one handler could be written. (i.e. the Vector Offset/4 = the exception number and the format field tells the size of the frame. Thus the one handler can "invoke" the correct routine to handle the exception.) What it boils down to is don't assume that format 0 and 1 are always trap #n or interrupt or illegal etc. Use the info in the frame to handle the exception. john grana