![]() |
![]() |
#1 |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
Killing caches: fool-proof method?
Hi,
Does anyone have a nice blob of code for disabling caches across all 680x0? Let's assume this is just before or after taking over the system, ExecBase still available. I'm aware there's a little dance of poking control registers that may not all exist so need to be tested for, or the resulting exceptions handled. Alternatively (or as well): would CacheControl(bits=0,mask=-1) be suitable system-friendly approach? I haven't actually yet found an example of someone calling this to disable all caches, but I guess I haven't foraged *that* hard. ![]() Cheers! |
![]() |
![]() |
#2 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,624
|
If you have LVOCacheControl available, it should be fine. Beware that you need Exec V37+ for it to be present.
|
![]() |
![]() |
#3 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
000~060, all KS
Code:
start move.w #$4000,$dff09a movea.l $4.w,a6 lea super(pc),a5 jsr _LVOSupervisor(a6) move.w #$c000,$dff09a rts super moveq #0,d0 lea trap(pc),a5 lea $10.w,a1 lea $2c.w,a2 movea.l (a1),a3 movea.l (a2),a4 move.l a5,(a1) move.l a5,(a2) dc.l $4e7b0801 ;movec d0,vbr dc.l $f4784e71 ;cpusha dc dc.l $4e7b0002 ;movec d0,cacr dc.l $4e7b0808 ;movec d0,pcr move.l a3,(a1) move.l a4,(a2) rte trap addq.l #4,2(sp) rte |
![]() |
![]() |
#4 |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
|
![]() |
![]() |
#5 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
I remember CPUSHA BC (branch cache? 68060?)
|
![]() |
![]() |
#6 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
ross's example code sets VBR to 0 in the supervisor routine but doesn't restore it afterwards. May not be a problem if you're killing the system/OS anyway though.
|
![]() |
![]() |
#7 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Hi jotd, see this message http://eab.abime.net/showpost.php?p=...5&postcount=15
CPUSHA pushes and possibly invalidates selected cache lines (IC=instruction, DC=data, BC=both). BC works, but if you disable all caches (CACR=0) then a DC suffice. For the 060 i've disabled also the Superscalar Dispatch (ESS bit in PCR register). Last edited by ross; 08 February 2019 at 23:05. Reason: typo, written BC insted of DC |
![]() |
![]() |
#8 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
You can simply add: Code:
move.l a5,(a2) ... moveq #0,d1 movec vbr,d1 ... dc.l $4e7b0801 ;movec d0,vbr EDIT: well, the moveq #0,d1 actually only serves if you plan to use the previous base and you are on a 000 not much if the next instruction is movec d0,vbr, so one of the two can be removed ![]() Last edited by ross; 08 February 2019 at 23:26. |
|
![]() |
![]() |
#9 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,164
|
I like the way your code does NOT test CPU family explicitly. Nice.
|
![]() |
![]() |
#10 | |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
Quote:
Zeroing VBR in this routine is quite nice if you're eventually killing the system: in some cases whatever you end up jumping into might well not consider non-zero VBR itself. Secondly I wondered whether touching INTENA is necessary -- is it just because touching exception vectors is frowned on? I suppose it might stop AV or debug software going nuts. |
|
![]() |
![]() |
#11 |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
Interesting update on this: I found the CPUSHA instruction can hang on some (specifically, Apollo) 68020 and 68030 accelerators. I didn't track down the root cause -- sometimes it hangs, while in other places it might appear to execute (without the expected F-Line exception). The CPUSHA will cause a bus cycle on 020/030, so perhaps the Apollo glue mucks up the handling.
I fixed this by gating execution of CPUSHA on a 'safer' 040+ instruction (MOVEC ITT0,D1) which does not depend on external decode logic. |
![]() |
![]() |
#12 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,216
|
I would not know how that might be possible, given that neither the 68020 nor the 68030 has a CPUSH instruction. Actually, they do not have the need for one in first place. The 68020 has only an I-cache, and the 68030 has a D-cache on top, but it is write-through.
|
![]() |
![]() |
#13 | |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
Quote:
|
|
![]() |
![]() |
#14 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,216
|
Ah, so that's what you are saying. Indeed, one should *not* attempt to run CPUSHA on these processors at all since the instruction is unsupported on them. To clear the cache, use CacheClearU() in exec, which is processor-independent.
|
![]() |
![]() |
#15 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
Properly designed hardware should reject CPU co-processor IDs that don't exist by activating bus error signal when CPU attempts to access non-existing co-pro which CPU internally converts to normal F-line exception. This is documented in official 020/030 documentation.
Unfortunately some 020/030 boards fail to do it. |
![]() |
![]() |
#16 | |
Registered User
Join Date: May 2011
Location: Cambridge
Posts: 682
|
Quote:
By the way, tangentially related: I have had reported that 'PMOVE TC' (to disable MMU on 68851/68030) would give an unexpected exception on a Furia 68020 card (Coprocessor Protocol Violation, which was a new one on me). I figure that since 68851 is external, 68020 must do bus cycles for that instruction too and is also subject to vagaries of external logic. So I am making that instruction 68030-only: I assume that since 030 doesn't support external PMMU, the PMOVE to disable MMU must be safe even on 68EC030 which does not 'support' MMU? No bus cycles there? |
|
![]() |
![]() |
#17 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,216
|
Quote:
Quote:
I afraid this is not so simple. It may or may not cause an exception, may just work, or may have more or less desasterous side effects. To my experience, mot sold 68030 which failed an MMU test as 68EC030, and there is to my very knowledge no reliable way to tell a 68EC030 apart from a 68030. A 68EC030 is just a 68030 with a failing MMU. |
||
![]() |
![]() |
#18 | |
Registered User
Join Date: Sep 2006
Location: New Sandusky
Posts: 942
|
Quote:
Why would you want to do this? Just as a means of slowing down the CPU even more? AFAIK having superscalar on doesn't cause any compatibility problems with anything. Only possibility I can think of is if you're doing some weird externally-modified code that changes an opcode for the very next instruction fetch somehow. |
|
![]() |
![]() |
#19 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
-- So the code blob need to be modified, I had no idea that the CPUSHA in some accelerator can hang the machine.. How to fast recognize 020/030 CPUs (w/o SO)? |
|
![]() |
![]() |
#20 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
You mean without OS ?
Not sure it's what you want, but here are a few tricks : - set some 040+ bit in cacr - if it reads back as 0, then 020-030 - try to access caar register - if not illegal, then 020-030 - trace a trap instruction - if you get to the trap vector instead of trace, then 040+ - try some cpsave opcode (e.g. $FF10) in user mode - if privilege violation instead of line-F, then 020-030 Note that it's possible emulators get caught and won't behave properly ![]() |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
How to disable caches using MOVEC => CACR | jotd | Coders. Asm / Hardware | 12 | 07 November 2017 20:45 |
Fool's Errand | Catflap | support.Games | 2 | 30 April 2015 21:53 |
How not to flush caches. | Toni Wilen | Coders. General | 18 | 28 October 2011 10:05 |
Some fool on ebay selling WinUAE | fitzsteve | support.WinUAE | 28 | 02 April 2011 20:24 |
A lost fool | Autana | project.WHDLoad | 9 | 05 January 2006 16:16 |
|
|