<html>
<head></head>
<body>
As well Linux kernel have direct patches from Intel and probably from AMD.
<br> FPC is not in race to outrun some.
<br>
<br> I have in mind to break one to one relationship of TAsmOp={$i x8664op.inc} and InsProp : array[tasmop] of TInsProp = {$i x8664pro.inc}
<br> That's what my question is about.
<br>
<br>
<div class="noTransl_fa84df616cd531b81ba9e1cd2e446b82">
----- Reply to message -----
<br>
<strong>Subject:</strong> Re: [fpc-devel] APX instruction set
<br>
<strong>Date:</strong> trešd., 2025. g. 21. maijs 21:37
<br>
<strong>From:</strong> J. Gareth Moreton via fpc-devel <
<a href="mailto:fpc-devel@lists.freepascal.org" target="_blank" rel="noopener noreferrer">fpc-devel@lists.freepascal.org</a>>
<br>
<strong>To:</strong> <
<a href="mailto:fpc-devel@lists.freepascal.org" target="_blank" rel="noopener noreferrer">fpc-devel@lists.freepascal.org</a>>
</div>
<blockquote>
FPC is always going to be a bit behind the curve because gcc, for
<br> example, has corporate sponsors. Heck, when I interviewed for a role at
<br> ARM (which I didn't get), they made clear that they help develop GCC and
<br> LLVM directly. Can't easily compete with the actual CPU manufacturers
<br> contributing code! Still, we do our best.
<br>
<br> One thing I'm trying to work on at the moment is auto-vectorisation.
<br> Currently it's just for x86_64, but keeping things as generic as
<br> possible for AArch64 support too, and of course, for future Intel
<br> instruction sets.
<br>
<br> Kit
<br>
</blockquote>
</body>
</html>