Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Thu, 12 Dec 2024 14:13:52 +0200
Organization: A noiseless patient Spider
Lines: 146
Message-ID: <20241212141352.00004f71@yahoo.com>
References: <vi54e9$3ie0o$1@dont-email.me>
	<87frnbt9jn.fsf@nosuchdomain.example.com>
	<viaqh0$nm7q$1@dont-email.me>
	<877c8nt255.fsf@nosuchdomain.example.com>
	<viasv4$nm7q$2@dont-email.me>
	<vibr1l$vvjf$1@dont-email.me>
	<vic73f$1205f$1@dont-email.me>
	<20241129142810.00007920@yahoo.com>
	<vicfra$13nl4$1@dont-email.me>
	<20241129161517.000010b8@yahoo.com>
	<vicque$15ium$2@dont-email.me>
	<vid110$16hte$1@dont-email.me>
	<vifcll$1q9rj$1@dont-email.me>
	<vifiib$1s07p$1@dont-email.me>
	<viht27$2hgg1$3@dont-email.me>
	<vjb8e9$1973q$1@paganini.bofh.team>
	<20241211111856.00005d14@yahoo.com>
	<vjbunl$1h46m$1@dont-email.me>
	<vjcaad$1jcad$3@dont-email.me>
	<20241211192249.000079d6@yahoo.com>
	<vjct1q$1n22j$1@dont-email.me>
	<20241212002639.00005ec2@yahoo.com>
	<vje6op$219uu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Dec 2024 13:12:58 +0100 (CET)
Injection-Info: dont-email.me; posting-host="6d183731774498c4d8f7959a66fdc537";
	logging-data="2234448"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+B0zXYoeUboQHFtP4QrXQLrTsVxeEo09A="
Cancel-Lock: sha1:o432SNIRBg7XSjDkmt9osDDUopg=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 7854

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