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

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

In message <schscc$u3l$1@dont-email.me>
druck <news@druck.org.uk> wrote:

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

Adrian

--

acrafer@orpheusmail.co.uk

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

In message <sd9v88$pt8$1@dont-email.me>
druck <news@druck.org.uk> wrote:

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

Adrian Crafer

--

acrafer@orpheusmail.co.uk

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

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.