<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; </style>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.</div><div><br>
</div><div>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).</div><div><br>
</div><div>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.<br>
</div><div><br>
</div><div>Gareth aka. Kit<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Sun 17/03/19 21:14 , Jeppe Johansen jeppe@j-software.dk sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">On 3/17/19 9:58 PM, Florian Klämpfl wrote:
<br>
<span style="color: rgb(102, 102, 102);">> Am 17.03.19 um 21:47 schrieb Martok:
</span><br>
<span style="color: rgb(102, 102, 102);">>> Am 17.03.2019 um 18:57 schrieb Florian Klämpfl:
</span><br>
<span style="color: rgb(102, 102, 102);">>>> How is it better than intrinsics support (similiar to gcc/icc etc.)?
</span><br>
<span style="color: rgb(102, 102, 102);">>> It *exists*?
</span><br>
<span style="color: rgb(102, 102, 102);">>>
</span><br>
<span style="color: rgb(102, 102, 102);">>> Remember how long it took to get PopCnt support?
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> PopCnt is not really an intrinsic as it has a fallback counter part
</span><br>
<span style="color: rgb(102, 102, 102);">> and works on all platforms. Intrinsic means that it is really mapped
</span><br>
<span style="color: rgb(102, 102, 102);">> directly to the CPU instruction without any fallbacks.
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> As the branch of Jeppe shows, it is pretty easy, just requires some
</span><br>
<span style="color: rgb(102, 102, 102);">> continuous work.
</span><br>
<br>
As far as I recall there were some issues in argument passing and
<br>
handling the new __mm128 type that were a little annoying. But it might
<br>
be fairly easy to bring back up to speed again.
<br>
<br>
<span style="color: rgb(102, 102, 102);">>> How about the rest of the BMI? > TBM? AES-NI? Newer AVX?
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> See above.
</span><br>
Agreed if that's the route that's taken. It's my feeling that the newer
<br>
extensions took a much more regular/orthogonal route than the old weird
<br>
MMX and SSE forms.
<br>
_______________________________________________
<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<br>
<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a>
<br>
<br>
<br>
</blockquote></HTML>