[fpc-devel] Exception handling differences with Delphi

Post by Sergei Gorelkin
1) Delphi uses EZeroDivide for floating-point division by zero, while
FPC uses EDivByZero (the same exception class is used for integer
division by zero). Should it be fixed?
2) Delphi uses EUnderflow for floating-point underflow condition, while
FPC uses EOverflow. Should it be fixed?

Noticed that before too when ported my delphi code. I vote yes for both
- it will simplify the porting.

It is better to handle paticular exception types in the user code than
generic Exception class and therefore such differences may cause a
malfunction of the application.

Btw, this article may be very useful for the task you are doing:
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1392

Best regards,
Paul Ishenin

Florian Klämpfl

2011-11-24 18:48:18 UTC

Post by Sergei Gorelkin
Hello,
There are some differences between FPC and Delphi exception handling
1) Delphi uses EZeroDivide for floating-point division by zero, while
FPC uses EDivByZero (the same exception class is used for integer
division by zero). Should it be fixed?

At least a distinction should be made.

Post by Sergei Gorelkin
2) Delphi uses EUnderflow for floating-point underflow condition, while
FPC uses EOverflow. Should it be fixed?

Same here.

Post by Sergei Gorelkin
3) Delphi halts in ExceptProc, while in FPC ExceptProc only prints the
exception information and then returns. I don't imagine why someone
would call ExceptProc from the user code, still, is this worth fixing?

IMO no.

Post by Sergei Gorelkin
4) Delphi resets FPU on every exception, while FPC does it only for
FPU-related exceptions. Do we really need to be different in this respect?

Is there a need to reset it at every exception?

Post by Sergei Gorelkin
5) What is the 'Athlon prefetch bug' we're trying to handle? Should be
an old thing, since it originates from svn revision 1; googling for
'Athlon prefetch bug' does not give relevant information, and my general
knowledge tells that such code should normally reside in OS kernel, not
in RTL. Anyway, does it apply to x86_64 target?

Some old athlons, might include x86_64 ones, had a bug that sometimes
prefetch (0^) causes a sig fault while it shouldn't, prefetch(0^)
happens in the typical use case of prefetch:

while assigned(p) do
begin
prefetch(p^.next^);
...
...
p:=p^.next;
end;

Sergei Gorelkin

2011-11-25 12:57:52 UTC

At least a distinction should be made.

Post by Sergei Gorelkin
2) Delphi uses EUnderflow for floating-point underflow condition, while
FPC uses EOverflow. Should it be fixed?

Same here.

Good, I'll fix these two.

Post by Sergei Gorelkin
4) Delphi resets FPU on every exception, while FPC does it only for
FPU-related exceptions. Do we really need to be different in this respect?

Is there a need to reset it at every exception?

Conditional resetting adds some complication.
Currently this complication is small, but with SEH it grows, because code that maps exception code
to exception class will be moved to SysUtils (I also want to support other missing stuff like
EExternal.ExceptionRecord while at the point), so I'll need to pass 'reset fpu' flag back to code in
System, or use a separate lookup through exception codes.

Therefore I'm trying to evaluate pros and cons.

Some old athlons, might include x86_64 ones, had a bug that sometimes
prefetch (0^) causes a sig fault while it shouldn't, prefetch(0^)
while assigned(p) do
begin
prefetch(p^.next^);
...
...
p:=p^.next;
end;

This means no program using prefetch instructions could execute on such CPU without similar
exception handling. Consequently, either Microsoft fixed it in next service pack, or every complier
vendor would have to fix it independently (in which case it should become much better known over the
Internet). We also don't have similar code in i386-linux RTL.
Maybe it is targeted to support some old Windows?

Regards,
Sergei

Tomas Hajny

2011-11-25 17:10:22 UTC

.
.

This means no program using prefetch instructions could execute on such CPU without similar
exception handling. Consequently, either Microsoft fixed it in next
service pack, or every complier
vendor would have to fix it independently (in which case it should become
much better known over the
Internet). We also don't have similar code in i386-linux RTL.
Maybe it is targeted to support some old Windows?

Isn't the fact that it's missing in i386-linux RTL more an omission of the
respective platform maintainer rather than a hint that it might be
specific to Windows (and specifically to old Windows)?

Tomas

Tomas Hajny

2011-11-25 18:00:49 UTC

Post by Tomas Hajny
.
.

This means no program using prefetch instructions could execute on such
CPU without similar
exception handling. Consequently, either Microsoft fixed it in next
service pack, or every complier
vendor would have to fix it independently (in which case it should become
much better known over the
Internet). We also don't have similar code in i386-linux RTL.
Maybe it is targeted to support some old Windows?

Isn't the fact that it's missing in i386-linux RTL more an omission of the
respective platform maintainer rather than a hint that it might be
specific to Windows (and specifically to old Windows)?

Extending my previous comment after digging a bit more:

1) Google reveals
(http://us.generation-nt.com/update-amd-athlon-opteron-athlon64-prefetch-errata-help-182678371.html)
that current Linux kernel includes a workaround for this problem (I was
able to find the concrete kernel source file with the workaround also).
Apparently, the problem was discovered in 2003 (already in 2.6.x Linux
kernel series). This means that any operating systems / kernels older than
that may suffer. I have no clue whether Microsoft included a fix into one
of their later Windows versions / service packs, nor whether it might have
been fixed for other operating systems (and since when).

2) The AMD docs (referenced from the URL above) explicitly mention the
impacted CPU versions including Athlon64 (and the reference above mentions
that it impacts both the x86 compatibility mode and the x86_64 native
mode).

3) The problem is also mentioned in the post as being quite rare. It
apparently took several years until it was discovered. Linux kernel was
probably patched because it directly triggered it under certain conditions
apparently. Add to that the fact that the impacted AMD CPUs are probably
not so common any longer and you'll see that certainly not all operating
systems nor all compilers need to contain the workaround while that
doesn't mean that the problem would not exist...

Tomas

Florian Klämpfl

2011-11-25 18:27:34 UTC

Post by Tomas Hajny
2) The AMD docs (referenced from the URL above) explicitly mention the
impacted CPU versions including Athlon64 (and the reference above mentions
that it impacts both the x86 compatibility mode and the x86_64 native
mode).
3) The problem is also mentioned in the post as being quite rare.

I was hit by it that's why I implemented it but I don't have the
slightest clue what test program I used.

Sergei Gorelkin

2011-11-25 20:09:50 UTC

Post by Tomas Hajny

Post by Tomas Hajny
Isn't the fact that it's missing in i386-linux RTL more an omission of the
respective platform maintainer rather than a hint that it might be
specific to Windows (and specifically to old Windows)?

1) Google reveals
(http://us.generation-nt.com/update-amd-athlon-opteron-athlon64-prefetch-errata-help-182678371.html)

Yep. Just search for 'AMD Athlon errata', not for 'AMD prefetch bug' :)

Post by Tomas Hajny
that current Linux kernel includes a workaround for this problem (I was
able to find the concrete kernel source file with the workaround also).
Apparently, the problem was discovered in 2003 (already in 2.6.x Linux
kernel series). This means that any operating systems / kernels older than
that may suffer. I have no clue whether Microsoft included a fix into one
of their later Windows versions / service packs, nor whether it might have
been fixed for other operating systems (and since when).

Patch for kernel 2.4 is mentioned on that page, too. Together with 2.6 it probably covers all
possible x86 Linux kernels that FPC can compile for.

Sergei

Tomas Hajny

2011-11-26 15:58:24 UTC

Post by Tomas Hajny

Isn't the fact that it's missing in i386-linux RTL more an omission o=

f the

Post by Tomas Hajny

respective platform maintainer rather than a hint that it might be
specific to Windows (and specifically to old Windows)?

1) Google reveals
(http://us.generation-nt.com/update-amd-athlon-opteron-athlon64-prefet=

ch-errata-help-182678371.html)

Post by Sergei Gorelkin
Yep. Just search for 'AMD Athlon errata', not for 'AMD prefetch bug' :)

Post by Tomas Hajny
that current Linux kernel includes a workaround for this problem (I wa=

Post by Tomas Hajny
able to find the concrete kernel source file with the workaround also)=

Post by Tomas Hajny
Apparently, the problem was discovered in 2003 (already in 2.6.x Linux
kernel series). This means that any operating systems / kernels older =

than

Post by Tomas Hajny
that may suffer. I have no clue whether Microsoft included a fix into =

one

Post by Tomas Hajny
of their later Windows versions / service packs, nor whether it might =

have