CPU Cache crash

A forum about the Hatari ST/STE/Falcon emulator - the current version is v2.1.0

Moderators: simonsunnyboy, thothy, Moderator Team

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

CPU Cache crash

Postby exxos » Fri Jan 08, 2016 11:06 pm

I've noticed in the Falcon version the cache instructions cause it to crash, but the instructions work ok in Hatari.exe. I had to use the falcon one to make use of the ALT-RAM but it causes problems for testing the cache instructions. So assume its something which hasn't been "Fixed" yet ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
shoggoth
Nature
Nature
Posts: 896
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: CPU Cache crash

Postby shoggoth » Sat Jan 09, 2016 9:20 am

Could you elaborate? Why do you need to fiddle with the caches, unless you're doing the nasty (like building code in memory etc)?
Ain't no space like PeP-space.

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: CPU Cache crash

Postby exxos » Sat Jan 09, 2016 9:32 am

shoggoth wrote:Could you elaborate? Why do you need to fiddle with the caches, unless you're doing the nasty (like building code in memory etc)?


Its part of Gembench6's features to turn the caches on/off. Though while the code runs in Hatari.exe the caches have no effect, but at least it doesn't crash.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: CPU Cache crash

Postby dml » Sat Jan 09, 2016 1:10 pm

I think we'd need to see exactly how it's operating on the cache.

I haven't noticed any problems with Hatari turning caches/on off using movec to/from cacr, at least on 68030. Not sure about the other chips. Make sure it's done from supervisor mode though.

Turning the caches on/off without clearing them can cause problems in some circumstances, but that's all.

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: CPU Cache crash

Postby exxos » Sat Jan 09, 2016 1:53 pm

It works in Hatari but not The falcon Hatari.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: CPU Cache crash

Postby dml » Sat Jan 09, 2016 2:49 pm

exxos wrote:It works in Hatari but not The falcon Hatari.


Yeah, but given that 'non-falcon' Hatari just ignores the cache instructions (i.e. executes them, but does not implement the cache behaviour at all) it could mean that the crash has more to do with the *presence* of the cache and its normal behaviour, and less to do with Hatari not digesting the instructions.

i.e. if the Gembench code is incorrectly using the cache, you could get a crash simply *because* the instructions are being executed properly.

Here's one example:

- turn the datacache off
- write some data in a region which happens to be mirrored in the cache
- turn the datacache on
- read back the same data, and it's wrong - because the cache was asleep when the data was written

The correct solution is to clear the cache when toggling its state (or flush it, on higher processors, due to other problems with those).


This of course doesn't explain why it would work on a real Falcon and crash in Hatari. So that's a test worth doing to make sure, before digging into the crash. If the two agree, it's improper use of the cache. If the two disagree... its not very clear, but could still be related to cache behaviour differing between Hatari and HW.


What version of Hatari is it btw? Versions from 1.6 onwards (maybe earlier) have always been able to digest the instructions involved. But the cache behaviour itself was only introduced in 1.7 or 1.8 IIRC.

a typical cache control operation in 68030 assembly looks like this (supervisor mode)

Code: Select all

 movec cacr,d0
 andi.w #my_cache_mask,d0  ; disables the stuff we don't want
 ori.w #my_cache_newstate|iclr|dclr,d0  ; enables the stuff we do want & clears the caches
 movec d0,cacr


Higher processors have the cache control bits in the upper word, so it requires longword operations. 68020/30 use the lower word only.

Below are the valid CACR flags for 020/030. Note they are different on 040,060.


Code: Select all

; bits (used by 68020/30)

ienab_bit   =      0
ifrz_bit   =      1
iclre_bit   =      2
iclr_bit   =      3
ibrst_bit   =      4

denab_bit   =      8
dfrz_bit   =      9
dclre_bit   =      10
dclr_bit   =      11
dbrst_bit   =      12
wa_bit      =      13


; flags (used by 68020/30)

ienab      =      1<<ienab_bit
ifrz      =      1<<ifrz_bit
iclre      =      1<<iclre_bit
iclr      =      1<<iclr_bit
ibrst      =      1<<ibrst_bit

denab      =      1<<denab_bit
dfrz      =      1<<dfrz_bit
dclre      =      1<<dclre_bit
dclr      =      1<<dclr_bit
dbrst      =      1<<dbrst_bit
wa      =      1<<wa_bit


; masks (valid flags for 68020/30)

cache_mask_68020 = ienab|ifrz|iclre|iclr
cache_mask_68030 = ienab|ifrz|iclre|iclr|ibrst | denab|dfrz|dclre|dclr|dbrst|wa

rpineau
Atari Super Hero
Atari Super Hero
Posts: 505
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: CPU Cache crash

Postby rpineau » Sat Jan 09, 2016 4:41 pm

@dml : exxos GB6 is using my asm code. The code does a movec to CACR. I do a flush when turning them off ($0808 to turn them off and clear them). I could add the clear bit when turning them on too. I do not enable the cache burst on 68030.
Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: CPU Cache crash

Postby dml » Sat Jan 09, 2016 4:56 pm

Hi!

rpineau wrote:@dml : exxos GB6 is using my asm code. The code does a movec to CACR. I do a flush when turning them off ($0808 to turn them off and clear them). I could add the clear bit when turning them on too. I do not enable the cache burst on 68030.
Rodolphe


Well that should suffice IMO. It's only necessary to clear them when you disable, as you describe. And the burst flags are ignored regardless of their state.

@exxos:

Is it definitely being used from supervisor mode? The old UAE core perhaps ignores the instruction privilege side of things, where the new one enforces it (i.e. priv violation crash = count the bombs onscreen).

A far less likely bug involves preservation of registers used in the asm code being invoked. I'd expect this to break all versions of Hatari and HW though.

Have other versions of Hatari been tried, in case it's a short-term bug? (i mean version information - not the falcon/st builds thing).

rpineau
Atari Super Hero
Atari Super Hero
Posts: 505
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: CPU Cache crash

Postby rpineau » Sat Jan 09, 2016 5:08 pm

yes my code switch tu superuser before setting the cache (I test in devpac before giving him the object code to use in HiSoft Basic) :

Code: Select all

cache_set
   ; D2 contains the new value for CACR
   ; become supervisor
   move.l   #0,-(a7)
   move.w   #$20,-(a7)
   trap    #1
   addq.l    #6,a7

   lea   cache_state(pc),a3
   movec   d2,cacr
   movec   cacr,d2
   move.w   d2,(a3)
   
   ; return to user mode
   move.l   d0,-(a7)
   move.w   #$20,-(a7)
   trap    #1
   addq.l    #6,a7
   bra.s   exit


Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: CPU Cache crash

Postby dml » Sat Jan 09, 2016 5:24 pm

Ok a few things to look at here...

I'd normally be a bit scared to trust register preservation across something like a supervisor switch. It might be ok since d2+ are preserved for the C ABI and TOS, but my trust level is not that good here :D

Also I don't quite remember offhand what the switch does for stack adjustment/compensation - but the switch itself causes the stackpointer to alternate between USP and SSP, so the #6,a7 adjustments may be breaking the code by walking across already-pushed data in supervisor space.

in other words, the userstack you 'pushed' the trap args onto, is not the same (super) stack you are compensating with #6 on the way out! Better check this detail - at both ends. It may be TOS 'expects' you might add the adjustment, but IMO it would be wrong to do so unless there's a strong internal reason behind it. (Since I usually change the SSP when switching to super, I wouldn't need to remember either way! But I'd certainly check it if/when I decided to use it)

You might prefer to use the supexec call instead to call the cache manip. code as a super-subroutine, and pass the D2 value some other way. This sidesteps worries about stack adjustment requirements.

pea my_super_routine
move.w #$26,-(sp)
trap #14
addq #6,sp

Not sure how a bug of this kind maps to Hatari exactly, but superstack corruption could have fun, time-critical side effects which don't play out identically on each system.


rpineau wrote:yes my code switch tu superuser before setting the cache (I test in devpac before giving him the object code to use in HiSoft Basic) :

Code: Select all

cache_set
   ; D2 contains the new value for CACR
   ; become supervisor
   move.l   #0,-(a7)
   move.w   #$20,-(a7)
   trap    #1
   addq.l    #6,a7

   lea   cache_state(pc),a3
   movec   d2,cacr
   movec   cacr,d2
   move.w   d2,(a3)
   
   ; return to user mode
   move.l   d0,-(a7)
   move.w   #$20,-(a7)
   trap    #1
   addq.l    #6,a7
   bra.s   exit


Rodolphe

rpineau
Atari Super Hero
Atari Super Hero
Posts: 505
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: CPU Cache crash

Postby rpineau » Sat Jan 09, 2016 8:14 pm

Ok I totally see your point.
I've been using a7 since ... actually forever, and never had any issues with it in devpac. But I can change it to sp intead of a7 (devpac generate the right opcodes). As for the adjustment I see your point. Not quite sure either. I think TOS set both stack to the same pointer. Of course after a few calls they ca diverge if adjustment is done on one and not the other (If I get what you're saying).
I've traced this in monst and mon030 and D2 is not touched. Also some of the code not shown here saves all the register I use with a movem.l and restore them at the end. Trap calls only change A0/D0 as far as I remember.
Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: CPU Cache crash

Postby dml » Sat Jan 09, 2016 8:23 pm

rpineau wrote:Ok I totally see your point.
I've been using a7 since ... actually forever, and never had any issues with it in devpac. But I can change it to sp intead of a7 (devpac generate the right opcodes). As for the adjustment I see your point. Not quite sure either. I think TOS set both stack to the same pointer. Of course after a few calls they ca diverge if adjustment is done on one and not the other (If I get what you're saying).
I've traced this in monst and mon030 and D2 is not touched. Also some of the code not shown here saves all the register I use with a movem.l and restore them at the end. Trap calls only change A0/D0 as far as I remember.
Rodolphe


Hi - ok D2 not being touched - good news. To be fair it really shouldn't be, but with something like a supervisor switch it was worth double checking...

However the SP situation isn't quite what I was meaning.

SP is equivalent to A7 in both modes (super/user) so it won't matter which one you choose. It's just syntax.

However the stack pointer itself is not the same when you switch. They are in different registers, and must point at different areas of memory.

In usermode SP/A7 = USP, whereas in supervisor mode SP/A7 = SSP. They are initialized to different address spaces to keep exceptions out of user space etc.

In other words - SP/A7 will 'teleport' when you switch modes, as different internal registers get mapped. Trace it in a debugger and watch what happens. This is why the adjustment needs to be examined.

rpineau
Atari Super Hero
Atari Super Hero
Posts: 505
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: CPU Cache crash

Postby rpineau » Sat Jan 09, 2016 8:33 pm

Ok understood.
Thanks for the clarification.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
shoggoth
Nature
Nature
Posts: 896
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: CPU Cache crash

Postby shoggoth » Sat Jan 09, 2016 9:27 pm

I've always found GEMBench to be inherently crashy and not willing to play ball on >030, so god knows what's in there.
Ain't no space like PeP-space.

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: CPU Cache crash

Postby exxos » Sat Jan 09, 2016 9:53 pm

shoggoth wrote:I've always found GEMBench to be inherently crashy and not willing to play ball on >030, so god knows what's in there.


Its why I am totally re-coding it from the bottom up, and adding support for caches. Though I never had any issues on the falcon or CT60 with GB4. I was just using Hatari Falcon for initial testing as its quicker to program and test on my PC than keep messing about with floppies. Though I ran into issues so thought I would ask about it here as it was causing problems that I couldn't test Alt-ram and use caches in one version of Hatari.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
shoggoth
Nature
Nature
Posts: 896
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: CPU Cache crash

Postby shoggoth » Sat Jan 09, 2016 10:22 pm

I'd check for the presence of Ssystem() and use it when available, then fall back to CT60/Milan-specific calls (if available), and as a last resort use CPU-dependent code if I absolutely have to.
Ain't no space like PeP-space.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1649
Joined: Sun Jul 31, 2011 1:11 pm

Re: CPU Cache crash

Postby Eero Tamminen » Sun Jan 10, 2016 6:52 pm

Does the crash happen only when you use cache instructions together with TT-RAM, or also without TT-RAM?

Full 030 cache support (cache misses etc), MMU and TT-RAM support [1] was added only in Hatari v1.9. Previous versions had only partial cache effect emulation. Only WinUAE CPU core supports caches, old UAE CPU core (used for ST/STE emulation until Hatari v1.9) ignores all caches related stuff.

[1] MMU and TT-RAM support are currently incompatible with each other.

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: CPU Cache crash

Postby exxos » Sun Jan 10, 2016 10:57 pm

It seems its related to the 24bit addressing. If I have that option on, things seems to work fine, thats 4MB ST-RAM 8MB TT RAM. Though Hatari moans it needs 24bit addressing off to use TT-ram and seems to turn it off :roll:
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator


Social Media

     

Return to “Hatari”

Who is online

Users browsing this forum: No registered users and 3 guests