Exception vector oddity

[roganjosh]

I'm putting the finishing touches to a version of FORTH. It's rather easy to generate bus and address errors in bugged FORTH so I'm currently writing the code to intercept the exceptions. I have the exception handling working but there is an oddity.

The M68K documentation I have states that exceptions leave the error-causing PC on the supervisor stack, followed by the SR. However, when I intercept the bus error vector (address $00000008) I see, within Devpac, that it puts out two extra longwords on the stack after it's stacked the SR/PC values. If I drop those two longs (addq.l #8,sp) then everything works as intended. The SR and PC values after the two longs are correct.

I'm puzzled as to what those extra longwords are for and whether the same thing will manifest itself with the address, illegal, division and privilege vectors. Hopefully someone here can lift the fog.

Sorry if this is a common question. I'm a newbie here. I've tried a few search terms without success.

[czietz]

The exception stack frame depends on the type of exception and the CPU in question (68000, 68010, 68020, ...).
See https://www.nxp.com/files-static/archiv ... 000PRM.pdf, section B.2 EXCEPTION STACK FRAMES, in particular Figure B-2. MC68000 Bus or Address Error Exception Stack Frame.

[roganjosh]

Thanks. Reassuring to know I didn't misread the manual. I'll see what the data sheets have to say.

[Petari]

MC68000 has generally 2 types of exception: Group 1 and 2 : On stack SR and Return address - 6 bytes . It is used by interrupts, Trap instruction, ....
Bus or address error exception frame: Access Address, Instruction Register, Then SR and Return Address (called program counter too) . That's 12 bytes .
For more detailed description look Motorola datasheets of MC68000. Really strange what you seen in that "M68K documentation" .

[roganjosh]

Thanks for that. I've now got the datasheets in front of me and they're very clear on the subject.

[ijor]

I'm putting the finishing touches to a version of FORTH. It's rather easy to generate bus and address errors in bugged FORTH so I'm currently writing the code to intercept the exceptions. I have the exception handling working but there is an oddity.

The M68K documentation I have states that exceptions leave the error-causing PC on the supervisor stack, followed by the SR. However, when I intercept the bus error vector (address $00000008) I see, within Devpac, that it puts out two extra longwords on the stack after it's stacked the SR/PC values. If I drop those two longs (addq.l #8,sp) then everything works as intended. The SR and PC values after the two longs are correct.

You can't reliably return from a bus or address error. The value of the PC pushed on the exception frame is not exact. This is also described on the 68000 manual.

[Petari]

...
You can't reliably return from a bus or address error. The value of the PC pushed on the exception frame is not exact. This is also described on the 68000 manual.

Sorry, but that's not correct. Me, as TOS expert, and who disassembled complete TOS 1.04 , 1.62 and 2.06 know that reliable return happens after every reset in ST, STE . Because TOS performs some HW detections which will generate bus error if some HW register/port is not present.
SW needs only to save current SSP (it must be done of course in supervisor mode) and to save proper exception vector - at address 8 for bus error, write there new, temporary value of own routine. Then, if port is present no bus error will happen. If no port, bus error will make it jump to test rutine part where can set some flag as test result (but may set inverse flag in part what executes if no bus error), may test more if need from larger stackframe (like what instruction was executed, what address was accessed), then will just write back org. SP and bus error values and can continue normally .

Example:

Code: Select all

	move.l	8.w,d3
	move.l	sp,d2
	move.l	#notMSTE,8.w

	tst.b	$FFFF8E09.w  * bus error if not MSTE - 

 * Here may perform some test result store, like setting flag what indicates that it is MSTE
 * like :
 
    st mstefl  * variable in SW workspace. Of course may set cookie too ...
* Above will be skipped if not MSTE 

notMSTE	move.l	d2,sp
	move.l	d3,8.w
	rts
	
	

[ijor]

...
You can't reliably return from a bus or address error. The value of the PC pushed on the exception frame is not exact. This is also described on the 68000 manual.

Sorry, but that's not correct. Me, as TOS expert, and who disassembled complete TOS 1.04 , 1.62 and 2.06 know that reliable return happens after every reset in ST, STE . Because TOS performs some HW detections which will generate bus error if some HW register/port is not present.

Yes, I know, but that is not a generic case. Actually it is not a "return" in the strict sense. TOS knows a bus error might happen in that case, and it saves enough information for the bus error exception to recover. Or the bus error vector is already the expected continuation code for this specific procedure. Either way, the PC on the exception frame is not used. The exception code does NOT perform a simple return from the exception to the PC pushed on the exception frame.

You can't do something like this with generic code.

[Petari]

You are right in latest post. But what matters is that reliable return is possible. Generic code ? That's relative
There are many cases where workaround gives best results.