SetPatch / CacheControl()

[dissident]

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.

[daxb]

If nobody here can help I would suggest to ask thor or olsen. They should know it or have access to the sources.

[Toni Wilen]

Originally Posted by dissident

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.

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)")

[SpeedGeek]

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.

[dissident]

Originally Posted by Toni Wilen

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.

Originally Posted by Toni Wilen

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]

Originally Posted by SpeedGeek

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().

[SpeedGeek]

Originally Posted by dissident

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

[dissident]

Originally Posted by SpeedGeek

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?

[SpeedGeek]

Originally Posted by dissident

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.

[dissident]

Originally Posted by SpeedGeek

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.

[ross]

Originally Posted by dissident

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:

		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

[meynaf]

Why isn't simple cpu nocache command enough ?

[dissident]

Originally Posted by ross

Hi dissident, I use code similar to this:

        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:

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]

Originally Posted by meynaf

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.

[ross]

Originally Posted by dissident

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.

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

[SpeedGeek]

Originally Posted by dissident

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

[dissident]

Originally Posted by ross

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]

Originally Posted by SpeedGeek

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.