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.