bsr.l on 68000 doesn't crash

StingRay · 22 September 2012, 08:00

I have recently fixed a bug in Hoffman's 8-Bit Jungle music disk (see thread here on EAB) which was caused by using bsr.l which is a 020+ instruction. WinUAE allows this instruction on 68000 though, i.e. the demo worked fine in the emulator but (of course) crashed on a real A500. Would be nice to have this fixed.

Toni Wilen · 22 September 2012, 12:11

Seems to have been always wrong.. BCC.L at least works correctly. Will be fixed.

BSR.L (and BCC.L) are annoying because they are also valid 68000 instructions.

StingRay · 22 September 2012, 12:25

Only 16 bit branch distance allowed on 68000, the .L versions are only valid on 020.

Toni Wilen · 22 September 2012, 14:14

Yes, but check opcode decoding of BSR.L and BCC.L

BSR.L or BCC.L won't cause illegal instruction exception but address exception because of above reason.

StingRay · 22 September 2012, 14:32

Ah, that you mean, if I remember correctly, the .l versions just have $ff as 2nd byte whereas the "normal" .w versions have $00 there. But yes, I understand what you mean with "annoying".

Toni Wilen · 22 September 2012, 21:43

I was fixing emulation and noticed that JSR and BSR also have interesting difference (at least on 68000).

JSR address error stack frame PC field contain address of JSR opcode and fault address contains new odd PC, as documented.

Both BSR (both .b and .w) address error stack frame PC and fault address field contain new PC (odd) value. EDIT: Which means RTE from this kind of address error isn't going to work..

22 September 2012, 08:00	#1
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,865	bsr.l on 68000 doesn't crash I have recently fixed a bug in Hoffman's 8-Bit Jungle music disk (see thread here on EAB) which was caused by using bsr.l which is a 020+ instruction. WinUAE allows this instruction on 68000 though, i.e. the demo worked fine in the emulator but (of course) crashed on a real A500. Would be nice to have this fixed.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Crash with custom ROM on 68000	UAE	support.WinUAE	5	10 July 2012 09:04
Undefined symbol bsr.b init_bitmaps	VoltureX	Coders. General	12	13 November 2011 16:11
clr.b -(SP) followed by bsr...	Photon	Coders. General	19	18 January 2011 22:42
68040 MMU jsr/bsr	Toni Wilen	Coders. General	5	28 April 2010 20:57
quitting on 68000?	Hungry Horace	project.WHDLoad	60	19 December 2006 20:17

22 September 2012, 12:11	#2
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	Seems to have been always wrong.. BCC.L at least works correctly. Will be fixed. BSR.L (and BCC.L) are annoying because they are also valid 68000 instructions.

22 September 2012, 12:25	#3
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,865	Only 16 bit branch distance allowed on 68000, the .L versions are only valid on 020.

22 September 2012, 14:14	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	Yes, but check opcode decoding of BSR.L and BCC.L BSR.L or BCC.L won't cause illegal instruction exception but address exception because of above reason.

22 September 2012, 14:32	#5
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,865	Ah, that you mean, if I remember correctly, the .l versions just have $ff as 2nd byte whereas the "normal" .w versions have $00 there. But yes, I understand what you mean with "annoying".

22 September 2012, 21:43	#6
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	I was fixing emulation and noticed that JSR and BSR also have interesting difference (at least on 68000). JSR address error stack frame PC field contain address of JSR opcode and fault address contains new odd PC, as documented. Both BSR (both .b and .w) address error stack frame PC and fault address field contain new PC (odd) value. EDIT: Which means RTE from this kind of address error isn't going to work..

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)