Generated code and CPU Instruction Cache

[Mrs Beanbag]

If I were to, say, write some sort of high level language compiler or virtual machine JIT would there be any issues with the instruction cache on 68020+? I know that self-modifying code is a bad idea for this reason, so how can I be sure the instruction cache is cleared when I generate some new code? Does Exec handle this when you allocate memory?

[StingRay]

Generate the code and flush the cache afterwards (Exec, CacheClearU) and you're fine.

[Mrs Beanbag]

Well that's nice and simple, thanks!

However, looking at CacheClearE which I could also use if I don't want to clear the data cache as well.

Somehow I have so far gotten away without doing this even after decrunching code. I guess this counts as code that only works by accident and could crash unexpectedly at any time?

This function only exists from AmigaDos 2.0 though, is there any 1.3 compatible way to do this?

[hooverphonique]

Originally Posted by Mrs Beanbag

Well that's nice and simple, thanks!

However, looking at CacheClearE which I could also use if I don't want to clear the data cache as well.

I think you need to flush the data cache as well in case of copyback, otherwise your generated code will not enter ram - the instruction cache does not track the data cache tags, afaik.

Originally Posted by Mrs Beanbag

This function only exists from AmigaDos 2.0 though, is there any 1.3 compatible way to do this?

you need to use dedicated instructions, and they are cpu-specific, ufortunately..

[Toni Wilen]

68040+ needs both caches flushed. CacheClearE() is only useful if you write to some DMA device buffer and you need to guarantee data has been written to memory before you start DMA.

68020/030 caches are so tiny and there is no copyback, it won't cause any problems unless you write self-modifying code that tries to modify cached loop or something similar. Also KS 1.x does not flush CPU caches.

[Leffmann]

If you want it to work without using the cache control functions in 2.0, then you would check the CPU flags in execbase, go into supervisor mode, and explicitly flush affected cache lines. Or just flush the whole caches to keep it simple. I don't think it's something you really need to do on 68020 and 030 because of how small their caches are, but if you want to be thorough:

; 68020
movec   cacr, d0
addq.b  #%1000, d0
movec   d0, cacr

; 68030
movec   cacr, d0
or.w    #%100000001000, d0
movec   d0, cacr
nop

; 68040/060
cpusha  bc
nop

[Mrs Beanbag]

ok just wondering now how Powerpacker &c handles this because I never had any trouble running a powerpacked executable on an 060 and that works on KS 1.3 right?

[thomas]

There is next to no risk that powerpacker uncompresses code into a memory area which was executed short time ago.

PP loads the compressed data into memory, allocates a new memory area for the uncompressed data, unpacks the data and jumps into the uncompressed memory area. It's very unlikely that the memory area which contains the uncompressed code is still in the instruction cache.

[Mrs Beanbag]

Originally Posted by thomas

There is next to no risk that powerpacker uncompresses code into a memory area which was executed short time ago.

PP loads the compressed data into memory, allocates a new memory area for the uncompressed data, unpacks the data and jumps into the uncompressed memory area. It's very unlikely that the memory area which contains the uncompressed code is still in the instruction cache.

But what if the data cache hasn't written it out yet, by the time it gets executed? (Which is presumably immediately)

[Toni Wilen]

Some decompression routines (that does not flush caches) crash very commonly under 68060, it depends on memory usage.

KS 1.3 + 68040/060 won't have data caches enabled (especially copy back) which reduces problems greatly. Data cache requires MMU and AFAIK all mmu libraries require at least 2.0.

[Photon]

Note that CacheClearU (and corresponding raw instruction sequences not supported by all 680x0 CPUs) take *tons* of cycles, plus you've thrown out instructions (and optionally, data) that you WANT to have in the cache (including the ones for the JIT itself), so that you may want to use a less blunt tool to micromanage the icache instead.

[Mrs Beanbag]

well maybe, I only really need to do dynamic linking upon loading modules from disk, rather than actually during execution so it shouldn't be too bad.