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
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?
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?
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.
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.
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....
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
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
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)
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.
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!
On 12/05/2021 12:02, Harriet Bazley wrote:
Once you've thrown out conditional execution and all the currentExactly, this is one of my many worries - they won't be.
operators, in what sense will the '64 bit ARM' chips be ARM at all?
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.
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.
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 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!
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 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.
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.
Yes, somebody does have to write the compiler, so it's inevitably less efficient than assembler code but more portable, one would hope.
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
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.
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
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 90:36:27 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,565 |