My take on the whole "inlined assembler routines" vs. "intrinsics"... why not both? They both fill a different niche, and as I've stated, my feature doesn't replace intrinstics because you can't directly encode SHUFPS with them, for example. Me personally, if I'm going to be playing around with raw CPU instructions, I rather drop directly into pure assembly language than use intrinsics, but I can see the benefit of using an intrinsic for a single instruction like, say, PREFETCHNTA or MFENCE (which admittedly have wrapper functions for them). For __mm128, I declared a type that resembled it in the "tests/test/cg/tvectorcall*.pp" tests in order to test the vectorcall calling convention. The main sticking point is that it must be aligned to a 16-byte boundary, whereas the System V ABI doesn't have that restriction, I don't think... it just uses the unaligned move operations instead.
Gareth aka. Kit On Sun 17/03/19 21:14 , Jeppe Johansen je...@j-software.dk sent: On 3/17/19 9:58 PM, Florian Klämpfl wrote: > Am 17.03.19 um 21:47 schrieb Martok: >> Am 17.03.2019 um 18:57 schrieb Florian Klämpfl: >>> How is it better than intrinsics support (similiar to gcc/icc etc.)? >> It *exists*? >> >> Remember how long it took to get PopCnt support? > > PopCnt is not really an intrinsic as it has a fallback counter part > and works on all platforms. Intrinsic means that it is really mapped > directly to the CPU instruction without any fallbacks. > > As the branch of Jeppe shows, it is pretty easy, just requires some > continuous work. As far as I recall there were some issues in argument passing and handling the new __mm128 type that were a little annoying. But it might be fairly easy to bring back up to speed again. >> How about the rest of the BMI? > TBM? AES-NI? Newer AVX? > > See above. Agreed if that's the route that's taken. It's my feeling that the newer extensions took a much more regular/orthogonal route than the old weird MMX and SSE forms. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: ------ [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
