(When) Are Precise Exceptions a Must?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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,
http://www.eetasia.com/article_content.php3?article_id88%00265195
(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.

Re: (When) Are Precise Exceptions a Must?
arh snipped-for-privacy@hotmail.com (Anders) wrote in

Quoted text here. Click to load it

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

Re: (When) Are Precise Exceptions a Must?
Quoted text here. Click to load it

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



Re: (When) Are Precise Exceptions a Must?
Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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

Re: (When) Are Precise Exceptions a Must?
Quoted text here. Click to load it
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) <-- causes exception
Inst 2: R3 = R3+1

There's no data (or any other) dependency between the three instruction but
there's no way you can restart the exection and maintain data consistency
unless all the previous conditions are met.

Quoted text here. Click to load it

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



Site Timeline