The Sinclair QL Forum

EDIT: Corrected typo in first draft! See Tobias' comment below.

I'm looking at some QLMultiMOn code from GitHub (Hi Jan) , it's in assembly, and handles exceptions. Always a bugbear of mine!


Most exceptions stack the following data on the SUPERVISOR SP, or A7 in the exception handler:

2(A7) = PC value that caused the exception.
0(A7) = Status Register value at exception time.

That's three words in total on the SSP.

There are a couple of exceptions in the QL that stack 4 extra words of information, BUS and ADDRESS. RESET is similar, but is ignored. These extra words give the stack the following appearance:

10(A7) = PC value that caused the exception.
8(A7) = Status Register value at exception time.
6(A7) = First word of instruction that barfed.
2(A7) = Address that was accessed to cause the exception.
0(A7) = Access type/Function code word.

Pennell on page 91, shows that the Address that was accessed and caused the exception is at 4(A7) when all my other books are 2(A7) as I have listed above, also, Pennell states that $0C(A7) is the PC value that caused the exception, and not $0A(A7) (or 10(A7)) as per my other books, and the above. Can someone please confirm that I am correct.


Cheers,
Norm.

NormanDunbar wrote: Most exceptions stack the following data on the SUPERVISOR SP, or A7 in the exception handler:

4(A7) = PC value that caused the exception.
0(A7) = Status Register value at exception time.

That's three words in total on the SSP.

Last sentence is correct, but doesn't fit your layout: address for PC should be 2(a7), the status register is only two bytes.

NormanDunbar wrote: There are a couple of exceptions in the QL that stack 4 extra words of information, BUS and ADDRESS. RESET is similar, but is ignored. These extra words give the stack the following appearance:

10(A7) = PC value that caused the exception.
8(A7) = Status Register value at exception time.
6(A7) = First word of instruction that barfed.
2(A7) = Address that was accessed to cause the exception.
0(A7) = Access type/Function code word.

Pennell on page 91, shows that the Address that was accessed and caused the exception is at 4(A7) when all my other books are 2(A7) as I have listed above, also, Pennell states that $0C(A7) is the PC value that caused the exception, and not $0A(A7) (or 10(A7)) as per my other books, and the above. Can someone please confirm that I am correct.

The Motorola MC68000 programming manual is with you (and not Mr Pennell) on that.

A comment on the PC value on the stack: That is only a hint, and simply says "we were somewhere there when we crashed" - It can easily be 2-10 bytes off, depending on the instruction.

Tobias

Thanks Tobias. I've corrected my own typo on the first post. It seems I can't write down what I'm thinking!

A comment on the PC value on the stack: That is only a hint, and simply says "we were somewhere there when we crashed" - It can easily be 2-10 bytes off, depending on the instruction.

My books mention this for the BUS Error only. It appears that a BUS error can happen at any point during the execution of a long instruction. One of them also says that:

Although the 68000 cannot itself return from a Group 0 exception, you can write an exception handler to use the information on the stack to create a new stack frame from which a return can be made. This procedure is not recommended. If you want to implement a return from Group 0 exception, you should use a 68020 or later processor.

which seems a tad harsh! The book in question is Alan Clements - 68000 Family Assembly Language (https://www.amazon.co.uk/Assembly-Langu ... ef=sr_1_16).

I have updated my copy/ies of Pennell. Thanks.


Cheers,
Norm.