Ttdfjt

Note: I only have the MC68040 USER'S MANUAL at hand.

In chapter 8.2.1 "Access Fault Exceptions", it is stated that those exceptions can be caused by Bus Error or Internal Access Faults and by that seem to be a replacement of Bus Error (only) for devices without Caches.

Access Fault Exception caused by Bus Error seem clear to me. My question is related to Internal Access Faults. Consider the Statement in the USER'S MANUAL:

Internal Access faults must be corrected to complete execution of the current context.

(The remainder of the section exceeds my expertise)

It seems to me that this statement may be interpreted to mean that Internal Access Faults may happen normally even in a correct program as a side effect of the cache mechanism. In this interpretation, every operating system utilizing MC68040 requires corrective actions (in the corresponding exception handler) in order to continue a program after the exception.

Can this be true?

It seems to me that this statement may be interpreted to mean that Internal Access Faults may happen normally even in a correct program as a side effect of the cache mechanism.

I just downloaded the manual:

If I interpret it correctly, I would say: No

We have to distinguish between cases 1-3 and case 4 described in the manual:

If I understand correctly, cases 1-3 happen if the external hardware (memory) reports some error (bus error?) while being accessed.

However, RAM and ROM normally should not report errors. And you should better not access address regions not containing RAM or ROM (such as peripheral devices) with the cache enabled. So if such a memory region is accessed using the cache enabled, I would not talk about "a correct program" (while "program" includes the OS).

(And yes: Accessing peripheral devices using the cache enabled will definitely lead to unwanted side effects!)

As Erik Eidt already wrote in his answer, Case 4 will definitely happen in OSs that support memory swapping (virtual memory) and similar features. However, this is not a "side effect" of caching but an intended feature of the OS.

Case 4 may also happen if the MMU tries to read some "configuration information" from the memory and the memory reports an error. But (just like in cases 1-3) the configuration information for the MMU should be stored in RAM only and RAM normally does not report errors...

An internal access fault also occurs when the data or instruction MMU detects that a
successful address translation is not possible because the page is write protected,
supervisor only, or nonresident.

(My emphasis.)

So, one major case of an internal access fault is an MMU detected condition, where the page is not resident, i.e. a page fault.

In this interpretation, every operating system utilizing MC68040 requires corrective actions (in the corresponding exception handler) in order to continue a program after the exception.

So, yes the operating system would either have to handle page faults as part of its virtual memory management, or disable the MMU, or configure the MMU so that all pages are resident.

Normally writing to a write-protected page is a fault in the program, which should then be aborted; however, in some environments, a page might be write protected in order to intervene on writes — for example, a debugger might mark a page write protected in order to locate a particular write to that page.  Upon faulting for these a debugger could accomplish the write, and continue the program; a garbage collector might want to intervene on writes so as to track when they occur concurrently with a major collection cycle.

As far as the other causes of internal access fault, here's what I speculate based on reading the text:

Board design: the board can dynamically disable cache operation forcing the CPU to bypass the cache and use main memory.  It seems possible that a dual CPU board or some configuration of other system devices might do this to signal a CPU about shared memory updates.

Apparently also, the board might send signals that cause the CPU to raise an internal access fault.  This might be used to support emulation, where the processor is used to run one (or several) instruction(s) and then suspend execution returning back to the emulator to observe or intervene.