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

J. Gareth Moreton gareth at moreton-family.com
Sun Mar 17 02:51:30 CET 2019


 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.
 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.

 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.
 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).

 Gareth aka. Kit

 On Sun 17/03/19 01:54 , "Ben Grasset" operator97 at gmail.com sent:
 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. 
 Something along these lines is absolutely sorely lacking in FPC currently,
don't let anyone tell you otherwise.
 On Sat, Mar 16, 2019 at 6:03 PM J. Gareth Moreton  wrote:
  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.
 Gareth aka. Kit

 On Sat 16/03/19 17:05 , "J. Gareth Moreton" gareth at moreton-family.com
sent:
  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.

 Admittedly one thing I'm also waiting on is the node XML dump feature (
https://bugs.freepascal.org/view.php?id=35017 [1] ), 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
https://bugs.freepascal.org/view.php?id=32913 [2] , 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.

 Gareth aka. Kit

 On Sat 16/03/19 16:07 , Ryan Joseph ryan at thealchemistguild.com sent:

 > On Mar 15, 2019, at 9:37 AM, Sven Barth via fpc-devel  wrote: 
 > 
 > 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): 
 > 

 I fixed the patch for constants in generics and uploaded again
(https://bugs.freepascal.org/view.php?id=35140). [3] 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. 

 Regards, 
 Ryan Joseph 

 _______________________________________________ 
 fpc-devel maillist - fpc-devel at lists.freepascal.org 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[4] 

  _______________________________________________
 fpc-devel maillist - fpc-devel at lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[5]

 _______________________________________________
 fpc-devel maillist  -  fpc-devel at lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [6]
  

Links:
------
[1] https://bugs.freepascal.org/view.php?id=35017
[2] https://bugs.freepascal.org/view.php?id=32913
[3] https://bugs.freepascal.org/view.php?id=35140).
[4] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[5] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[6] 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/55d9377a/attachment.html>


More information about the fpc-devel mailing list