<HTML>
<div><style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Thank you so much Ben!  I'm glad I'm not the only person who gets a kick out of assembly language programming!  There's still a place for it even in today's world.</div><div><br>
</div><div>I myself have a passion for games development, and it was partly my driving force behind implementing "vectorcall" for FPC, something which only existed in Microsoft Visual C++ before.  I figured inlined assembler functions for certain mathematical functions would be hugely beneficial for gaming.  I've never got to grips with intrinsics because I'm not sure how much control I get - I prefer dropping into pure assembler.<br>
</div><br>
<div>If you're curious, have a look at the vectorcall tests in the "tests/test/cg" subdirectory of the FPC source (there should be about 4 or so, named tp the theme of "tvectorcall*.pp") - you'll find an implementation of TM128 there as well (also aligned to a 16-byte boundary as required by vectorcall) that, if I recall, has a useful mapping to X, Y, Z and W fields.</div><div><br>
</div><div>It's been a little hard trying to convince Florian of the benefits of inlined assembler routines because of the different assembler platforms that need supporting, which is why I had to design it very carefully in order to a) make sure other platforms don't break, and b) try to be as safe as possible (so no writing to the stack or non-volatile registers, for example, but who knows, maybe the restrictions can be loosened over time when proven safe).<br>
</div><div><br>
</div><div>Gareth aka. Kit<br>
</div><br>
 <br>
<br>
<span style="font-weight: bold;">On Sun 17/03/19 01:54 , "Ben Grasset" operator97@gmail.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"><div dir="ltr">Inlining of pure assembler functions would actually be immediately, specifically useful to me! I've been having a go at improving FPC scores on "BenchmarksGames", and was so far successful with Binary Trees simple by throwing a really good threading library at it, however, there are some benchmarks that simply can't be fixed without either proper intrinsics or user-specifiable inlinable ASM methods. I have a working re-implmentation of NBody (that is just a direct rewrite of the Rust implementation) where I've implemented __m128 and __m128d as records with static nostackframe assembler "class functions", however it's just not fast enough to be competitive due to the inability to inline any of the assembler methods.<div>
<br>
</div><div>Something along these lines is absolutely sorely lacking in FPC currently, don't let anyone tell you otherwise.</div></div><br>
<div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 16, 2019 at 6:03 PM J. Gareth Moreton <<a href="javascript:top.opencompose('gareth@moreton-family.com','','','')">gareth@moreton-family.com</a>> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 
<div>Of course, my worry now is that we've submitted so many patches and issues that we'll just be building an ever-growing back-log that may never be cleared.  It also depends on what Florian's own vision for the future of Free Pascal is, I think.</div><div><br>
 
</div><div>Gareth aka. Kit<br>
 
</div><br>
 
 <br>
 
<br>
 
<span style="font-weight:bold">On Sat 16/03/19 17:05 , "J. Gareth Moreton" <a href="javascript:top.opencompose('gareth@moreton-family.com','','','')" target="_blank">gareth@moreton-family.com</a> sent:<br>
 
</span><blockquote style="border-left:2px solid rgb(245,245,245);margin-left:5px;margin-right:0px;padding-left:5px;padding-right:0px"> 
Normally Florian or another administrator will say if the patch has been applied and mark the ticket as "resolved" if they're happy.  Once they are added I will have a play around.<br>
 
 
<br>
 
 
Admittedly one thing I'm also waiting on is the node XML dump feature ( <a href="https://bugs.freepascal.org/view.php?id=35017" target="_blank">https://bugs.freepascal.org/view.php?id=35017</a> ), since that will allow me to see how procedures are constructed at the intermediate level, plus I sort of need it in order to work out what's going on with <a href="https://bugs.freepascal.org/view.php?id=32913" target="_blank">https://bugs.freepascal.org/view.php?id=32913</a> , something I've vowed to fix but has been sitting dormant for ages now - I'll have to apologise to David Hawk (the reporter) afterwards.<br>

 
 
<br>
 
 
Gareth aka. Kit<br>
 
 
<br>
 
 
 <br>
 
 
<br>
 
 
<span style="font-weight:bold">On Sat 16/03/19 16:07 , Ryan Joseph <a href="javascript:top.opencompose('ryan@thealchemistguild.com','','','')" target="_blank">ryan@thealchemistguild.com</a> sent:<br>
 
 
</span><blockquote style="border-left:2px solid rgb(245,245,245);margin-left:5px;margin-right:0px;padding-left:5px;padding-right:0px"> 
<br>
 
 
 
 
<br>
 
 
 
<span style="color:rgb(102,102,102)">> On Mar 15, 2019, at 9:37 AM, Sven Barth via fpc-devel <<a href="javascript:top.opencompose('fpc-devel@lists.freepascal.org','','','')" target="_blank">fpc-devel@lists.freepascal.org</a>> wrote: 
</span><br>
 
 
 
<span style="color:rgb(102,102,102)">> 
</span><br>
 
 
 
<span style="color:rgb(102,102,102)">> That could maybe be managed once the support for constants as parameter for generics is added (note: I don't know right now how SHUFPS works, so take the following as pseudo code): 
</span><br>
 
 
 
<span style="color:rgb(102,102,102)">> 
</span><br>
 
 
 
 
<br>
 
 
 
I fixed the patch for constants in generics and uploaded again (<a href="https://bugs.freepascal.org/view.php?id=35140)." target="_blank"><span style="color:red">https://bugs.freepascal.org/view.php?id=35140).</span></a> Not sure if they added it yet or they were waiting for my to fix things. Let me know if that patch is in the correct format so I can fix the other one for multi-helpers. 
<br>
 
 
 
 
<br>
 
 
 
Regards, 
<br>
 
 
 
 Ryan Joseph 
<br>
 
 
 
 
<br>
 
 
 
_______________________________________________ 
<br>
 
 
 
fpc-devel maillist - <a href="javascript:top.opencompose('fpc-devel@lists.freepascal.org','','','')" target="_blank">fpc-devel@lists.freepascal.org</a> 
<br>
 
 
 
<a>http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color:red"><a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a></span> 
<br>
 
 
 
<br>
 
 
 
<br>
 
 
 
</blockquote> 
 
_______________________________________________<br>
 
 
fpc-devel maillist - <a href="javascript:top.opencompose('fpc-devel@lists.freepascal.org','','','')" target="_blank">fpc-devel@lists.freepascal.org</a><br>
 
 
<a>http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color:red"><a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a></span><br>
 
 
<br>
 
 
</blockquote>_______________________________________________<br>
 
fpc-devel maillist  -  <a href="javascript:top.opencompose('fpc-devel@lists.freepascal.org','','','')" target="_blank">fpc-devel@lists.freepascal.org</a><br>
 
<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" rel="noreferrer" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a><br>
 
</blockquote></div> 
 

</blockquote></HTML>