Re: question about linker

On Thu, 12 Dec 2024 09:27:05 +0100
David Brown <david.brown@hesbynett.no> wrote:

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.
>

Arm Cortex-A9 was very popular for enough time to create significant
software legacy. And in majority of situations Cortex-A9 runs
T32-compiled code a little better than an equivalent A32. Also, even
when A32 and T32 run at approximately the same speed, more compact
T32 was a natural default choice for developers. At least for
developers do not care about compatibility with older Arm. Which would
constitute nearly all Android devs that were sufficiently
performance-oriented to write native Arm code in the first place.

"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.
 

In order to lose "long tail" of microcontrollers and of embedded SOCs to
RVor to anybody else Arm would have to screw rather badly. Now, I don't
say that they are incapable of doing so :(
Or, may be, you are not in "long tail". Outside of it things look
different.

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.

Both.

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.

You understand incorrectly.

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.
>

I don't know what others were considering with regard to you trying tcc.
My thought was about replacing compiler without touching linker or the
rest of the tools.

 

 

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.