[fpc-devel] Successful implementation ofinlinesupportforpureassembler routines on x86

[J. Gareth Moreton]

 On Mon 18/03/19 20:23 , "Jonas Maebe" jonas at freepascal.org sent:
     Similarly, replacing return instructions with jumps is something
you cannot do.

 Why not? There's no other way to make RET work when inlined otherwise it
exits the caller and might even desynchronise the stack.  If the
programmer wants guaranteed, unmodified assembly language in the middle of
a subroutine, there already exists a feature for that: an asm...end block.

 True, this "inline" for pure assembler procedures takes it one step
towards a higher-level language, but this is another reason why what you
can do is limited.  In terms of control and power, I put it between true,
raw assembly language and intrinsics, since you're limited to volatile
registers but have much more control on where temporary values are
stored.  I simply wish to develop a tool for programmer who need that raw
speed and control using semantics that already exist, while making it as
safe as possible.  I myself have a number of uses for the feature, and I
can see where the RTL can benefit too.

 By the way, I updated the patches to patch the trick of assigning RSP to
another register and then deferencing that, and literal byte values via DB
etc are now forbidden.  I do invite you to try to break it.  (It is
overly conservative though... if you do something like MOV RAX, RSP
followed by MOV RAX, RDX (so it no longer depends on RSP) then derefencing
RAX, the compiler will still consider it writing to the stack and forbid
inlining - after all, you're obviously trying to do something unusual)

 I hope that our philosophies don't conflict.  I'm worried.  I want to
find the balance between tradition and revolution, for lack of a better
term.  If you're not allowed to do something, or something must be done in
a particular way, I ask "why?".  Even in some of my other compiler
submissions, I've used repeat...until False loops just because everyone
says that "goto" is bad, but in some situations, I suddenly ask "why?" -
after all, in some situations like in my optimizer overhaul, using "goto"
is actually clearer, while the alternative would be to exit and then
re-enter the procedure and incur a lot of performance penalties due to
performing a number of other checks that we already know the answer to (in
order to call OptPass1MOV, for example).

 Gareth aka. Kit
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190318/5ca56b38/attachment.html>