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

In article <s7d8f4$lc4$1@dont-email.me>,
Joseph Harley <joerebelloharley@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.

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

On 11 May 2021 as I do recall,
Martin wrote:

> In article <s7d8f4$lc4$1@dont-email.me>,
> Joseph Harley <joerebelloharley@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.

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

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.

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

In message <s7gk64$i1a$1@dont-email.me>
druck <news@druck.org.uk> 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?
>
> The fact that ARM designs them.

An ARM AM.

--
Fred

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.

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

On Wed, 12 May 2021 21:23:08 +0100
druck <news@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

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

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.

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

In message <s7julo$ksb$1@dont-email.me>
Joseph Harley <joerebelloharley@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

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.

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

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.

In article <s7me8f$p2q$1@dont-email.me>,
Joseph Harley <joerebelloharley@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/

In article <ab329bf4-ecea-4f05-a843-079925ef488bn@googlegroups.com>,
Sprow <news@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.

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.

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

druck <news@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

In message <1fd81c3d-f812-4bd8-b9bb-3c6912ed2b57n@googlegroups.com>
Jonathan Harston <jgh@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

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.

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

On 09/06/2021 21:40, Jonathan Harston wrote:
> 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.

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

The date being 9 Jun 2021, Jonathan Harston <jgh@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