mORMot Open Source

urhen

Member

Registered: 2020-02-13

Posts: 36

Contributing to FPC

Hey ab,
why don't you contribute your assembler implementations for specific functions to FPC?
For instance, your recent MoveFast x86_64 optimized assembly function. It's just one example, there are many other functions in highly optimized assembly code.
Then not only mORMot would profit but also FPC and all other code which uses move().

Regards

Last edited by urhen (2020-02-13 16:31:05)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,673

Website

Re: Contributing to FPC

Last time I checked, any attempt to provide some alternate asm to FPC x86_64 RTL (by Johannes IIRC) was a more or less rejected, for several reasons I don't remember well.
I am not even sure Intel syntax for asm is allowed... the FPC compiler tries to be compatible with external GAS IIRC, whereas mORMot doesn't.
This is why I didn't propose any change yet.

Using such critical code in mORMot first, as testing/validation, and not directly in the RTL is a safe idea anyway.

Anyone is welcome using my code and trying to push it to FPC trunk!
I could of course change the licence of this code to FPC if it helps.

If it works, then I could try to provide a lot of more tuned asm for the most used part of the RTL for x86_64, e.g. for string/array process.

urhen

Member

Registered: 2020-02-13

Posts: 36

Re: Contributing to FPC

Intel syntax shouldn't be a problem any more because GNU Assembler supports it.
"However, since version 2.10, Intel syntax can be used through use of the .intel_syntax directive."

Maybe the best thing is if you could ask on the fpc-devel mailing list? Then it could also be figured out which license is needed etc.
But to be honest, I don't see why patches for optimizing often used functions should be rejected (assume tests for these functions are already there to prove that changes don't break anything).

Last edited by urhen (2020-02-15 14:51:55)

mdbs99

Member

From: Rio de Janeiro, Brazil

Registered: 2018-01-20

Posts: 139

Website

Re: Contributing to FPC

Last time I checked, any attempt to provide some alternate asm to FPC x86_64 RTL (by Johannes IIRC) was a more or less rejected, for several reasons I don't remember well.

I think they don't like code that may not work in all platforms which FPC cover.

urhen

Member

Registered: 2020-02-13

Posts: 36

Re: Contributing to FPC

By the way, FPC also supports Intel assembly by using

  {$ASMMODE INTEL}

directive.

Last time I checked, any attempt to provide some alternate asm to FPC x86_64 RTL (by Johannes IIRC) was a more or less rejected, for several reasons I don't remember well.

I think they don't like code that may not work in all platforms which FPC cover.

That cannot be the reason, e.g. String functions for 32bit (i386), String functions for 64bit (x86_64), generic String functions (if not implemented in assembly) and String functions for 64bit ARM (AArch64). If a specific assembly version of a function is not implemented, it falls back to the generic pascal one. This links are specific for strings but in the directory are some more files with assembly versions of other functions or internal FPC intrinsics (?).

Last edited by urhen (2020-02-23 20:23:15)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,673

Website

Re: Contributing to FPC

Yes, there are IMHO a lot of potential improvements in the /rtl/x86_64/ folder of the RTL.
When you compare /rtl/x86_64/ content to /rtl/i386/ - which is much more complete - it shows some nice possibilities.
The only very efficient part was move() which is bitten by our own MoveFast() version from my tests.

urhen

Member

Registered: 2020-02-13

Posts: 36

Re: Contributing to FPC

Last time I checked, any attempt to provide some alternate asm to FPC x86_64 RTL (by Johannes IIRC) was a more or less rejected, for several reasons I don't remember well.
I am not even sure Intel syntax for asm is allowed... the FPC compiler tries to be compatible with external GAS IIRC, whereas mORMot doesn't.
This is why I didn't propose any change yet.

Using such critical code in mORMot first, as testing/validation, and not directly in the RTL is a safe idea anyway.

Anyone is welcome using my code and trying to push it to FPC trunk!
I could of course change the licence of this code to FPC if it helps.

If it works, then I could try to provide a lot of more tuned asm for the most used part of the RTL for x86_64, e.g. for string/array process.

Check https://bugs.freepascal.org/view.php?id=37039 for more infos
Seems they're open to accept patches with optimized assembly.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,673

Website

Re: Contributing to FPC

@urhen
Here is a first attempt: https://synopse.info/fossil/info/166a84cb5f
Seems to work and give a noticeable but small performance boost - we patch the exe at runtime, so we didn't touch the FPC sources.
Feedback is welcome. This code may find its way to the FPC RTL, I guess.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,673

Website

Re: Contributing to FPC

Update: I have included x86_64 asm patches for fpc_dynarray_* fpc_ansistr_* and fpc_unicodestr_* raw RTL functions.
See https://github.com/synopse/mORMot2/blob … c.inc#L547

There is a small performance boost for sure, but not something as measureable as with our SynFPCx64MM memory manager.