24.11.2011 21:48, Florian Klämpfl пишет:
Show quoted text 18 lines
Am 24.11.2011 14:59, schrieb Sergei Gorelkin:
> Hello,
>
> There are some differences between FPC and Delphi exception handling
> (working on SEH support, one would inevitably collect all of them):
>
> 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.
>
> 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.
Show quoted text 6 lines
>
> 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.
Show quoted text 18 lines
>
> 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;
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
