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

[J. Gareth Moreton]

 I think one of the main issues with intrinsics is that you don't have much
control over where results are stored.  Unless you're chaining a load of
intrinsics together in a mess of function calls in actual parameters, the
result is going to have to be stored in a local variable, which even on
good days will end up being stored on the stack, and problems can occur if
the stack isn't aligned and you're using SSE or AVX instructions.  After
that, when you call the next intrinsic that uses the result, it will have
to recall that data from memory.

 With care, especially if you only need a temporary value, you don't have
to worry about the stack at all or worry in the back of your mind that the
intrinsics aren't being as optimal as they could be.  To use the integer
clamp function as an example (if x < 0 then x := 0):

 { Microsoft x64 calling convention... X is in ECX }
 function ClampInt(X: LongInt): LongInt; assembler; nostackframe; inline;
 asm
   XOR EAX, EAX
   TEST ECX, ECX
   CMOVG EAX, ECX
 end;

 The instructions are arranged in order to reduce the chance of a pipeline
stall, and ECX is written to the result (EAX) only if ECX is greater than
zero, otherwise EAX is set to zero (by the XOR EAX, EAX instruction).

 True, optimiser improvements can improve a lot of the stall situations and
unnecessary storage, but that in itself is a mammoth task.

 Gareth aka. Kit

 On Sun 17/03/19 21:56 , Florian Klämpfl florian at freepascal.org sent:
 Am 17.03.19 um 21:37 schrieb J. Gareth Moreton: 
 > My take on the whole "inlined assembler routines" vs. "intrinsics"... 
 > why not both? 

 Maintenance effort. 

 >They both fill a different niche, 

 What niche do inline assembler routines fill, intrinsics dont't ? This 
 is imo the central question. What can be done by inline assembler 
 routines, intrinsics cannot? 
 _______________________________________________ 
 fpc-devel maillist - fpc-devel at lists.freepascal.org [1] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
------
[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/671b34d9/attachment.html>