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
On 21/05/2025 18:43, Marģers . via fpc-devel wrote:
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-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
