assembler

[Curt Carpenter]

For an example of ASM use in FPC, see /fpcsrc/rtl/i386/i386.inc

[Thaddy]

Curt,
Fred is a seasoned programmer.
If he has a problem it is not about using assembler at all.
The problem he has is the tool chain. IOW the correct assembler and linker for the FreeBSD platform.

Maybe Marcov can help him, he is more versed in the BSD stuff, which I only run for tests in VM's.

[Fred vS]

Thanks Thaddy for the adjective!

The problem is in the assembler code of system.ppu.
When cross-compiling fpc himself from Linux arm64 to FreeBSD aarch64, using the info of Pierre from there:
https://downloads.freepascal.org/fpc/snapshot/trunk/aarch64-freebsd/README-fpc-3.3.1.aarch64-freebsd.built.on.x86_64-linux

No problem, the cross-assembler works and assemble system.ppu.
But strangely on a real aarch64 FreeBSD (Rpi3 b) the compilation fails because unknown operand for the "official" as assembler.
See picture of previous post: https://forum.lazarus.freepascal.org/index.php/topic,67915.msg523881.html#msg523881

To resume: fpc 3.3.1 source to binary can be done by cross-compilation but not by direct-compilation.
It is not a big problem only if you want to recompile fpc using your Rpi.

 

[Curt Carpenter]

Curt,
Fred is a seasoned programmer.
If he has a problem it is not about using assembler at all.
The problem he has is the tool chain. IOW the correct assembler and linker for the FreeBSD platform.

Maybe Marcov can help him, he is more versed in the BSD stuff, which I only run for tests in VM's.

I understand that.  I was trying to update the info. I offered the OP Weiss yesterday.  Sorry for the confusion.

[Fred vS]

Hello Curt.

My fault, I shouldn't divert the OP subject. Excuse me.

[Weiss]

gents, I totally took Curt's comment as directed to me, no confusion here. I also have no problem when my thread is stolen, unless we begin discussing politics or religion. Babes and motorcycles ok.

[Seenkao]

The compiler is pretty good at optimizing generated code and while it might have been fruitful to count cycles for old processors it is pretty much undoable to optimize for modern processors to such an extent that is becomes noticeable. Ofc for your particular use-case and setup you might be able to optimize the crap out of things but that doesn't guarantee for the same code to run as smooth on another setup or other use-case.

Компилятор FPC, к сожаленью, не очень хорош в оптимизации кода. Особенно это видно для ARM32/ARM64 архитектруры. Я скидывал проблемы с кодом в багтрекер, его ни кто не рассматривал. Не хотите это исправлять, значит не надо. (да, я знаю что это не просто всё исправить, и вполне возможно показанные мной проблемы взяли отметили для исправления в будущем).

Извиняюсь за оффтоп.


------------------------------------------------------
Google translate:

The compiler is pretty good at optimizing generated code and while it might have been fruitful to count cycles for old processors it is pretty much undoable to optimize for modern processors to such an extent that is becomes noticeable. Ofc for your particular use-case and setup you might be able to optimize the crap out of things but that doesn't guarantee for the same code to run as smooth on another setup or other use-case.

The FPC compiler, unfortunately, is not very good at optimizing code. This is especially noticeable for the ARM32/ARM64 architecture. I posted problems with the code in the bug tracker, but no one looked at it. If you don't want to fix it, then you don't have to. (yes, I know that it’s not easy to fix everything, and it’s quite possible that the problems I showed were taken and noted for correction in the future).

Sorry for the offtopic.

[TRon]

The FPC compiler, unfortunately, is not very good at optimizing code. This is especially noticeable for the ARM32/ARM64 architecture. I posted problems with the code in the bug tracker, but no one looked at it. If you don't want to fix it, then you don't have to. (yes, I know that it’s not easy to fix everything, and it’s quite possible that the problems I showed were taken and noted for correction in the future).

I am aware that FPC does not always produce the most efficient code, especially not for newly added cpu's/platforms. It is a lot of work and requires a special skill set e.g. not many people are proficient with optimizing generated assembler (for a particular CPU). It is getting better of the years though.

I don't consider it to be off-topic because one of the arguments used to to start writing (your own) assembler is because the compiler does such a shitty job (not my words).