Guidelines on how to use the cache on Falcon?

[Zamuel_a]

I wonder if there are any good guidelines for using the data and instruction cache. I have a 3d application that I wrote in C and assembler but whatever I do with the cache settings is always worse than leave them alone.
I guess the default setting on the Falcon is instruction cache ON and data cache OFF? Atleast that's how it seems to work on my machine since if I enable the data cache my application goes slower than with it off (or leave it at whatever Falcon use as default).

[mikro]

A few years ago Daniel wrote a nice summary about the caches: https://nb.atari.org/main.php?page=prog ... _falcon030.

Also I wrote something about that topic many moons ago: https://mikro.naprvyraz.sk/docs/mikro/030_stram.html.

In short, yes, for tasks like clearing the frame buffer (screen) the data cache is your foe because every written long is written in the cache as well as in memory (write-through). The easiest workaround is to disable the data cache before clearing and then enable it again but Doug had developed a smarter way around: reprogram the PMMU so the frame buffer is marked as 'cache inhibit' by the PMMU.

Data cache enabled is useful for your use case, too: calculating a lot of middle-results (like matrices, 3D math etc) makes accessing stack/variables in memory faster.

Also, when playing with caches, don't forget to flush them first before disabling else you may get very strange and subtle errors. Oh and the burst mode doesn't work on plain Falcon, only with accelerators like CT2/DFB and similar.

[Zamuel_a]

I have read those two articles. They are the only I have found for the Falcon so far.
I don't clear the frame buffer. I draw over it with new textures each frame, but that is maybe the same for the cache, so better disable it when drawing anything.

Is it better to clear the cache when disable it instead of when enable it?

[Eero Tamminen]

I have read those two articles. They are the only I have found for the Falcon so far.
I don't clear the frame buffer. I draw over it with new textures each frame, but that is maybe the same for the cache, so better disable it when drawing anything.

Yes, if your drawing is just writing a lot and not really reading any of that data back.

Note that Hatari profiler can tell you both about i-cache misses, and d-cache hits.

[mikro]

Is it better to clear the cache when disable it instead of when enable it?

Ah, sorry, I should have been more specific. You are correct, on the 030 you have to clear it only when enabling (because if there's some garbage, you enable it and read it immediately, it may contain invalid data).

Writing never leads to incorrect data because it is always written into memory, too. However this is not true for 040+, there you can write something, have it only in the cache and if you disable it, it will never make it to memory. So you have to flush the cache before disabling.

[Zamuel_a]

If I understand correctly the cache reads data in long words, but is it possible to align program code to start at a long addess?

[Cyprian]

If I understand correctly the cache reads data in long words, but is it possible to align program code to start at a long addess?

if I remember correctly the TOS aligns the code to the word address boundary, but if needed you can realign it to the long-word address on your own.

[ThorstenOtto]

No, that cannot be guaranteed. TOS aligns Malloc() calls from STRAM only on an even address, but not necessarily on a long address. Since Pexec() uses Malloc, that also applies to program code. For TTRAM, that is different though. EmuTOS behaves the same.

[ThorstenOtto]

but if needed you can realign it to the long-word address on your own.

That would only work if your program is position-independent. Unless your whole program is written in assembler, that is hardly to achieve.