1. Home
  2. Embedded Programming
  3. (When) Are Precise Exceptions a Must?

(When) Are Precise Exceptions a Must?

Can anybody give me examples of when precise exceptions are required?

I know that it is 'nice to have' for debugging if you want to break on data or address match, and 'needed' if you want an exception handler to deal with overflow.

"The architecture does not include either precise exceptions, which would be nearly mandatory in a data-processing environment..." Ron Wilson, EE Times about the FirePath DSP from Broadcom,

formatting link
(requires registration for access)

Anyone who can explain the reason for Ron's claim?

My definition of precise exception in an out-of-order execution machine is as follows:

  1. It is possible to associate any exception with a instruction in the program.
  2. From the exception handler the state of the machine is as if instructions are executed in-order, i.e. all previous instructions in the program flow has been executed and none of the following instructions have been executed.

Thanks in advance for any relevant comments.

Reply to
Anders
Loading thread data ...

arh snipped-for-privacy@hotmail.com (Anders) wrote in news: snipped-for-privacy@posting.google.com:

I can't say if you require this, but I thought that precise exceptions allowed the exception handler to analyze the reason for exception, possibly fix the "problem", and the retry the instruction that caused the exception allowing the program to continue as though nothing "bad" had happened. A TLB miss handler would be a good example of a precise exception (that is required to be so as well).

--
- Mark ->
--
Reply to
Mark A. Odell

I would think that precise exceptions are needed if you plan on retry the instructions after the handler. An obvious example is virtual memory handling. Another would be arithmetic over/under-flows where it's much faster to have an exception handler correct the problem than check for all possible errors after each floating-point operation. Depends on architecture and application though...

Without precise exceptions you cannot do much in the handler but terminating the process.

Regards, Andras Tantos

Reply to
Andras Tantos

Why is it needed if the out of order execution is constrained by data dependencies, i.e. following instructions using the result of the instruction that triggered the exception will not be executed until the return from the exception handler?

Are you thinking of an exception handler that updates the CAM of a TLB when there is no hit? What is the issue in this case? It should not matter what memory access triggers the update of the TLB. Maybe you are thinking of an update of the address mapping, i.e. changing an entry in the TLB to map to another physical address. When does a programmer want to do so?

Regards,

- Anders

Reply to
Anders

the

Maybe I missunderstood something: in my mind precise exception means that the handler has the ability to pinpoint the instruction that caused the exception and can be sure that all the previous instructions completed successfully (with all their side-effects) and none of the proceeding instructions caused any permanent change in the logical CPU state.

Think of the following - rather silly - code sample (not real CPU code of course):

Inst 0: R1 = R1+1 Inst 1: R2 = mem(0x345)

I'm thinking about handling a page-fault i.e. when there's a logical-physical mapping miss. The handler can

- Load the missing page from a storage (HDD) and possibly swapping out some other pages to make room

- Uncompress the page from a part of the memory and possibly compress some other pages to make room and restart the operation. Again: without knowing which exact instruction caused the fault and being certain that the (logical) CPU state is clean in the above mentioned sense there's no way the handler can be sure it's safe to restart the original program after such an operation.

Regards, Andras Tantos

Reply to
Andras Tantos

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.