Hi, I am looking forward to implement APX instructions set. APX extend general purpose register count to 32. By reading official documentation about instructions sets from Intel it come to my attention that APX is in Intel's road map for upcoming Diamond Rapids cpu. It will be in metal rather sooner than later (probable year of launch 2026). In Gas (tested ver 2.44) APX support is already implemented. There has been ignored problem with instruction implementation in fpc. Assumption that there is one fixed number of operators for opcode. This is not a case as of today. It is ignored or handled as special cases somewhere in code. As new addition to legacy instructions from map 0 and map 1 is 3 operator version. So most common instructions will have 2 and 3 operator version. The question is how to handle this for days to came? For example in x86ins.data it could be [ADD,addX] (Ch_Mop2, Ch_Rop1, Ch_WOverflowFlag, Ch_WSignFlag, Ch_WZeroFlag, Ch_WAuxiliaryFlag, Ch_WCarryFlag, Ch_WParityFlag) regmem,reg16|32|64    \320\1\x01\101                  8086,SM reg16|32|64,regmem    \320\1\x03\110                  8086,SM (Ch_Wop3, Ch_Rop2, Ch_Rop1, Ch_WOverflowFlag, Ch_WSignFlag, Ch_WZeroFlag, Ch_WAuxiliaryFlag, Ch_WCarryFlag, Ch_WParityFlag) regmem,reg64,reg64    ...                   APX reg64,reg64,regmem    ...                   APX There are multiple options how to go on from here. I have few ideas. I am open to suggestions. As well, I would want to know what I have to take into consideration? I have not started yet. This is good point in time to know if this kind addition to fpc is welcome. Anyhow implementation will take couple of weeks or so. Margers

FPC is always going to be a bit behind the curve because gcc, for example, has corporate sponsors.  Heck, when I interviewed for a role at ARM (which I didn't get), they made clear that they help develop GCC and LLVM directly.  Can't easily compete with the actual CPU manufacturers contributing code!  Still, we do our best.

One thing I'm trying to work on at the moment is auto-vectorisation.  Currently it's just for x86_64, but keeping things as generic as possible for AArch64 support too, and of course, for future Intel instruction sets.

Kit

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