move.w ccr,d0 on 68030

BlankVector · 03 February 2013, 22:53

Hello.

While doing tests with EmuTOS and Degas Elite on WinUAE, I noticed the following.

The instruction "move.w ccr,d0" called from user mode triggers a Privilege Violation exception on WinUAE with 68030 CPU. This is a bug, that instruction should be allowed. It works fine on WinUAE with 68040 and 68060.

It fails equally with WinUAE 2.5.1 and 2.6.0 Beta 6.

Toni Wilen · 04 February 2013, 17:40

I can't duplicate, opcode 42C0 (move ccr,d0) works fine here in 68030 config.

BlankVector · 04 February 2013, 18:01

I will make deeper tests.

Be sure that your OS does not emulate that instruction using a Privilege Violation handler. It is very common to catch both Privilege Violation and Illegal Instruction handlers to emulate the "move sr" or "move ccr" instructions which are not present on all processors.

Toni Wilen · 04 February 2013, 18:07

I traced it in visual studio, emulated cpu did run in user mode and I didn't see any exceptions being generated. Much more accurate results

Do you have "plain" 68030 or 68030 + more compatible or 68030 + cycle exact? (and if you didn't use "plain" 68030, does it work?)

BlankVector · 04 February 2013, 20:38

The problem appears only with 68030 + cycle exact.

Toni Wilen · 04 February 2013, 21:05

I still can't duplicate it, no difference in cycle-exact mode.

BlankVector · 04 February 2013, 21:14

Here is my configuration file.

Toni Wilen · 04 February 2013, 21:19

Still works. Are you sure it is opcode 42C0 that causes the problem? (Not something else getting confused?)

If you know the address of move ccr,d0 in advance, enter debugger (shift+f12), set breakpoint (f <addr>) and when it breaks, trace it manually (t), does it still cause exception?

BlankVector · 04 February 2013, 22:20

Many apologizes, my analysis was wrong since the beginning

This turns to be an issue about auto-modified code and cache management!

- The initial offending instruction is 40C0 "move sr,d0".
- It causes a Privilege Violation exception as expected.
- EmuTOS caches it, and transforms it in place to 42C0 "move ccr,d0"
- Then EmuTOS invalidates the instruction cache, but forgets to flush the data cache before.
- The exception routine terminates with RTE, and tries again the same instruction.
- The instruction is read from the memory. Since the data cache was not flushed, it is still the old 40C0 "move sr,d0" so it triggers a Privilege Violation exception again!
- Then the handler examines the offending instruction (through the data cache !!) and sees the modified "move ccr,d0"
- It does not find anything to emulate, so it jumps to the panic() routine to cleanly crash.

The WinUAE debugger is a masterpiece

It would have been very difficult to understand this bug without that.

Sorry to have wasted your time, Toni.

BlankVector · 05 February 2013, 00:20

BTW, isn't the 68030 data cache supposed to always work in write-through mode?
Isn't the above story a clue about a potential WinUAE data cache bug in 68030 + cycle exact mode?
I wonder how this behaves on real hardware...

Toni Wilen · 05 February 2013, 16:43

Yeah, it is broken, it is experimental, I have said 68030+ "cycle exact" should not be used

This time 68030 CE mode used 68020 instruction cache routines.

BlankVector · 05 February 2013, 16:46

Ok, no more mystery

I don't need any fix, this was just to hunt a potential bug.

03 February 2013, 22:53	#1
BlankVector Registered User Join Date: Jun 2012 Location: France Posts: 183	move.w ccr,d0 on 68030 Hello. While doing tests with EmuTOS and Degas Elite on WinUAE, I noticed the following. The instruction "move.w ccr,d0" called from user mode triggers a Privilege Violation exception on WinUAE with 68030 CPU. This is a bug, that instruction should be allowed. It works fine on WinUAE with 68040 and 68060. It fails equally with WinUAE 2.5.1 and 2.6.0 Beta 6.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Move it Move it... (68000)	Gilloo	Coders. Asm / Hardware	19	04 December 2011 17:36
Move Em	amigapd	request.Old Rare Games	1	13 March 2011 02:22
SPS link to move	Another World	HOL data problems	0	21 September 2008 21:43
Please delete or move if necessary	JSemple3	support.Games	7	30 June 2003 13:59

04 February 2013, 17:40	#2
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	I can't duplicate, opcode 42C0 (move ccr,d0) works fine here in 68030 config.

04 February 2013, 18:01	#3
BlankVector Registered User Join Date: Jun 2012 Location: France Posts: 183	I will make deeper tests. Be sure that your OS does not emulate that instruction using a Privilege Violation handler. It is very common to catch both Privilege Violation and Illegal Instruction handlers to emulate the "move sr" or "move ccr" instructions which are not present on all processors.

04 February 2013, 18:07	#4
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	I traced it in visual studio, emulated cpu did run in user mode and I didn't see any exceptions being generated. Much more accurate results Do you have "plain" 68030 or 68030 + more compatible or 68030 + cycle exact? (and if you didn't use "plain" 68030, does it work?)

04 February 2013, 20:38	#5
BlankVector Registered User Join Date: Jun 2012 Location: France Posts: 183	The problem appears only with 68030 + cycle exact.

04 February 2013, 21:05	#6
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	I still can't duplicate it, no difference in cycle-exact mode.

04 February 2013, 21:19	#8
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	Still works. Are you sure it is opcode 42C0 that causes the problem? (Not something else getting confused?) If you know the address of move ccr,d0 in advance, enter debugger (shift+f12), set breakpoint (f <addr>) and when it breaks, trace it manually (t), does it still cause exception?

04 February 2013, 22:20	#9
BlankVector Registered User Join Date: Jun 2012 Location: France Posts: 183	Many apologizes, my analysis was wrong since the beginning This turns to be an issue about auto-modified code and cache management! - The initial offending instruction is 40C0 "move sr,d0". - It causes a Privilege Violation exception as expected. - EmuTOS caches it, and transforms it in place to 42C0 "move ccr,d0" - Then EmuTOS invalidates the instruction cache, but forgets to flush the data cache before. - The exception routine terminates with RTE, and tries again the same instruction. - The instruction is read from the memory. Since the data cache was not flushed, it is still the old 40C0 "move sr,d0" so it triggers a Privilege Violation exception again! - Then the handler examines the offending instruction (through the data cache !!) and sees the modified "move ccr,d0" - It does not find anything to emulate, so it jumps to the panic() routine to cleanly crash. The WinUAE debugger is a masterpiece It would have been very difficult to understand this bug without that. Sorry to have wasted your time, Toni.

05 February 2013, 00:20	#10
BlankVector Registered User Join Date: Jun 2012 Location: France Posts: 183	BTW, isn't the 68030 data cache supposed to always work in write-through mode? Isn't the above story a clue about a potential WinUAE data cache bug in 68030 + cycle exact mode? I wonder how this behaves on real hardware...

05 February 2013, 16:43	#11
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,502	Yeah, it is broken, it is experimental, I have said 68030+ "cycle exact" should not be used This time 68030 CE mode used 68020 instruction cache routines.

05 February 2013, 16:46	#12
BlankVector Registered User Join Date: Jun 2012 Location: France Posts: 183	Ok, no more mystery I don't need any fix, this was just to hunt a potential bug.

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