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

[J. Gareth Moreton]

Hi Florian,

I think the main thing is that Object 
Pascal has always supported the ability to 
drop into assembly language, unlike C++ 
which requires a dialect-specific 
extension and is not allowed at all under 
Microsoft Visual C++ 64-bit. Allowing 
certain assembler routines to be inlined 
seems like a logical extension using 
language semantics that already exist.

Part of it may be preference but I think 
some people like the fine degree of 
control that assembly language offers, 
while intrinsics, I find, can quickly get 
somewhat untidy and confusing, especially 
with instructions like CPUID that read and 
write to specific registers (although my 
code forbids that instruction because EBX 
is non-volatile).

The other thing... no matter how good the 
compiler is, there are some situations 
where assembly language will always 
perform better.

I suppose I would like to ask the 
community more than anything. Is this a 
feature that you'd like to see and use?

I hoped the way that I designed the patch 
helps to alleviate the can of worms by 
simply not allowing inline if the platform 
doesn't have the ability to support it 
yet. "CanInline" simply returns False 
unless overridden.

Gareth aka. Kit

On Sun 17/03/19 17:37 , Florian Klämpfl 
florian at freepascal.org sent:
> Am 15.03.19 um 11:32 schrieb J. Gareth 
Moreton:
> 
> > Hi everyone,
> 
> > 
> 
> > Sorry for the slightly long-winded 
title. 
> This was something I've been 
> > working on for the past few weeks to 
allow the
> use of "inline" with 
> > certain x86 assembler routines, 
subject to
> restrictions for safety 
> > reasons.  I have successfully written 
code
> that implements this support 
> > while ensuring it doesn't affect 
platforms with
> a different assembly 
> > languages.  Regression tests have 
passed,
> as have some new tests, some 
> > of which test modified RTL assembler 
functions
> that have had "inline" 
> > added to their list of directives.
> 
> 
> 
> As said before, I have a lot of concerns 
against this as it opens a can 
> 
> of worms hard to handle:
> 
> * using inline assembler is always the 
worst solution to do something, 
> 
> it normally means either:
> 
> - the compiler misses a certain feature
> 
> - the compiler is generating bad code
> 
> * intrinsics provide a much better way 
to achieve exactly what this 
> 
> approach aims at:
> 
> - they enable the use of all registers 
as the compiler does register 
> 
> allocation
> 
> - constraints on instructions (like a 
certain operand needs to be a 
> 
> constant) can be easily forced
> 
> 
> 
> Is there any advantage over intrinsics, 
I missed so far?
> 
> 
> 
> > 
> 
> > There was a previous concern about it 
breaking
> too much and it being 
> > impossible to implement on all 
platforms - the
> latter point may be true, 
> > but through the careful use of virtual 
methods
> within the compiler, it 
> > should be possible to extend the 
inline support
> one platform at a time 
> > without breaking the others.
> 
> > 
> 
> > All the details, including a PDF 
specification
> that explains the design 
> > and implementation choices, a couple 
of existing
> tests that touch on the 
> > functionality, along with any new 
tests,
> limitations or problems found, 
> > can be found here: 
https://bugs.freepascal.org/view.php?
id=35232
> > 
> 
> > I hope it proves to be insightful and 
useful.
> 
> > 
> 
> > Gareth aka. Kit
> 
> > 
> 
> > P.S. Though this feature can be used 
for
> implementing intrinsics, it is 
> > not a direct replacement for them 
because
> instructions like SHUFPS 
> > cannot be flexibly encoded due to its 
immediate
> operand (i.e. it has to 
> > be a raw number... it can't take its 
value from
> a parameter).
> 
> 
> Well, with intrinsics, this can be 
easily done.
> 
> 
__________________________________________
_____
> 
> fpc-devel maillist  -  fpc-
devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-
bin/mailman/listinfo/fpc-devel
> 
> 
> 
>