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

J. Gareth Moreton gareth at moreton-family.com
Sun Mar 17 21:24:38 CET 2019

 True, the assembler reader needs to be programmed to recognise new
instructions - I myself implemented BMI a few months ago.  That's an issue
with all assemblers... they need to be updated when a new instruction set
comes out.
 I do have a slight concern when it comes to intrinsic support, because
support will be needed to be added for all platforms, (virtually) all
instructions and tested to see if they expand into the expected
instruction, along with determining what happens when you string several
intrinsics together (i.e. passing the result of one such intrinsic into the
actual parameter of another).  I want to say that it will require just as
much, if not more, maintenance than permitting inlined assembler routines
under limited circumstances, including adding intrinsics for every
individual platform's assembly language and showing that it works.

 P.S. I'll make fixes so it bans the use of DB etc in order to emit raw
machine code, as well as catch naughty trickery in order to write to the
stack via another register (it's easy enough to detect if a register has a
dependency on ESP or EBP) - e.g. "mov %rsp, %rax; mov $0, (%rax)" - and
trust me... don't try getting around it by setting a register to zero and
then ADDING the stack pointer to it!

 Gareth aka. Kit

 P.S. It goes to show though... it's always possible to break assembly
language if you try hard enough, whether or not it's inlined.  The
intention behind the restrictions is to prevent as many accidental causes
of it as possible.

 On Sun 17/03/19 20:47 , Martok listbox at martoks-place.de sent:
 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? How about the rest of the
 TBM? AES-NI? Newer AVX? 

 Implementation of these would be a lot easier if they could be written in
 even with native-pascal implementations as drop-ins for platforms that
 support them (or use other mnemonics). Those would just be normal
 (in the RTL or in a package), and not require modifying the compiler for
 It would also be easier to maintain, as there wouldn't be the need for new

 inlinennodes or entirely different node types. 


 fpc-devel maillist - fpc-devel at lists.freepascal.org [1] 


[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/a3f458ec/attachment.html>

More information about the fpc-devel mailing list