Re: question about linker

On 11/12/2024 23:26, Michael S wrote:

On Wed, 11 Dec 2024 21:35:06 +0100
David Brown <david.brown@hesbynett.no> wrote:
 

On 11/12/2024 18:22, Michael S wrote:

On Wed, 11 Dec 2024 16:15:25 +0100
David Brown <david.brown@hesbynett.no> wrote:
  

>
Suffice it to say that as far as code generation is concerned, the
Cortex-A devices on the RPi's are completely different from the
Cortex-M devices in microcontrollers.  It's like comparing the
80286 with the Z80A.
 

>
With exception of RPi1, saying so would be an exaggeration.
RPi2 through 5 are technically capable to run Thumb2-encoded user
level routines.

>
I did not know that the 64-bit Cortex-A devices could run 32-bit
Thumb2-encoded instructions.  That does reduce the difference
somewhat.
>

 Support for T32 in ARMv8-A is optional.
In practice, majority of "two-digit" Cortex-A devices support it. There
are only two exceptions - A34 and A65, both rather obscure.

Do you have any thoughts on why it is supported at all?  Who would use it?  I can see support for 32-bit ARM code being of interest on 64-bit Cortex-A devices for backwards compatibility - you can run old RPi 1 binaries on an RPi 4, for example.  But where would you want to run Thumb2 binaries on a 64-bit Cortex-A device - especially when you could not do so on 32-bit Cortex-A predecessors.

"Three-digit", i.e. ARMv9 Cortex-A cores are another story. Most of them
either do not support T32 (and A32) at all, or make it optional for
implemetator.
On the other  hand, nearly all Arm Inc. server cores, even those that
are very closely related to Cortex-A cores, like Neoverse N1 (a variant
of Cotex-A76) do *not* support aarch32.
 

OK - thanks for that information.  My ARM work has primarily been with 32-bit Cortex-M devices (so "ARM architectures" like ARMv7-M and ARMv8-M).  64-bit microcontrollers are not common, as yet.  (There is a 64-bit version of ARMv8-R, but not of the -M architectures.)  Maybe we'll be on RISC-V before 64-bit microcontrollers fit the needs of our customers.
I've used 64-bit Cortex-A devices in embedded Linux systems, but I've not needed to consider the details of the architecture as you typically use these at a higher level of abstraction (at least for usermode code, which is all I have done there).

Compilers targeting 64-bit ARM would generate 64-bit (AArch64)
instructions, which are of course significantly different.

 Understatement detected.
 

  But
perhaps a compiler targeting 32-bit Cortex-A devices might be able to
generate Thumb2 instructions.
>

 Majority of compilers are. But it seems that tcc is not.
Or may be it is. tcc docs are too sparse.
 

I don't think there would be much reason to generate Thumb2 code unless it was for running on microcontrollers.  So it would be a lot of work for a compiler developer for little purpose.  I don't know if tcc targeted 32-bit ARM or 64-bit ARM.  If it is the former, then Thumb2 would be less effort to implement since it is mostly a different encoding of the same instruction set - but it would be of little use since (if I understand you correctly) 32-bit Cortex-A devices don't support Thumb2.  And if tcc supports 64-bit ARM, then the Thumb2 generation would be much more work since it is a significantly different ISA.  And again, how many people actually want Thumb2 binaries for their 64-bit Cortex-A devices?

However, you would not expect binary compatibility between code
generated for a 32-bit Cortex-M device and a Cortex-A platform, even
if it supports Thumb2 instructions - you have major differences in
the ABI, memory layouts, and core features beyond the basic registers.
>

 There are major difference in floating-point parts of the ABI and in
everything related to interrupts. But for integer, it looks like the
T32 ABI is the same.

I'm sure much of it is the same (after all, it is solving the same basic problem), but the details are critical to making things work.  As well as the points you made, I would guess there are differences to the way code and data is addressed - on Linux, you expect dynamic link/loading, and typically have some level of indirection so that it can handle address-space randomisation, linking to dynamic libraries, etc.  On microcontrollers, code is normally compiled and linked for a fixed static memory layout.

 

>

May be, mutual incompatibility with MCUs would become true again in
the next generation of RPi. But more likely it would not happen
until RPi7.

>