Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2013-03

position of External: SIGFPE

4 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Xiangrong Fang

Hi,

Why the "External: SIGFPE" error not reported on the line it was generated? e.g. In the following code:

1: if SomeCondition then begin
2:   Y := exp(Y);
3: end;
4: d := Data[X];

The SIGFPE is generated on line 2, because Y is too big. But while the program is running in IDE, it told me that line 4 is generating SIGFPE?

Reply by email

Jonas Maebe
to Xiangrong Fang
Xiangrong Fang wrote 12 lines
Why the "External: SIGFPE" error not reported on the line it was generated? e.g. In the following code: 1: if SomeCondition then begin 2: Y := exp(Y); 3: end; 4: d := Data[X]; The SIGFPE is generated on line 2, because Y is too big. But while the program is running in IDE, it told me that line 4 is generating SIGFPE?

Because that is how the 80x86 architecture works. Back when the original 8086 came out, the FPU was a separate co-processor you had to plug in. It worked in parallel with the main cpu (so the cpu didn't wait for the co-processor to finish with an instruction before continuing), so when it wanted to raise an exception it waited for the next FPU instruction to be dispatched rather than do so immediately (so the exception would always be raised in the same place, rather than at a random address). The FPU had no clue about the address of the original instruction, and hence could not report it.

We are now several decades later, but for compatibility reasons the FPU on the x86 processors still uses the same logic. It is possible to get the exception at the place where it happened by inserting fwait instructions after every fpu operation. Those tell the cpu to stop executing until the FPU has finished executing the previous instruction. That obviously slows down the code significantly. FPC has no option to do this.

Jonas

Reply by email

Xiangrong Fang
to Jonas Maebe
We are now several decades later, but for compatibility reasons the FPU

on the x86 processors still uses the same logic. It is possible to get the exception at the place

where it happened by inserting fwait instructions after every fpu

operation. Those tell the cpu to stop executing until the FPU has finished executing the previous

instruction. That obviously slows down the code significantly. FPC has no

option to do this.

It is a pity. I think this would be a very useful option for development. Will the team consider adding this ? :-)

Reply by email

Lukasz Sokol
to Xiangrong Fang
Xiangrong Fang wrote 11 lines
> We are now several decades later, but for compatibility reasons the > FPU on the x86 processors still uses the same logic. It is possible > to get the exception at the place where it happened by inserting > fwait instructions after every fpu operation. Those tell the cpu to > stop executing until the FPU has finished executing the previous > instruction. That obviously slows down the code significantly. FPC > has no option to do this. It is a pity. I think this would be a very useful option for development. Will the team consider adding this ? :-)

Consider defining your floating-point-fpu-using operators with inline assembler fwait instruction added ? If possible...

L.

Reply by email