7

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?

Improve this question

2 Answers 2

Reset to default
2

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...

Improve this answer
1
  • I checked the system at hand: MMU is disabled, except that cacheable and non-cacheable memory areas are defined, the latter one includes the peripheral devices. So, in this situation, only Bus error is a possible source for the access fault exception. Thanks a lot!
    – Hartmut Braun
    Commented Jun 25, 2019 at 11:53
9

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.

Improve this answer
4
  • Thanks. I think on the platform at hand the MMU is deactivated but I have to check this. The caches are enabled. What confuses me is the mixture of bus error, which to me is clearly an error situation, with something that seems to be a rather normal situation, or even used to implement functionality.
    – Hartmut Braun
    Commented Jun 24, 2019 at 17:01
  • I think also on a fork it's not unusual to provide the same pages to both processes as read only, and then perform a selective copying only if either process writes.
    – Tommy
    Commented Jun 24, 2019 at 17:14
  • 2
    @Tommy, yes thx, a good example: copy on write uses write-protection fault but is continuable.
    – Erik Eidt
    Commented Jun 24, 2019 at 18:52
  • Another real-world example: on Windows, there is a "guard page" just above the top of the stack. This allows the stack to grow on demand.
    – MSalters
    Commented Jun 25, 2019 at 10:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .