Hi everyone,

I've started to look at developing FPC on the Raspberry Pi again, but I've run into a snag.

The unmodified trunk does not build - it fails when building system.pp at the ppc1 stage:

math.inc(57,7) Error: Assembler syntax error
math.inc(58,11) Error: Unrecognized opcode round
flt_core.inc(459,47) Error: Can't evaluate constant expression
flt_core.inc(461,10) Fatal: Syntax error, ")" expected but "," found

I remember noticing that AArch64 does not yet support inline assembly, which is what math.inc contains at the lines indicated (although "round" is inside a constant, so... what gives?!).  Not sure how to get around the issue with flt_core.inc just yet.

Gareth aka. Kit

(On another note, a number of AArch64 opcodes are missing, notably ADDS (add and set flags) and similar instructions - granted, a64ins.dat just lists the instructions and is devoid of any syntax encoding, which I think is partly why inline assembly is not yet implemented)

How do you build for Aarch64 (your command line)? I assume your host is arm-linux?

I remember noticing that AArch64 does not yet support inline assembly, which is what math.inc contains at the lines indicated (although "round" is inside a constant, so... what gives?!).  Not sure how to get around the issue with flt_core.inc just yet.

Of course it supports inline assembly. Where did you get that nonsense?

Regards,
Sven

Okay, found the problem. Please try again with r47123.

Regards,
Sven

J. Gareth Moreton wrote

(On another note, a number of AArch64 opcodes are missing, notably ADDS (add and set flags) and similar instructions -

This is done by opcode prefixes.

Ah, thanks Florian.

Gareth aka. Kit

Hi Sven - thanks for the quick check.  I'm out of the house currently so I can't try it out immediately, but I'll try it out later this evening.  By the way, both my source and target are aarch64-linux (I'm using the prototype aarch64 build of the Raspberry Pi OS, athough I have an SD card with the standard 32-bit Arm Raspian as well).

In regards to it not supporting inline assembly, it might only be applicable to FPC 3.2.x, as I tried to write some customised assembly language but was getting unrecognised opcode errors for instructions that definitely exist (like LDR).

Gareth aka. Kit

So you used 3.2.0 aarch64-linux as starting compiler? (though the question isn't important anymore as the problem was somewhere else)

In regards to it not supporting inline assembly, it might only be applicable to FPC 3.2.x, as I tried to write some customised assembly language but was getting unrecognised opcode errors for instructions that definitely exist (like LDR).

3.2.0 also supports inline assembly for aarch64. And LDR works as well as the following code in the Rtti unit from 3.2.0 shows:

=== code begin ===

const
   RawThunkPlaceholderProc = $8765876587658765;
   RawThunkPlaceholderContext = $4321432143214321;
type
   TRawThunkProc = PtrUInt;
   TRawThunkContext = PtrUInt;

procedure RawThunk; assembler; nostackframe;
asm
  ldr x16, .LProc
  ldr x0, .LContext
  br x16
.LProc:
  .quad RawThunkPlaceholderProc
.LContext:
  .quad RawThunkPlaceholderContext
RawThunkEnd:
end;

=== code end ===

So you probably either used something that's definitely not supposed to be supported or something that the assembly reader does not yet handle correctly (e.g. I had to fix 3.1.1 so that the code above is handled correctly)

Thus if you have such code and it doesn't work please report it.

Regards,
Sven

I can't remember for sure - it might have been 3.0.4, so I'm probably asking for trouble now.  When I get back later I'll check for sure and try a few things and get back to you.  At least it's confirmed that it actually did not compile!

For the curious, I'm looking to implement the optimisation of converting a division by a constant into a multiplication and a shift for AArch64, inspired by me playing around with my own assembly-written generator function in the other e-mail thread.  I made the comment about ADDS, forgetting about suffixes, because of how 'magic add' is handled when required (e.g. when dividing by 7 for 32-bit).

Gareth aka. Kit

I've just seen the change you've made Sven (just looking it via diff, not actually testing the code)... do the standard Pascal comments seriously cause a problem in AArch64 assembly blocks?  Do the braces have an actual syntactic use on that platform?  That seems like an incredibly awkward design.

Gareth aka. Kit

J. Gareth Moreton wrote

I've just seen the change you've made Sven (just looking it via diff, not actually testing the code)... do the standard Pascal comments seriously cause a problem in AArch64 assembly blocks?  Do the braces have an actual syntactic use on that platform?

Just like with plain ARM, some instructions in AArch64 accept register sets. The syntax for a register set for both ARM and AArch64 is "{ rX, rY }".

Jonas

Aah, I see - thanks Jonas.  That's a little awkward - presumably we can't change it to round brackets instead since that's a bit of a clash that can't easily be remedied, especially as such comments are fine in other inline assembly languages.

Gareth aka. Kit

J. Gareth Moreton wrote

Aah, I see - thanks Jonas.  That's a little awkward - presumably we can't change it to round brackets instead since that's a bit of a clash that can't easily be remedied, especially as such comments are fine in other inline assembly languages.

Technically it would be possible, but we want to be as close as possible to the native platform assembly language so that people don't need to search for how it might work.

Regards,
Sven

That's a point, yeah.  It's just difficult because, on Lazarus for example, anything inside braces is coloured as if it were a comment in an asm block.  Changing this so it appears the same colour as the rest of the assembly code when on Arm platforms would help reduce the confusion, although that's another story, and I'm not sure what the policy is on platform-specific syntax highlighting.

Gareth aka. Kit