English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 26 February 2018, 22:44   #1
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
SetPatch / CacheControl()

Hi,

actually I'm trying to test, if there is a way to disable the 68060 branch cache OS friendly with the patched CacheControl() function after the "SetPatch CACHES" (OS 3.9) command is executed on a system with KS 3.0/3.1. The SetPatch enables the branch cache, but it seems that with CacheControl() only the data&instruction cache can be turned off.

1. Is there any documentation what the SetPatch (OS3.5/3.9) command does exactly?

2. I know that the SetPatch command sets the 68060-bit in Exec's AttnFlags but where is this documented? The normal Commodore docs only support up to the 68040.
dissident is offline  
Old 27 February 2018, 15:42   #2
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 2,118
If nobody here can help I would suggest to ask thor or olsen. They should know it or have access to the sources.
daxb is offline  
Old 27 February 2018, 16:02   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,129
Quote:
Originally Posted by dissident View Post
1. Is there any documentation what the SetPatch (OS3.5/3.9) command does exactly?
I don't think so and there probably is some undocumented API that setpatch uses to execute some 68040/68060.library function that does the cache configuration.

Quote:
2. I know that the SetPatch command sets the 68060-bit in Exec's AttnFlags but where is this documented? The normal Commodore docs only support up to the 68040.
OS3.9 headers have it. ("#define AFF_68060 (1L<<7)")
Toni Wilen is online now  
Old 27 February 2018, 16:50   #4
SpeedGeek
Registered User
SpeedGeek's Avatar
 
Join Date: Dec 2010
Location: Wisconsin USA
Age: 55
Posts: 416
The Setpatch for OS 3.0/3.1 can only detect the 68040 and load the 68040.library, so 3rd party developers created a "Dummy" 68040.library which can detect the 68060 and load the 68060.library.

The Setpatch for OS 3.5/3.9 can detect the 68060 and load it so the "Dummy" library can be eliminated. Note that it is the 68060.library which sets the exec AttnFlag rather than Setpatch.

The extra 68060 cache functions (e.g. branch cache) are usually supported by the CPU060 command provided by the 68060.library developer.
SpeedGeek is offline  
Old 27 February 2018, 21:08   #5
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
Quote:
Originally Posted by Toni Wilen View Post
I don't think so and there probably is some undocumented API that setpatch uses to execute some 68040/68060.library function that does the cache configuration.
So disassembling the SetPatch command seems to be more effective to get some details of its functions.

But it would be interesting to know which 68040/68060.library functions exist. I guess docs for them are very rare even in 2018.


Quote:
Originally Posted by Toni Wilen View Post
OS3.9 headers have it. ("#define AFF_68060 (1L<<7)")
Okay, so with SetPatch3.0/3.1 no 68060 would be detected and so there would always be a 68040 I guess.
dissident is offline  
Old 27 February 2018, 21:25   #6
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
Quote:
Originally Posted by SpeedGeek View Post
The Setpatch for OS 3.0/3.1 can only detect the 68040 and load the 68040.library, so 3rd party developers created a "Dummy" 68040.library which can detect the 68060 and load the 68060.library.

The Setpatch for OS 3.5/3.9 can detect the 68060 and load it so the "Dummy" library can be eliminated. Note that it is the 68060.library which sets the exec AttnFlag rather than Setpatch.

The extra 68060 cache functions (e.g. branch cache) are usually supported by the CPU060 command provided by the 68060.library developer.
Hey SpeedGeek, good background information. So it seems that the 68060.library and its functions will always be the mistery of the developers. Yes, I know the CPU060 command. But does this command also work on 68020 machines?

To sum it, up there is no way that the CacheControl() function is patched by the SetPach3.5/3.9 command this way that the branch cache can be disabled. I guess it's time for KS 3.1.4+ for a real 68060 support. http://eab.abime.net/showthread.php?...39#post1195739

Then I have to access the CACR of the 68060 directly or I have to write my own patch for CacheControl().
dissident is offline  
Old 28 February 2018, 15:45   #7
SpeedGeek
Registered User
SpeedGeek's Avatar
 
Join Date: Dec 2010
Location: Wisconsin USA
Age: 55
Posts: 416
Quote:
Originally Posted by dissident View Post
Hey SpeedGeek, good background information. So it seems that the 68060.library and its functions will always be the mistery of the developers. Yes, I know the CPU060 command. But does this command also work on 68020 machines?

To sum it, up there is no way that the CacheControl() function is patched by the SetPach3.5/3.9 command this way that the branch cache can be disabled. I guess it's time for KS 3.1.4+ for a real 68060 support. http://eab.abime.net/showthread.php?...39#post1195739

Then I have to access the CACR of the 68060 directly or I have to write my own patch for CacheControl().
Well, I doubt that any 68060.library developers put much effort into supporting previous 68K family CPUs since the Commodore CPU command supports them up to and including the 68040.

The CacheControl() function is not patched by Setpatch. It is patched by the 68060.library, so your options are:

1) Set the 68060.library cache config file options (if available)
2) Use the CPU060 command to set the cache config options
3) Patch the 68060.library "Default" cache config options
SpeedGeek is offline  
Old 01 March 2018, 22:18   #8
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
Quote:
Originally Posted by SpeedGeek View Post
Well, I doubt that any 68060.library developers put much effort into supporting previous 68K family CPUs since the Commodore CPU command supports them up to and including the 68040.

The CacheControl() function is not patched by Setpatch. It is patched by the 68060.library, so your options are:

1) Set the 68060.library cache config file options (if available)
2) Use the CPU060 command to set the cache config options
3) Patch the 68060.library "Default" cache config options
Hi SpeedGeek again very useful infos. Thanks.

1) I don't quite understand what that means. Instead I would execute SetPatch3.9 in the startup-sequence to have the 68060 bit set in AttnFlags if this CPU is available.
2) Then I would use a self written prg which tests for the 68060 bit set in AttnFlags and returns a TRUE or FALSE condition. So I could decide with the IF command whether CPU060 on the 68060 or CPU for 68020-040 is executed to turn off the Caches.
3) How should this be done?
dissident is offline  
Old 02 March 2018, 15:31   #9
SpeedGeek
Registered User
SpeedGeek's Avatar
 
Join Date: Dec 2010
Location: Wisconsin USA
Age: 55
Posts: 416
Quote:
Originally Posted by dissident View Post
Hi SpeedGeek again very useful infos. Thanks.

1) I don't quite understand what that means. Instead I would execute SetPatch3.9 in the startup-sequence to have the 68060 bit set in AttnFlags if this CPU is available.
2) Then I would use a self written prg which tests for the 68060 bit set in AttnFlags and returns a TRUE or FALSE condition. So I could decide with the IF command whether CPU060 on the 68060 or CPU for 68020-040 is executed to turn off the Caches.
3) How should this be done?
For 1) this really depends on the "If Available" part. Check the 68060.library docs to see if it supports a config file (e.g. env:68060.cfg) and what options can be set here.

For 2) you can probably just run the CPU060 command followed by IF WARN or IF FAIL (depending on what your s-s defined "FailAt" value is set to) then followed by the CPU Command... but the previous 68K Family CPUs don't have a Branch Cache so I don't know why you need it?

For 3) you would need to disassemble the 68060.library and patch the CacheControl() function to change the default cache config set up.
SpeedGeek is offline  
Old 02 March 2018, 23:11   #10
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
Quote:
Originally Posted by SpeedGeek View Post
For 1) this really depends on the "If Available" part. Check the 68060.library docs to see if it supports a config file (e.g. env:68060.cfg) and what options can be set here.

For 2) you can probably just run the CPU060 command followed by IF WARN or IF FAIL (depending on what your s-s defined "FailAt" value is set to) then followed by the CPU Command... but the previous 68K Family CPUs don't have a Branch Cache so I don't know why you need it?

For 3) you would need to disassemble the 68060.library and patch the CacheControl() function to change the default cache config set up.
1) Could you please give me a hint where to find those 68060.library docs?

2) Yes, if the CPU060 supports such a return-value, this would be a smarter solution. I know that only the 68060 has a branch cache. But I wanted to turn off the caches of the 68020-060 to run OCS demos after these caches are turned off. So a combination of using the CPU and the CPU060 commands could be a solution.
I've checked the CPU060 command with a debugger on a 68030 and a 68060 system. There is only one exit and the returncode in D0 is always set to zero.

3) Okay, I understand.
dissident is offline  
Old 02 March 2018, 23:32   #11
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,366
Quote:
Originally Posted by dissident View Post
But I wanted to turn off the caches of the 68020-060 to run OCS demos after these caches are turned off
Hi dissident, I use code similar to this:

Code:
		moveq   #0,d0
		dc.l	$4e7b0002		;movec d0,cacr #disable all cache
		dc.l	$f4784e71		;cpusha dc #Flush dirty cache lines 
		dc.l	$4e7b0808		;movec d0,pcr #>=68060
In supervisor mode and after checking AttnFlags.

EDIT: if there are no friendly systems better to use brutal manners

Last edited by ross; 02 March 2018 at 23:56.
ross is offline  
Old 03 March 2018, 10:37   #12
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,344
Why isn't simple cpu nocache command enough ?
meynaf is offline  
Old 03 March 2018, 12:26   #13
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
Quote:
Originally Posted by ross View Post
Hi dissident, I use code similar to this:

Code:
        moveq   #0,d0
        dc.l    $4e7b0002        ;movec d0,cacr #disable all cache
        dc.l    $f4784e71        ;cpusha dc #Flush dirty cache lines 
        dc.l    $4e7b0808        ;movec d0,pcr #>=68060
In supervisor mode and after checking AttnFlags.

EDIT: if there are no friendly systems better to use brutal manners
I use a similar code executed in supervisor mode with the Supervisor() function:

Code:
caches_off
  OR.W    #$0700,SR      ;Level-7-interrupt priority
  CPUSHA  BC             ;(DC.W $F4F8) Flush Instruction+Data-Cache
  MOVEQ   #0,D1          ;CACR: Turn off Instr.+Data+Branch-Cache
  MOVEC   D1,CACR        ;(DC.L $4E7B1002) New content of CACR
  NOP                    ;Prevent parallel execution on the MC68060
  RTE
But writing to the PCR register is new for me. Remarkable, I didn't know it since now. I guess you do this mainly to clear the ESS-bit to disable the 68060's ability to execute multiple instructions per cycle. But if all caches are disabled, is this really necessary?
dissident is offline  
Old 03 March 2018, 12:32   #14
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
Quote:
Originally Posted by meynaf View Post
Why isn't simple cpu nocache command enough ?
Because cpu nocache doesn't disable the 68060's branche cache and thinks it's a 68040. Only the data&instruction caches can be disabled with it. And I want to be sure that all caches are disabled to run nasty old OCS demos with perhaps self modifying code.
dissident is offline  
Old 03 March 2018, 15:38   #15
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,366
Quote:
Originally Posted by dissident View Post
CPUSHA BC ;(DC.W $F4F8) Flush Instruction+Data-Cache
Notice that i've used CPUSHA DC.

From MC68060UM:

"To fully support self-modifying code in any situation, it is imperative that a CPUSHA instruction specifying both caches be executed before the execution of the first self-modified instruction. The CPUSHA instruction has the effect of ensuring that there is no stale data in memory, the pipeline is flushed, and instruction prefetches are repeated and taken from external memory."

But if you flush/disable caches through CACR then only dirty lines remains.

"A cache line is always in one of three states: invalid, valid, or dirty.
For invalid lines, the Vbit is clear, causing the cache line to be ignored during lookups. Valid lines have their V-bit set and D-bit cleared, the line contains valid data consistent with memory. Dirty cache lines have the V-bit and D-bit set, indicating that the line has valid entries that have not been written to memory."

Only Data Cache supports dirty line so CPUSHA DC suffice and is faster.

Quote:
But writing to the PCR register is new for me. Remarkable, I didn't know it since now. I guess you do this mainly to clear the ESS-bit to disable the 68060's ability to execute multiple instructions per cycle. But if all caches are disabled, is this really necessary?
Yes, the processor configuration register (PCR) contains bits which control the internal pipelines of the '060.
But I did not find any references to the fact that disabling the cache changes the operation of the pipelines.

At least this is what I understand from the manual

EDIT: not mentioned but there is also a NOP, you can recognize the $4e71 opcode

Last edited by ross; 03 March 2018 at 15:47.
ross is offline  
Old 03 March 2018, 18:21   #16
SpeedGeek
Registered User
SpeedGeek's Avatar
 
Join Date: Dec 2010
Location: Wisconsin USA
Age: 55
Posts: 416
Quote:
Originally Posted by dissident View Post
1) Could you please give me a hint where to find those 68060.library docs?

2) Yes, if the CPU060 supports such a return-value, this would be a smarter solution. I know that only the 68060 has a branch cache. But I wanted to turn off the caches of the 68020-060 to run OCS demos after these caches are turned off. So a combination of using the CPU and the CPU060 commands could be a solution.
I've checked the CPU060 command with a debugger on a 68030 and a 68060 system. There is only one exit and the returncode in D0 is always set to zero.

3) Okay, I understand.
The docs supplied with the 68060.library or whatever docs you can find.
The CPU command for OS 3.9 can CHECK for the 68060 and set the return code to 5 if you still want use IF WARN but since the CPU060 command just returns zero (even when it fails) why not simply do:

CPU060 NOBRANCHECACHE; Use >NIL: here to suppress the output
CPU NOCACHE; See above comment
SpeedGeek is offline  
Old 04 March 2018, 17:58   #17
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
Quote:
Originally Posted by ross View Post
Notice that i've used CPUSHA DC.

From MC68060UM:

"To fully support self-modifying code in any situation, it is imperative that a CPUSHA instruction specifying both caches be executed before the execution of the first self-modified instruction. The CPUSHA instruction has the effect of ensuring that there is no stale data in memory, the pipeline is flushed, and instruction prefetches are repeated and taken from external memory."

But if you flush/disable caches through CACR then only dirty lines remains.

"A cache line is always in one of three states: invalid, valid, or dirty.
For invalid lines, the Vbit is clear, causing the cache line to be ignored during lookups. Valid lines have their V-bit set and D-bit cleared, the line contains valid data consistent with memory. Dirty cache lines have the V-bit and D-bit set, indicating that the line has valid entries that have not been written to memory."

Only Data Cache supports dirty line so CPUSHA DC suffice and is faster.


Yes, the processor configuration register (PCR) contains bits which control the internal pipelines of the '060.
But I did not find any references to the fact that disabling the cache changes the operation of the pipelines.

At least this is what I understand from the manual

EDIT: not mentioned but there is also a NOP, you can recognize the $4e71 opcode
Hi ross, you are great, thanks for this very detailed explanation. This makes things much clearer for me.

Also thanks for your nop command hint, I really overlooked it. Additionally I will have a closer look at the disassembled code of the CPU060 command. I guess that there is much to learn from it.

I own the MC68060UM manual, too, but I never read the caches part in detail. Time to have a more accurate look at this worthful document.
dissident is offline  
Old 04 March 2018, 18:01   #18
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 178
Quote:
Originally Posted by SpeedGeek View Post
The docs supplied with the 68060.library or whatever docs you can find.
The CPU command for OS 3.9 can CHECK for the 68060 and set the return code to 5 if you still want use IF WARN but since the CPU060 command just returns zero (even when it fails) why not simply do:

CPU060 NOBRANCHECACHE; Use >NIL: here to suppress the output
CPU NOCACHE; See above comment
Hi SpeedGeek, many thanks for this hint. I will check this way to turn off the caches.
dissident 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
Setpatch 3.9 Romupdate Yes or No ? Nibbler support.Hardware 0 06 February 2015 23:31
setpatch option andreas request.UAE Wishlist 4 13 August 2008 17:21
SetPatch: Unloading possible? mrleeman support.Apps 1 21 July 2008 11:06
where can i find setpatch 44.38 turrican3 request.Apps 5 07 May 2007 20:46

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 13:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08831 seconds with 15 queries