What's the difference between Prefetch Abort and Data Abort for ARM processors?
In the book ARM Assembly Language Programming, by Peter Knaggs and Stephen Welsh, the two aborts are defined as following, respectively:
* Prefetch Abort occurs when the processor attempts to access memory that does not exist.
* Data Abort occurs when attempting to access a word on a non-word aligned boundary. The lower two bits of a memory must be zero when accessing a word.
This is to say, when CPU tries to access a memory address that doesn't exist, it will cause prefetch abort, is that right?
Seems not precise. I consulted infocenter.arm.com, and got the following pieces of information:
In ARM7TDMI Technical Reference Manual (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0210c/index.html) , following the subsection 3.6.2 memory Interface > Data timed signals > ABORT:
"ABORT indicates that a memory transaction failed to complete successfully. ABORT is sampled at the end of the bus cycle during S-cycles and N-cycles.
If ABORT is asserted on a data access, it causes the processor to take the Data Abort trap. If it is asserted on an opcode fetch, the abort is tracked down the pipeline, and the Prefetch Abort trap is taken if the instruction is executed."
And, in ARM Developer Suite Developer Guide (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0056d/index.html), following the subsection 5.8 Prefetch Abort Handler:
"If the system has no MMU, the Prefetch Abort handler can simply report the error and quit. Otherwise the address that caused the abort must be restored into physical memory. lr_ABT points to the instruction at the address following the one that caused the abort, so the address to be restored is at lr_ABT - 4. The virtual memory fault for that address can be dealt with and the instruction fetch retried. "
Also in this document, subsection 5.9:
"If there is no MMU, the Data Abort handler should simply report the error and quit. If there is an MMU, the handler should deal with the virtual memory fault.
The instruction that caused the abort is at lr_ABT - 8 because lr_ABT points two instructions beyond the instruction that caused the abort.
Three types of instruction can cause this abort:
Single Register Load or Store (LDR or STR)
The response depends on the processor type:
* If the abort takes place on an ARM7-based processor, including the ARM7TDMI, the address register will have been updated and the change must be undone.
Swap (SWP)
There is no address register update involved with this instruction.
Load Multiple or Store Multiple (LDM or STM)
The response depends on the processor type:
* If the abort takes place on an ARM6-based processor or ARM7-based processor, and writeback is enabled, the base register will have been updated as if the whole transfer had taken place.
In the case of an LDM with the base register in the register list, the processor replaces the overwritten value with the modified base value so that recovery is possible. The original base address can then be recalculated using the number of registers involved.
In each of the three cases the MMU can load the required virtual memory into physical memory. The MMU Fault Address Register (FAR) contains the address that caused the abort. When this is done, the handler can return and try to execute the instruction again."
Conclusion: in the case of ARM7TDMI, neither Data Abort nor Prefetch Abort will be recovered, the handlers will simply report the exception and return. Actually in MMU-less processors, these aborts shouldn't happen anyway. Most of those aborts are caused by improper coding problems.
