CacheClearU during Forbid

[Blueberry]

Is is safe to call CacheClearU() inside a Forbid() / Permit() pair? Can I be sure that the CacheClearU() call will not break the Forbid state? I know it doesn't for the ROM version of CacheClearU() (which just runs appropriate CPU instructions to clear the cache), but is this also the case for any turboboard / emulator environment which might patch CacheClearU()?

Context: In the default Shrinkler decrunch header, the decrunch code and crunched data are deallocated after decrunching is completed. Since the code doing this resides in the memory that is deallocated and A0/D0 need to be restored to make commandline arguments work, I push the entry point on the stack and wrap the deallocation in Forbid() / Permit() like this:

	jsr	Forbid(a6)
	lea.l	Header2-8(pc),a1
	move.l	(a1),d0
	jsr	FreeMem(a6)
	movem.l	(a7)+,d0/a0
	jmp	Permit(a6)

Now, I am changing some things in the code where it would be convenient for the CacheClearU() call (which currently happens right before this code) to happen after the FreeMem() call. Therefore I want to be sure that the Forbid state is not broken by the call.

[ross]

I don't see a single reason why a patched CacheClearU() should break a Forbid().
If it did it would simply be broken.

[Thomas Richter]

Originally Posted by Blueberry

Is is safe to call CacheClearU() inside a Forbid() / Permit() pair?

That's a low-level function that should be callable from almost any CPU state, including from interrupt, and I would call an implementation that breaks the "forbid" quite defect. All the implementations I know (and I made) do not break this, neither Disable().