[fpc-devel] Proof of concept. Inline support for pureassemblerroutines on x86

J. Gareth Moreton gareth at moreton-family.com
Sun Feb 17 13:54:52 CET 2019

 There are some good examples out there where being able to directly inline
assembler routines has beneficial importance but where intrinsics don't cut
it.  One example is the following:

 function GetClockTics_RDTSC: QWord; assembler; nostackframe; inline;
 {$ifdef CPUX64}
   SHL RDX, 32

 Taken from:
Tue 12/02/19 11:51 , "J. Gareth Moreton" gareth at moreton-family.com sent:
  And this e-mail contains additional files to aid with testing and

 - x86-inline-assembler-rtl-samples.patch - makes some internal RTL
functions inline, like Trunc, since it's just a single instruction.
 - x86_inline_asm_test.pp - an x86-64 test program that has some
hand-written assembler routines that have been inlined.  The output should
be identical whether or not "inline" is specified.

 Additionally, "tests/test/cg/tvectorcall3.pp" has an assembler function
that is inlined, and this can be used to test if it works properly for
vectorcall under Win64 and the regular System V ABI under Linux (it only
uses the XMM registers, so the registers that are used for the parameters
and the return value are identical).

 Gareth aka. Kit

 On Tue 12/02/19 11:43 , "J. Gareth Moreton" gareth at moreton-family.com
  This is something I've been researching for a while, the ability to
inline procedures that are written in pure assembler, and I've got
something working pretty well and I'd like to showcase it.

 It's something that's garnered a little uncertainty from others because of
how easy it is to introduce compiler bugs and offer support on other
platforms, for example.  Currently, my code is restricted to i386 and
x86_64 because that's all I can actually test on.  Nevertheless, the new
virtual methods will easily allow extension to other CPUs while blocking
"inline" on pure assembler routines by default.

 There are a number of restrictions on what can and can't be inlined,
 - The routine must have the "nostackframe" directive.
 - You cannot write to the stack.
 - No parameters or return values must be on the stack.
 - You cannot write to a non-volatile register.

 ... among a few others.  The internal procedure checks commands against
the "InsProp" array (although a number of the opcodes just have "Ch_All"
specified, which my code assumes to mean that everything is modified, hence
it marks the procedure as 'cannot inline').

 I've so far built this on x86_64-win64, i386-win32 and x86_64-linux (I
couldn't do i386-linux due to problems with missing tools, but it gets
quite far in the compilation otherwise - if someone can do a more strenuous
test, I'd be grateful) and done some tests with internal functions and some
showcase functions, with promising results.

 Some other things that the inlining routine does:
 - If jumps and labels are found, new local ones are generated.
 - If RET is found, it is changed to a JMP and a new destination label
generated at the end of the inserted code.
 - The markers at the beginning and end are removed, so peephole
optimisation is actually performed on the inserted code - this is mostly to
address some inefficiencies that crop up from moving parameters into the
expected registers (e.g. the first integer parameter into RCX under Win64).

 To Florian, I know this work is somewhat unsanctioned, but I would like to
show that it can be done in a way that's clean.  Even if this is still a
definite no, well, I managed to find and squash bug #35065!

 Another e-mail will follow this one that adds a patch that inlines some
RTL routines, and a small test program.

 Gareth aka. Kit
 NOTE: Make sure you have the current trunk, because this code triggered
Internal Error 200208181 due to a bug in "tai_cpu_abstract.ppuload" that
was only fixed this morning.

 fpc-devel maillist - fpc-devel at lists.freepascal.org

 fpc-devel maillist - fpc-devel at lists.freepascal.org


[1] http://secureweb.fast.net.uk/ http:=
[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/20190217/7cd57b53/attachment.html>

More information about the fpc-devel mailing list