Burn 100000 on the 68040

[Thomas Richter]

Hi folks, hope to get some help here with a pretty special request. I'm looking for a verified(!) code that burns 100000 cycles on the 68040. Assumption is that the code is cached and in cacheable memory. Thus, one can assume that the code is completely in cache. You can also assume that task switching and interrupts are disabled. The code should approximately look as follows:

  DelayLoop040:         move.l  #1000,d0 .loop:         nop                     ;8 cycles per nop         nop         nop         nop         nop         nop          nop                     ;8 cycles per nop         nop         nop         nop         nop         nop                     ;12 * 8 = 96 cycles burned         dbra    d0,.loop        ;+3 cycles for dbra = 99 cycles burned         rts

This looks like a rather strange request (even more so from me), so let me explain what this is used for. The purpose is to determine the CPU clock frequency of an 68040 board, as close as possible. For this, the current code runs a delay cycle like the above until 100ms have been spend, and then returns the number of times the above delay loop is run. As one can compute, this returns (approximately) the clock frequency of the CPU in Mhz. Now, what do I need this all for? Actually, this is part of a (new) driver for a GVP EGS 110 graphics board, and as it looks, the board requires a configuration of the number of wait states of its memory. The number of wait states depends on the clock frequency of the host CPU as the card connects directly to the board. Thus, please provide algorithms, (i.e. I need the number of NOPs and the loop counter for the dbra), and please verify that, indeed, the requested number of cycles is burned, for example by cross-checking with the CIA-E clock. Thanks a lot, and I hope I get some help for this (as much as I hate cycle counting, this time it is needed (- Greetings, Thomas

[Don_Adan]

Why not, something like this?

 move.w #999,D0
Loop
 addq.l #1,D1 ; 1 (1 cycle)
 addq.l #1,D1 ; 2
...
 addq.l #1,D1 ; 97
 dbf D0,Loop (3 cycles)
 rts

[Thomas Richter]

It doesn't really matter what is in the loop as long as you had it verified. "NOP" seemed like a good alternative since it seems to burn more cycles (less instructions), but that does not matter too much. It does not have to be super precise.

[meynaf]

NOP can burn many cycles because it triggers a pipeline resync. Thus its timing may eventually depend on what the cpu was doing before.

[Thomas Richter]

Absolutely. This is why I need it verified for the 68040. I have a verified NOP delay loop for the 68030, but I cannot simply reuse the same loop for the 68040 for the reasons you gave. The NOP on the 68040 will spend a different (more?) number of cycles than the NOP on the 68030.

[meynaf]

Why using NOP then ? It does not look like a very reliable source for cycle counting.
Unfortunately i don't own a 040 so i can't verify timings, but Don Adan's code looks good enough.

[Thomas Richter]

That's not any different with any other instruction - timing will differ between the 68030 and 68040 anyhow, so I need two delay loops in first place. Anyhow, I'm not insisting on NOP, I only need to be sure it really burns the requested number of cycles.

[aros-sg]

Can't you do something self calibrating like it's being done elsewhere to implement things like very small (busy looping) time delays.

[Thomas Richter]

Hmm, do you have anything particular in mind? Just to remind you, the point of the whole exercise is to find the clock speed of the CPU, which I need to configure the wait states of a graphics card attached directly to the turbo board.

[Locutus]

Sorry if this is stupid

...But isn't this over engineering? If you only need the approximate clock in MHz, why not ask it the end user during the installation process?

I can't imagine there are many users with this setup who wouldn't know their installed CPU clock speed.

[Thomas Richter]

Well, you know, if the casual user has to modify a tool type to get a driver working, chances are that this doesn't work. I have no problem adding a tool type for this type of configuration, but the driver should work out of the box without user intervention.

[alexh]

Originally Posted by Thomas Richter

I have no problem adding a tool type for this type of configuration, but the driver should work out of the box without user intervention.

Is there a big range of speeds? 25MHz, 33MHz, 40MHz?

[Thomas Richter]

Ok, here a test program instead:

http://eab.abime.net/attachment.php?...1&d=1657639518

Please run on an 68040 system, please report the result, and the true CPU clock of the system.

Thanks!

[Thomas Richter]

Originally Posted by alexh

Is there a big range of speeds? 25MHz, 33MHz, 40MHz?

No, not at all, only what GVP managed to manufacture as Turbo boards. It is pretty much the above range. Thus, it doesn't have to be super-precise, but it needs to distinguish the clocks to switch between 2 to 5 wait states, depending on the board frequency.

[Mathesar]

Forget about it if this is a stupid idea but:

If you can read/write into the graphics card memory. Can't you do a memory test to see how many wait states are needed for a reliable data transfer?

Also, I don't have a 040 system to test on otherwise I would have helped.

[grond]

Originally Posted by Mathesar

If you can read/write into the graphics card memory. Can't you do a memory test to see how many wait states are needed for a reliable data transfer?

Such tests are usually not reliable because the system will behave differently when the computer heats up.

From what I read in the German forum, the problem has been solved, Thomas has working code already.

[paraj]

Originally Posted by grond

Such tests are usually not reliable because the system will behave differently when the computer heats up.

From what I read in the German forum, the problem has been solved, Thomas has working code already.

That's interesting. Does the graphics card do thermal throttling?
(Would have helped if I could with the measurements, but "only" have a 060).

[Thomas Richter]

Actually, I doubt such ancient technology uses thermal throttling, it is more a matter of system tolerances such that a particular configuration when measured with a cold system no longer remains stable once the system heats up as tolerances are then exceeded. It is also hard to actually detect the issues with bit flips into video RAM without actually turning the video on and trying to reproduce the issue by flooding the bus with writes.

But as ground said, the problem is resolved. Funny enough, my 68040 "computed delay loop" worked right from its design sketch, a rather rare circumstance.

[grond]

As Thomas says, semiconductors get "slower" (it's more complicated physics but let's skip this) as they heat up. This can also affect power supply and a lot of other factors that determine how a processor or bus driver chip will operate.

[alexh]

Originally Posted by grond

As Thomas says, semiconductors get "slower" (it's more complicated physics but let's skip this) as they heat up.

That is not strictly true. Semiconductors are designed so that they work correctly at the speed they are being clocked across a range of temperatures.

Heat should have no affect on tests like these.

What is more likely to affect speed is other bus traffic. If you stay inside the CPU, in the cache then external factors such as bus traffic etc. are ruled out.