Hello,

the ARMv5 runtime detection in rtl/arm/arm.inc fails, because the used pld instruction does not raise SIGILL on ARM architectures ARMv4 and below. If you would use an instruction which raises a SIGILL, it would still fail, because SignalToRunerror in rtl/linux/arm/sighnd.inc does not recover correct from the SIGILL.

The problem is now, that the wrong move procedure Move_pld is used instead of Move_blended for ARMv4 which leads to a huge speed penalty (about 25 %) for this architecture.

I would suggest to use conditional compilation to separate between the different ARM architectures.

Regards, Bernd.

Not using pld gives a speed penalty of 500-1000% (!) for ARMv5 :)

I would suggest to use conditional compilation to separate between the different ARM architectures.

At least this is no good solution because it would require that we build two completly different releases.

no question.

I attached a patch, which solves the problem. To be honest: I am not totally sure if this is the right way. I am a newbie concerning Linux and ARM. At least the patch should not break ARMv5 ;-)

Regards, Bernd.

CPUs supporting CLZ might not support PLD. Can you test if using ldrd works?

Florian Klaempfl wrote

CPUs supporting CLZ might not support PLD. Can you test if using ldrd works?

yes, ldrd works.

Regards, Bernd.

Ok, my question was not very good ;) I meant, can we use ldrd, i.e. does ldrd cause a sigill exception on ARMv4?

:-)
I understood your question. Yes, ldrd causes a SIGILL on ARMv4.

Regards, Bernd.

I commited a fix in 10458. I tried to fix SignalToRunerror without assembler, maybe it works.

Florian Klaempfl wrote

I commited a fix in 10458. I tried to fix SignalToRunerror without assembler, maybe it works.

yes it works, thanks.

You chose ldrd r0, [sp] to force the SIGILL on ARMv4. According to the docs the load address has to be double word (8 byte) aligned, otherwise a Bus Error/Misaligned data access Error on ARMv5 would occur. Is it save to use sp in your way?

Regards, Bernd.

ok, it does not work. This is what I guessed. But I am in doubt about your current fix:

   asm
     bic r0,sp,#7
     ldrd r0,[r0]
   end;

r0 is double word (8 byte) aligned now, but does it always point to a valid memory location? IMHO something like that would be better:

procedure fpc_cpucodeinit;
var
    qw: QWord;
begin
{$ifdef FPC_SYSTEM_FPC_MOVE}
   cpu_has_edsp:=true;
   in_edsp_test:=true;
   asm
     ldrd r0, qw
   end;
   in_edsp_test:=false;
   if cpu_has_edsp then
   else
     ;
{$endif FPC_SYSTEM_FPC_MOVE}
end;

It fails too, because qw is not correct aligned (bug/feature), but this is another question ;-)

Regards, Bernd.

Yes, this can be safely assumed imo

Does the ARM ABI require that the stack is aligned to 8 byte boundaries?

Stack is mapped in, and aligned to, pages of 4096 bytes (or bigger), so this is guaranteed to work.

Micha

ok, thanks for the fix.

Regards, Bernd.

Florian Klaempfl wrote

Does the ARM ABI require that the stack is aligned to 8 byte boundaries?

Sorry, I don't know.

Regards, Bernd.