<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>