English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 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.
BlankVector is offline  
Old 04 February 2013, 17:40   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,744
I can't duplicate, opcode 42C0 (move ccr,d0) works fine here in 68030 config.
Toni Wilen is offline  
Old 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.
BlankVector is offline  
Old 04 February 2013, 18:07   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,744
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?)
Toni Wilen is offline  
Old 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.
BlankVector is offline  
Old 04 February 2013, 21:05   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,744
I still can't duplicate it, no difference in cycle-exact mode.
Toni Wilen is offline  
Old 04 February 2013, 21:14   #7
BlankVector
Registered User
 
Join Date: Jun 2012
Location: France
Posts: 183
Here is my configuration file.
Attached Files
File Type: zip 68030.zip (2.6 KB, 129 views)
BlankVector is offline  
Old 04 February 2013, 21:19   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,744
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?
Toni Wilen is offline  
Old 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.
BlankVector is offline  
Old 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...
BlankVector is offline  
Old 05 February 2013, 16:43   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,744
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.
Toni Wilen is offline  
Old 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.
BlankVector is offline  
 


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

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 16:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.09295 seconds with 14 queries