• RISC OS 5 (Open) and ARM64

    From Joseph Harley@21:1/5 to All on Tue May 11 07:33:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to Joseph Harley on Tue May 11 09:56:47 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joseph Harley@21:1/5 to Martin on Tue May 11 17:55:25 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to Martin on Wed May 12 12:02:06 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Harriet Bazley on Wed May 12 14:11:32 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joseph Harley@21:1/5 to Harriet Bazley on Wed May 12 17:55:17 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harriet Bazley@21:1/5 to Joseph Harley on Wed May 12 18:30:45 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frederick Bambrough@21:1/5 to druck on Wed May 12 18:17:49 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Harriet Bazley on Wed May 12 21:23:08 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Folderol@21:1/5 to druck on Wed May 12 22:02:32 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave@21:1/5 to All on Thu May 13 07:55:37 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joseph Harley@21:1/5 to Dave on Thu May 13 20:28:56 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hughes@21:1/5 to Joseph Harley on Thu May 13 23:15:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joseph Harley@21:1/5 to Chris Hughes on Fri May 14 19:07:09 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sprow@21:1/5 to Joseph Harley on Fri May 14 12:52:29 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stuart@21:1/5 to Joseph Harley on Fri May 14 22:17:36 2021
    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Hill@21:1/5 to Sprow on Mon May 17 21:39:30 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Harston@21:1/5 to Joseph Harley on Sun May 23 08:55:18 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Jonathan Harston on Mon May 24 09:16:52 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Theo@21:1/5 to druck on Mon May 24 14:10:49 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Higton@21:1/5 to Jonathan Harston on Mon May 24 15:59:57 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sprow@21:1/5 to Sprow on Tue May 25 15:15:14 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Harston@21:1/5 to David Higton on Wed Jun 9 13:40:48 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Jonathan Harston on Fri Jun 11 21:09:55 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Porter@21:1/5 to All on Mon Jul 12 10:18:08 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Richard Porter on Mon Jul 12 17:58:51 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adrian Crafer@21:1/5 to druck on Wed Jul 21 18:54:03 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Adrian Crafer on Wed Jul 21 21:15:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adrian Crafer@21:1/5 to druck on Mon Jul 26 10:57:09 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Adrian Crafer on Tue Jul 27 21:15:28 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sprow@21:1/5 to druck on Wed Jul 28 00:51:21 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)