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" operato...@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" gar...@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 r...@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@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@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@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
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
