RISC OS 5 (Open) and ARM64

[Joseph Harley]

Greetings all,

I was informed by a good friend today that most of the chip fabs have
announced that by 2022, they will no longer be making 32-bit ARM core,
and will move only to ARM64; which begs the question, what will happen
to RISC OS 5 (Open) when the 32-bit boards go out of production.

The problem is, looking at the code, fairly large chunks of the OS are
still written in ARM assembly, and I've heard that because the ARM64
cores are so different, it's not possible to use the old assembly, ROOL
would have to translate and rewrite all the current assembly code.

The problem is, ROOL doesn't have the manpower to do a full rewrite, the
logical thing to do would be to rewrite all of the assembly stuff in C
(or Rust if you wanted to be fancy), but as mentioned, this might be
even more unrealistic.

So what are our options? I know there is quite a heavy support of
emulation-only; it might be feasible to have ARM64 quietly start up a
hypervisor at boot, and then run RISC OS in 32-bit emulation mode, but
then that opens up another can of worms with what OS will boot up that
hypervisor, and the fact that you wouldn't be able to interact with
ARM64 from within RISC OS.

I'm genuinely stumped on what to do, I missed the whole ARM26 panic, so
I can't think of what we did last time. Any other thoughts would be
greatly appreciated!

Thanks,

- Joe. H

[Martin]

In article <s7d8f4$lc4$1...@dont-email.me>,

Joseph Harley <joerebel...@protonmail.ch> wrote:

> I was informed by a good friend today that most of the chip fabs
> have announced that by 2022, they will no longer be making 32-bit
> ARM core, and will move only to ARM64; which begs the question,
> what will happen to RISC OS 5 (Open) when the 32-bit boards go out
> of production.

[Snip]

There is a long discussion post on the ROOL website about this - see
https://www.riscosopen.org/forum/forums/5/topics/15704

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

[Joseph Harley]

On 11/05/2021 09:56, Martin wrote:
> [Snip]
>
> There is a long discussion post on the ROOL website about this - see
> https://www.riscosopen.org/forum/forums/5/topics/15704
>

Ah, that's handy, thanks very much! ;)

--
Joe Harley

Certified RISC OS and Acorn freak.

Still uses RISC OS 5 almost daily.

Has a pretty much empty website @ https://jharley.codeberg.page

Mildly updated Gemini capsule @ gemini://tilde.club/~rebello

Can also be found on IRC: rebello @ freenode

[Harriet Bazley]

On 11 May 2021 as I do recall,

Martin wrote:

> In article <s7d8f4$lc4$1...@dont-email.me>,
> Joseph Harley <joerebel...@protonmail.ch> wrote:
>
> > I was informed by a good friend today that most of the chip fabs
> > have announced that by 2022, they will no longer be making 32-bit
> > ARM core, and will move only to ARM64; which begs the question,
> > what will happen to RISC OS 5 (Open) when the 32-bit boards go out
> > of production.
>
> [Snip]
>
> There is a long discussion post on the ROOL website about this - see
> https://www.riscosopen.org/forum/forums/5/topics/15704
>

Once you've thrown out conditional execution and all the current
operators, in what sense will the '64 bit ARM' chips be ARM at all?

--
Harriet Bazley == Loyaulte me lie ==

We are not punished for our sins, but by them.

[druck]

On 12/05/2021 12:02, Harriet Bazley wrote:
> Once you've thrown out conditional execution and all the current
> operators, in what sense will the '64 bit ARM' chips be ARM at all?

The fact that ARM designs them.

---druck

[Joseph Harley]

On 12/05/2021 12:02, Harriet Bazley wrote:

> Once you've thrown out conditional execution and all the current
> operators, in what sense will the '64 bit ARM' chips be ARM at all?

Exactly, this is one of my many worries - they won't be.

[Harriet Bazley]

On 12 May 2021 as I do recall,

Joseph Harley wrote:

> On 12/05/2021 12:02, Harriet Bazley wrote:
> > Once you've thrown out conditional execution and all the current
> > operators, in what sense will the '64 bit ARM' chips be ARM at all?
>
> Exactly, this is one of my many worries - they won't be.
>

I only read the first two pages of the ROOL thread, but I got the
impression that the ARM64 code was more similar to 6502 assembler (the
only non-RISC machine code with which I have any familiarity) than to
classic ARM code - I'd assumed that '64-bit' was simply a case of longer
registers able to address more memory, but it looks more like a
completely different architecture that has abandoned most of Acorn's
original innovations. Not that that's relevant to the question of
running RISC OS, of course, which would be a problem given any changes
in addressing or the instruction set....

--
Harriet Bazley == Loyaulte me lie ==

Radioactive cats have 18 half-lives.

[druck]

On 12/05/2021 18:30, Harriet Bazley wrote:
> I only read the first two pages of the ROOL thread, but I got the
> impression that the ARM64 code was more similar to 6502 assembler (the
> only non-RISC machine code with which I have any familiarity) than to
> classic ARM code - I'd assumed that '64-bit' was simply a case of longer
> registers able to address more memory, but it looks more like a
> completely different architecture that has abandoned most of Acorn's
> original innovations. Not that that's relevant to the question of
> running RISC OS, of course, which would be a problem given any changes
> in addressing or the instruction set....

It's nothing like the 6502, could not be more different!

The underlying architecture of ARM chips is similar, given that many
chips offer both Aarch32 and Aarch64, but it is an entirely different
instruction set.

The obvious differences aside from number of registers and their width,
are; no condition instructions (not needed with branch prediction), PC
and SP are not general purpose registers (uses special instructions to
access), no load/store multiple (although pairs of registers can be
loaded and stored), and also the stack must always be 16 byte aligned.

But apart from that Aarch64 it does everything Aarch32 does plus much
more, all you need to do is leave it to the compiler.

---druck

[Folderol]

On Wed, 12 May 2021 21:23:08 +0100
druck <ne...@druck.org.uk> wrote:

>The underlying architecture of ARM chips is similar, given that many
>chips offer both Aarch32 and Aarch64, but it is an entirely different
>instruction set.
>
>The obvious differences aside from number of registers and their width,
>are; no condition instructions (not needed with branch prediction), PC
>and SP are not general purpose registers (uses special instructions to
>access), no load/store multiple (although pairs of registers can be
>loaded and stored), and also the stack must always be 16 byte aligned.
>
>But apart from that Aarch64 it does everything Aarch32 does plus much
>more, all you need to do is leave it to the compiler.
>
>---druck

I used to really enjoy programming the ARM2 chips :'(

--
W J G

[Dave]

This all looks very troublesome... :-(

Maybe we should... "Run to the hills" now (Iron Maiden) and find a new
home/OS before the 64bit overwhelms our tribe. ;-)


Dave

--

Dave Triffid

[Joseph Harley]

Nice Iron Maiden reference ;)

Yeah, I'm already looking into running RISC OS 6 on accelerated RiscPc's
with networking cards, 486 co-processor and whatnot (yes, that's
possible), or jumping ship to Amigaland with AROS etc.

[Chris Hughes]

In message <s7julo$ksb$1...@dont-email.me>

Joseph Harley <joerebel...@protonmail.ch> wrote:

> On 13/05/2021 07:55, Dave wrote:
>> This all looks very troublesome... :-(
>>
>> Maybe we should... "Run to the hills" now (Iron Maiden) and find a new
>> home/OS before the 64bit overwhelms our tribe. ;-)
>>
>>
>> Dave
>>

> Nice Iron Maiden reference ;)

> Yeah, I'm already looking into running RISC OS 6 on accelerated RiscPc's
> with networking cards, 486 co-processor and whatnot (yes, that's
> possible), or jumping ship to Amigaland with AROS etc.

Why? 32 bit ARM processors will be available for the existing computers
running RISCOS 5 for several years.

Work is being done to deal with the 64bit issue by ROOL and RISCOS
Developments, these were discussed at the recent Virtual Wakefield Show
(the talks are on the WROCC You Tube Channel)

--
Chris Hughes

[Joseph Harley]

On 13/05/2021 23:15, Chris Hughes wrote:
> Why? 32 bit ARM processors will be available for the existing computers
> running RISCOS 5 for several years.

I think my main concern is 'What if I need faster hardware?', of course,
systems will be around for longer, and my current overclocked Pi 400 is
brand new, but I'm still thinking ahead for the future,

> Work is being done to deal with the 64bit issue by ROOL and RISCOS
> Developments, these were discussed at the recent Virtual Wakefield Show
> (the talks are on the WROCC You Tube Channel)

Admittedly, I missed Wakefield due to other things going on at the time,
but I haven't had time to watch anything back yet, so I will be sure to
do that, if they are dealing with it, then I guess I can sleep easy.

[Sprow]

On Friday, May 14, 2021 at 7:07:12 PM UTC+1, Joseph Harley wrote:
> Admittedly, I missed Wakefield due to other things going on at the time,
> but I haven't had time to watch anything back yet, so I will be sure to
> do that, if they are dealing with it, then I guess I can sleep easy.

Don't sleep too long, the future is now.
Acorn were asleep at the wheel thinking 26 bit would last forever, when it turned out only 1 more chip (StrongARM) supported it, then that was it!

If you're pressed for time you can fast forward to the big topics that need addressing here
https://youtu.be/obQNf-qiflM?t=15575 for approx 6 minutes

I wouldn't go as far as to say anyone's "dealing with it", more that options of what a solution might look like is being pondered. The engineering effort to implement such a solution is going to be large,
Sprow.

[Stuart]

In article <s7me8f$p2q$1...@dont-email.me>,

Joseph Harley <joerebel...@protonmail.ch> wrote:

> Admittedly, I missed Wakefield due to other things going on at the time,
> but I haven't had time to watch anything back yet, so I will be sure to
> do that, if they are dealing with it, then I guess I can sleep easy.

I'm not sure "dealing with it" is quite right, to say they are aware of
the situation would be more accurate. Fixing the problem is a huge amount
of work and we are talking about many programmer months, so you can guess
the problem there.

--
Stuart Winsor

Tools With A Mission
sending tools across the world
http://www.twam.co.uk/

[Tim Hill]

In article <ab329bf4-ecea-4f05...@googlegroups.com>,
Sprow <ne...@sprow.co.uk> wrote:

[Snip]

> Don't sleep too long, the future is now. Acorn were asleep at the wheel
> thinking 26 bit would last forever, when it turned out only 1 more chip
> (StrongARM) supported it, then that was it!

I think Acorn were still patting themselves on the back for leapfrogging
16-bit processors and going to 32(26) bits.

[Jonathan Harston]

On Wednesday, 12 May 2021 at 17:55:18 UTC+1, Joseph Harley wrote:
> On 12/05/2021 12:02, Harriet Bazley wrote:
> > Once you've thrown out conditional execution and all the current
> > operators, in what sense will the '64 bit ARM' chips be ARM at all?
> Exactly, this is one of my many worries - they won't be.

For a personal project I've been digging into the ARM64 instruction
set architecture, and the more I dig the more I keep thinking "good
god, who designed this mess?" It strikes me as a classic "second
system" effect. We've done the first version, that was good, it was
lean and mean due to design contraints, now we're unconstrained,
lets update it and throw everything in that we can think of, destroying
it in the process.

Even just ploughing through the documentation to figure out all the
different versions of "LD" has taken several days. I'm not talking
address modes, I'm talking LOAD instructions. LDR, LDRB, LDRH,
LDRSB, LDSW, LDUR, LDURB, LDRH, LDURSB, LDURSW, LDURSH, LDRAA, LDRAB, LDRSH, LDOPSW, LDO, LDNP, LDURSG
all scattered across 8000 pages of documentation.

[druck]

On 23/05/2021 16:55, Jonathan Harston wrote:
> For a personal project I've been digging into the ARM64 instruction
> set architecture, and the more I dig the more I keep thinking "good
> god, who designed this mess?" It strikes me as a classic "second
> system" effect. We've done the first version, that was good, it was
> lean and mean due to design contraints, now we're unconstrained, lets
> update it and throw everything in that we can think of, destroying it
> in the process.

The difference is aarch32 was hand crafted by Sophie to be nice for
assembler programmers to use. Aarch64 doesn't give a stuff about
people writing assembler, it's designed using statical analysis of what
instructions are of most benefit to compilers.

> Even just ploughing through the documentation to figure out all the
> different versions of "LD" has taken several days. I'm not talking
> address modes, I'm talking LOAD instructions. LDR, LDRB, LDRH, LDRSB,
> LDSW, LDUR, LDURB, LDRH, LDURSB, LDURSW, LDURSH, LDRAA, LDRAB, LDRSH,
> LDOPSW, LDO, LDNP, LDURSG all scattered across 8000 pages of
> documentation.

If you are not writing a compiler or boot loader, its not aimed at you.

---druck

[Theo]

druck <ne...@druck.org.uk> wrote:
> The difference is aarch32 was hand crafted by Sophie to be nice for
> assembler programmers to use. Aarch64 doesn't give a stuff about
> people writing assembler, it's designed using statical analysis of what
> instructions are of most benefit to compilers.

It's also designed to make it easier to build faster processors.
Performance being what most people care about at the end of the day, not
cleanliness of the instruction set.

It just so happened that ARM2 was fast because it was small (and the
instruction set to match) as that suited the manufacturing technology of the
time. Nowadays the manufacturing is different - small CPUs are slow and the
fastest CPUs are definitely not small.

Theo

[David Higton]

In message <1fd81c3d-f812-4bd8...@googlegroups.com>

Jonathan Harston <j...@mdfs.net> wrote:

> For a personal project I've been digging into the ARM64 instruction set
> architecture, and the more I dig the more I keep thinking "good god, who
> designed this mess?" It strikes me as a classic "second system" effect.
> We've done the first version, that was good, it was lean and mean due to
> design contraints, now we're unconstrained, lets update it and throw
> everything in that we can think of, destroying it in the process.
>
> Even just ploughing through the documentation to figure out all the
> different versions of "LD" has taken several days. I'm not talking address
> modes, I'm talking LOAD instructions. LDR, LDRB, LDRH, LDRSB, LDSW, LDUR,
> LDURB, LDRH, LDURSB, LDURSW, LDURSH, LDRAA, LDRAB, LDRSH, LDOPSW, LDO,
> LDNP, LDURSG all scattered across 8000 pages of documentation.

As I've been saying in the ROOL fora for some time now, it's another
reason to write in a higher level language.

David

[Sprow]

On Friday, May 14, 2021 at 8:52:30 PM UTC+1, Sprow wrote:
> On Friday, May 14, 2021 at 7:07:12 PM UTC+1, Joseph Harley wrote:
> > if they are dealing with it, then I guess I can sleep easy.
> Don't sleep too long, the future is now.
> Acorn were asleep at the wheel thinking 26 bit would last forever,
> when it turned out only 1 more chip (StrongARM) supported it, then that was it!

And today's clutch of new ARMv9 processors
https://www.arm.com/company/news/2021/05/arm-total-compute-solutions-and-armv9-to-the-broadest-range-of-client-devices

specifically mentions "...all mobile big and LITTLE cores will be 64-bit only by 2023", which sounds reasonably close,
Sprow.

[Jonathan Harston]

On Monday, 24 May 2021 at 16:00:24 UTC+1, David Higton wrote:
> As I've been saying in the ROOL fora for some time now, it's another
> reason to write in a higher level language.
> David

But at some point that higher-level language still needs to be translated
to machine code.

"No it doesn't, let the compiler do that"

Yes, but the compiler still needs to be written by *somebody*. *Something*
needs to translate a=2 into MOV r0,#2 and some human being somewhere
needs to create that something.

jgh

[druck]

Compilers such as LLVM are written in C++ and the backend specific to a
processor architecture is a series of classes describing its registers
and instructions. It could not be more different to writing programs in
assembler.

---druck

[Richard Porter]

The date being 9 Jun 2021, Jonathan Harston <j...@mdfs.net> decided to
write:

> But at some point that higher-level language still needs to be translated
> to machine code.

> "No it doesn't, let the compiler do that"

> Yes, but the compiler still needs to be written by *somebody*. *Something*
> needs to translate a=2 into MOV r0,#2 and some human being somewhere
> needs to create that something.

MOV r0,#2 is a symbolic assembler instruction, not machine code, although
there is generally a 1:1 correspondence. It has to be translated into
machine code by the assembler. Of course a compiler could and probably
would go all the way to machine code.

Yes, somebody does have to write the compiler, so it's inevitably less
efficient than assembler code but more portable, one would hope.

--
Richard

[druck]

On 12/07/2021 10:18, Richard Porter wrote:
> Yes, somebody does have to write the compiler, so it's inevitably less
> efficient than assembler code but more portable, one would hope.

There are two parts of a compiler, the front end which interprets the
human readable language, optimises it and produces an intermediate
representation, then the backend which is specific to a processor
architecture and converts that to native instructions.

I'll completely ignore whether the front end can produce better
optimised code than a human, as the original question was how new
instructions are added to the compiler backend.

With a simple CPU like the 6502 and ARM2, a human could do much better
than a contemporary compiler backend, being able to work out clever
tricks and shortcuts. But compilers have improved considerably and CPUs
have become far more complex. With ARMv7 and ARMv8 chips, a human is
hard pushed to remember all the instructions (integer, VFP, neon and
other special purpose instructions), never mind huge number of
constraints which affect the most efficient use of a superscalar pipeline.

Where as a compiler backend can be given information on thousands of
instructions and constraints, and work out which is the most optimal
combination is almost every circumstance. Even if a human could match
that, it would be diabolical waste of their time to attempt it.

---druck

[Adrian Crafer]

In message <schscc$u3l$1...@dont-email.me>

You say the back end to the compiler is specific to the processor, does
that mean that the code that is applied to the back end could come from
any compiler front end, meaning that a front end would "only" have to be
written for Risc Os, and it could in turn use a suitable Linux back end or
for that matter if you could get hold of it a Windows 11 back end, or have
I totally misunderstood what is meant.

Adrian


--

acr...@orpheusmail.co.uk

[druck]

On 21/07/2021 18:54, Adrian Crafer wrote:
> You say the back end to the compiler is specific to the processor, does
> that mean that the code that is applied to the back end could come from
> any compiler front end, meaning that a front end would "only" have to be
> written for Risc Os, and it could in turn use a suitable Linux back end or
> for that matter if you could get hold of it a Windows 11 back end, or have
> I totally misunderstood what is meant.

A compiler suite can have different front ends for different languages,
and back ends for different processors. GNU supports front ends for C,
C++, Objective-C Fortran, Ada and Java. LLVM has front ends for Ada, C,
C++, D, Delphi, Fortran, Haskell, Julia, Objective-C, Rust, and Swift.

You don't need a front end for RISC OS, unless you want one to compile
BBC BASIC. Any of the front ends can be ported to RISC OS, and libraries
such as UnixLib takes care of most of the pathname / file extension
differences under RISC OS.

---druck

[Adrian Crafer]

In message <sd9v88$pt8$1...@dont-email.me>

Slightly confused I thought it was said in this discussion that a 64 bit
Compiler was required to generate a 64 bit version of RISC OS.

Adrian Crafer

--


acr...@orpheusmail.co.uk

[druck]

On 26/07/2021 10:57, Adrian Crafer wrote:
> Slightly confused I thought it was said in this discussion that a 64 bit
> Compiler was required to generate a 64 bit version of RISC OS.

It is, see the previous messages on how compilers work.

The problem for RISC OS isn't the lack of a 64 bit compiler, it's not
even the large amount of 32 bit assembler which is still in the OS. It's
problem of redesigning every API for 64 bits, which is obviously not
going to be compatible with existing applications, even BASIC ones.

But as this will break things, it's also the last chance to drag RISC OS
kicking and screaming in to the modern world, i.e. being able to make
use of multiple cores, and protection against insipid crashiness.

You've then got to pray that there are still developers around to make
enough applications run natively on the new 64 bit OS, or you'll just be
emulating 26/32 bit RISC OS forever more.

---druck

[Sprow]

On Tuesday, July 27, 2021 at 9:15:31 PM UTC+1, druck wrote:
> The problem for RISC OS isn't the lack of a 64 bit compiler, it's not
> even the large amount of 32 bit assembler which is still in the OS. It's
> problem of redesigning every API for 64 bits, which is obviously not
> going to be compatible with existing applications, even BASIC ones.

On a cursory survey of all the SWIs in RISC OS 5, it's not /that/ bad
https://www.riscosopen.org/wiki/documentation/show/Addressing%20the%20end-of-life%20of%20AArch32

So (picking one not flagged as needing attention) in BASIC on AArch32 I might write
DIM block% 4
SYS"IIC_Control",chip%,block%,4

in a 64 bit world
DIM block% 4
SYS"IIC_Control",chip%,block%,4

which works because we've defined SWIs in terms of registers passed, except on AArch64 the registers are now 64 bit so can pass 64 bit pointers.
There's a lot more iceberg under the water of course, but I don't count fixing up a few APIs as where most of the ice is,
Sprow.