[fpc-devel] Successful implementation of inline support forpureassembler routines on x86

[J. Gareth Moreton]

 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 jeppe at 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 at 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 at lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190317/9e854364/attachment.html>