Scott Lurndal wrote:
[snip]
> There are some which have support for A32/T32 at EL0. I've not seen
> any that have A32 support for any higher exception level. (EL0 is
> usermode, EL1 is kernel, EL2 is Hypervisor and EL3 is machine (i.e.
> SMM on intel).
>
> There's really no reason to support AArch32 (A32/T32 encodings) even
> at EL0 anymore.

Decent performance AArch32 support was part of the plan for
AArch64. I seem to recall that it was some years before ARM
provided AArch64 designs that did not provide AArch32.

I suspect you are correct that no new design really needs to
provide AArch32 support for AArch64 implementations. Server/
workstation targets would just use AArch64 (and likely be
mostly running open source or in-house software). Phones and
tablets typically use a centralized application source that
encourages software installation/updating over a network.

[snip]

> There are three architectural profiles for ARMv8 (and ARmv7):
>
> - A (Application - this is the most general and most powerful)
> - M (Mobile - reduced area, reduced power, reduced performance)
> - R (Hard Realtime optimized - most power efficient)

The M profile is Microcontroller (not Mobile). Code density is
also a selling point since microcontrollers I think have a price
premium based on flash capacity (I seem to recall Michael S said
such some time).

On 5/14/2023 10:47 AM, Paul A. Clayton wrote:
> Scott Lurndal wrote:
> [snip]
>> There are some which have support for A32/T32 at EL0.  I've not seen
>> any that have A32 support for any higher exception level.  (EL0 is
>> usermode, EL1 is kernel, EL2 is Hypervisor and EL3 is machine (i.e.
>> SMM on intel).
>>
>> There's really no reason to support AArch32 (A32/T32 encodings) even
>> at EL0 anymore.
>
> Decent performance AArch32 support was part of the plan for
> AArch64. I seem to recall that it was some years before ARM
> provided AArch64 designs that did not provide AArch32.
>
> I suspect you are correct that no new design really needs to
> provide AArch32 support for AArch64 implementations. Server/
> workstation targets would just use AArch64 (and likely be
> mostly running open source or in-house software). Phones and
> tablets typically use a centralized application source that
> encourages software installation/updating over a network.
>

Yeah.

For the phone use-case, the CPU ISA almost doesn't matter. As long as
the programs in the "app store" are whatever are built for the type of
phone in question, it doesn't matter.

Could be done in various ways:
A VM, like in Android;
Fat binaries for every target, apparently what Apple uses;
Submit source-code to app store, store builds it for every target (1).

1:
Not entirely sure why this isn't more common;
Unless maybe the "dev's being protective" thing;
Except that the company probably has little real use for any of the code
in any of the apps (99% of the time, there isn't likely to be anything
they couldn't easily write themselves if they wanted; and typically none
of the creative aspects are protected by keeping the code private).

End user experience is likely to be similar in any case.

For Linux, it is also mostly hidden, since stuff usually either comes
from an OS repository or is built directly from source on the target
machine.

Unlike Windows, where one has to be sure to download the correct version
whenever downloading something if using an unusual target (and building
stuff from source is rarely such a hassle-free process).

> [snip]
>
>> There are three architectural profiles for ARMv8 (and ARmv7):
>>
>>    - A (Application - this is the most general and most powerful)
>>    - M (Mobile - reduced area, reduced power, reduced performance)
>>    - R (Hard Realtime optimized - most power efficient)
>
> The M profile is Microcontroller (not Mobile). Code density is
> also a selling point since microcontrollers I think have a price
> premium based on flash capacity (I seem to recall Michael S said
> such some time).

Yeah, it is usually 'A' cores in cellphones...

But, a lot of the options like A53 and A55 were in-order designs.
For a long while, pretty much everything seemed to be using one of these
two.

Cortex-M cores are mostly using Thumb2 and similar as their primary ISA.
Generally all 32-bit designs (with RAM sizes usually measured in kB).

Meanwhile, I recently went and (more or less) ported TestKern (at least
the userland parts) to building on RV64; partly intending to "hopefully
actually test this stuff".

Ironically, the test binaries built with just the C library and similar
for RV64 come out larger than those with all the kernel functionality
also linked in for BJX2. This is curious as past tests implied that
GCC+RV64 executes less dynamic instructions, ...

Though, a likely difference here is possibly because BGBCC does a
graph-walk and only includes functions and variables which are "actually
reachable" by the program, whereas with GCC, "basically everything" ends
up included in the binary (at least short of doing like some other C
libraries and putting each library function in its own translation
unit). So, a lot of otherwise unused functions in the C runtime end up
being included in the final binary.

Also recently had sort of a random idea that it could be theoretically
possible to run a full RV64 Linux distro on the BJX2 core by essentially
using TestKern like a hypervisor and then emulating all the privileged
ISA stuff and hardware interfaces in software...

Would be kind of a waste, but theoretically possible at least.

There is also now XG2RV mode as well, but as-is, the different C ABI
would effectively break all the existing ASM code.

Did add some ASM-level pseudo registers, A0..A15 and AR/AR0/AR1 which
will map to different registers based on which ABI is in effect, but
this isn't likely to scale well (as the number and location on any other
scratch registers and any preserved registers also moves around).

But, say:
A0..A7: (Argument)
BJX2 Mode: R4..R7, R20..R23
XG2RV Mode: R10..R17
AR0/AR1: (Return)
BJX2 Mode: R2, R3
XG2RV: R10, R11
T0..T6: (Temporary)
BJX2 Mode : R1, R2/R3, R16..R19
XG2RV Mode: R5, R6/R7, R28..R31
S0..S11: (Saved)
BJX2 Mode: R8..R13, R24..R29
XG2RV Mode: R8, R9, R18..R27
S12..S15:
BJX2 Mode: R30, R31, R14
XG2RV Mode: N/A

But, non-trivial ABI agnostic ASM code is unlikely to be particularly
workable.

....

In article <u3rdil$2ncvk$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:

> Submit source-code to app store, store builds it for every target (1).
>
> 1: Not entirely sure why this isn't more common;
> Unless maybe the "dev's being protective" thing;

There's s significant difference in mindset between commercial and
open-source development. Commercial developers are generally concerned
about trade secrets. This may or may not be justifiable, but that's how
they feel.

There's also the issue of trusting compilers that you have not tested
yourself. The code I work on is a tough case for that, because it has
lots of iterative numerical algorithms, and switching compiler on an
existing platform is usually quite a bit of work. App stores would not be
interested in taking everyone's test data and running all their tests.

John

"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>Scott Lurndal wrote:
>[snip]
>> There are some which have support for A32/T32 at EL0. I've not seen
>> any that have A32 support for any higher exception level. (EL0 is
>> usermode, EL1 is kernel, EL2 is Hypervisor and EL3 is machine (i.e.
>> SMM on intel).
>>
>> There's really no reason to support AArch32 (A32/T32 encodings) even
>> at EL0 anymore.
>
>Decent performance AArch32 support was part of the plan for
>AArch64. I seem to recall that it was some years before ARM
>provided AArch64 designs that did not provide AArch32.

Within ARM, perhaps. But Marvell's first design (ThunderX)
almost a decade ago now only supported AArch64. I don't believe
that any of the Apple M1 AAarch64 cores ever supported AArch32.

>> There are three architectural profiles for ARMv8 (and ARmv7):
>>
>> - A (Application - this is the most general and most powerful)
>> - M (Mobile - reduced area, reduced power, reduced performance)
>> - R (Hard Realtime optimized - most power efficient)
>
>The M profile is Microcontroller (not Mobile).

Noted.

>Code density is
>also a selling point since microcontrollers I think have a price
>premium based on flash capacity (I seem to recall Michael S said
>such some time).

Yes, the M7 supports only the T32 instruction set.

In article <XEq8M.624246$5CY7.6104@fx46.iad>, scott@slp53.sl.home (Scott
Lurndal) wrote:
> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
> >Decent performance AArch32 support was part of the plan for
> >AArch64. I seem to recall that it was some years before ARM
> >provided AArch64 designs that did not provide AArch32.
>
> Within ARM, perhaps. But Marvell's first design (ThunderX)
> almost a decade ago now only supported AArch64. I don't believe
> that any of the Apple M1 AAarch64 cores ever supported AArch32.

The M-series chips have never supported AArch32, but Apple's A-series
chips up to the A10 did. That was introduced in 2016 and ceased
production in 2022. Apple started their phase-out of AArch32 from their
operating systems early and aggressively.

John