Edmund Grimley Evans wrote on Fri, 29 May 2015:

How much freedom do you have in the choice of which exceptions you
detect and when?

In theory: all the freedom in the world. E.g., when using the x87 instructions on x86 hardware, floating point exceptions are (currently) only thrown when the next x87 instruction starts executing following the one that caused the exception. This can be in a completely different part of the program, if you're unlucky, and is due to the origins of the x87 as an independent/off-chip co-processor. For a long time, I've had the idea of adding a compiler switch that optionally emits an "fwait" instruction after every x87 instruction that might cause an exception, but never got around it.

In practice, I think that throwing the exception at the point where it occurs is best. It's true that it's not ideal from a performance perspective, but in that case you can just disable the generation of exception-generating code. We already have an architecture-independent way to raise an exception if the FPU detected an error while its exceptions were masked (using the Math unit as described in my previously referenced post). Therefore you can perform manual checking only at the points you care about in that case (with the caveat that's also mentioned in that previous post, namely that currently this kind of checking is only implemented on AArch64).

Just for a check list, the AArch64 cumulative exception bits are:

IXC : Inexact
UFC : Underflow
OFC : Overflow
DZC : Division by Zero
IOC : Invalid Operation

These are more or less the same on all architectures. The reason is probably that they're mandated by the IEEE 754 standard: http://en.wikipedia.org/wiki/IEEE_floating_point#Exception_handling


Jonas
_______________________________________________
fpc-devel maillist  -  [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to