[fpc-devel] Kit's ambitions!

[David Pethes]

Hi,
I would welcome inlining of (simple) asm routines. Lately I wanted to
use the BEXTR instruction to speed up some inlined bit reading
functions. As there's no intrinsic for it and including even a simple
assembly method disables inlining, it didn't go well.

As for using a BEXTR intrinsic instead: I'd like to try to add it, if
it's welcomed. Judging by searching for POPCNT it shouldn't be that much
work, but I'm likely to miss something - any advice is welcomed.
There's at least one catch that I know of - there's no CPU target that
supports BMI1 but not BMI2 (there are several such AMD cpu-s), so it
should be added as well.


David

On 13. 5. 2018 4:28, J. Gareth Moreton wrote:

> - Research possibility for 'inline' support for certain assembler routines.
> 
> For situations where speed is of the highest priority, there are some
> internal functions such as Int and Frac that can theoretically be
> inlined (a procedure call is quite expensive, around 50 cycles), but
> because they are written in pure assembly language, the compiler will
> never inline them.  I'm still working out quite a bit of theory, but I
> believe I will be able to allow the inlining of routines that are leaf
> functions (don't have CALLs of their own) and declared as
> 'nostackframe'.  Such a system would allow the support of 'intrinsics'
> that can be composed programmatically rather than as internal routines,
> though it's not exactly what Florian is planning. Even if Florian does
> go for a different approach for intrinsics, I like to think that such
> inline support will have uses elsewhere, especially some of the routines
> like "GetStackFrame" (I think) that simply return the value of RSP (if
> it's 'inline', which it is actually declared as in the unit, the return
> value will be far more accurate).