Exception vector oddity

News,announcements,programming,fixes,game patches & discussions.

Moderator: troed

roganjosh
Posts: 4
Joined: Fri Nov 23, 2018 7:35 pm

Exception vector oddity

Post by roganjosh » Fri Nov 23, 2018 8:37 pm

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
Posts: 90
Joined: Sun Jan 14, 2018 1:02 pm

Re: Exception vector oddity

Post by czietz » Fri Nov 23, 2018 9:19 pm

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
Posts: 4
Joined: Fri Nov 23, 2018 7:35 pm

Re: Exception vector oddity

Post by roganjosh » Sat Nov 24, 2018 7:19 am

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

Petari
Trusted Guru
Trusted Guru
Posts: 554
Joined: Tue Nov 28, 2017 1:32 pm

Re: Exception vector oddity

Post by Petari » Sat Nov 24, 2018 7:36 am

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" .
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

roganjosh
Posts: 4
Joined: Fri Nov 23, 2018 7:35 pm

Re: Exception vector oddity

Post by roganjosh » Sat Nov 24, 2018 8:36 am

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

ijor
Posts: 93
Joined: Fri Nov 30, 2018 8:45 pm

Re: Exception vector oddity

Post by ijor » Fri Nov 30, 2018 9:20 pm

roganjosh wrote:
Fri Nov 23, 2018 8:37 pm
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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

Petari
Trusted Guru
Trusted Guru
Posts: 554
Joined: Tue Nov 28, 2017 1:32 pm

Re: Exception vector oddity

Post by Petari » Sat Dec 01, 2018 9:19 am

ijor wrote:
Fri Nov 30, 2018 9:20 pm
...
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
	
	
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

ijor
Posts: 93
Joined: Fri Nov 30, 2018 8:45 pm

Re: Exception vector oddity

Post by ijor » Sat Dec 01, 2018 9:48 am

Petari wrote:
Sat Dec 01, 2018 9:19 am
ijor wrote:
Fri Nov 30, 2018 9:20 pm
...
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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

Petari
Trusted Guru
Trusted Guru
Posts: 554
Joined: Tue Nov 28, 2017 1:32 pm

Re: Exception vector oddity

Post by Petari » Sat Dec 01, 2018 9:58 am

You are right in latest post. But what matters is that reliable return is possible. Generic code ? That's relative :D
There are many cases where workaround gives best results.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

ijor
Posts: 93
Joined: Fri Nov 30, 2018 8:45 pm

Re: Exception vector oddity

Post by ijor » Sat Dec 01, 2018 12:56 pm

Sorry, can't reply to your PM. For some reason I am not allowed and seems my posts still need to be approved. I assumed that after 10 posts that would not be required anymore ???
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

Post Reply