[fpc-devel] Exception handling differences with Delphi

Tomas Hajny XHajT03 at hajny.biz
Fri Nov 25 19:00:49 CET 2011


On Fri, November 25, 2011 18:10, Tomas Hajny wrote:
> On Fri, November 25, 2011 13:57, Sergei Gorelkin wrote:
>> 24.11.2011 21:48, Florian Klämpfl пишет:
>>> Am 24.11.2011 14:59, schrieb 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;
>>
>> 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





More information about the fpc-devel mailing list