5 ms·

> built with hindsight no other ISA has Why do all the riscv fans Conveniently ignore aarch64 when they make statements like this? It was in fact a completely

> built with hindsight no other ISA has Why do all the riscv fans Conveniently ignore aarch64 when they make statements like this? It was in fact a completely clean new design, based on hindsight, by people who know what they are doing, and with no legacy Cruft.

snvzz 5y ago
>Why do all the riscv fans Conveniently ignore aarch64 when they make statements like this? It was in fact a completely clean new design, based on hindsight, by people who know what they are doing, and with no legacy Cruft. aarch64 seems poorly designed to me. ARMv7 had thumb, but for some reason ARMv8 did not incorporate any lessons from that. As a result, code density is bad; ARMv8 binaries are huge. ARMv9, to be available in chips next year, is just a higher profile of required extensions, and does nothing to fix that. Ever wonder why M1 needs such huge L1 cache? Well, now you know. Considering ARMv9 will be competing against RVA22, I don't have much hope for ARM.
- dmitrygr 5y ago
  > for some reason ARMv8 did not incorporate any lessons from that. I used to think so too, until I asked some more knowledgeable people about it. Turns out the lesson IS that not having it is better. Fixed-sized instructions make a decoding significantly simpler, making it much easier to make very wide front ends
  - brucehoult 5y ago
    A little easier, not much easier. A number of organisations are making very wide RISC-V implementations, and one has already published how their decoder works. It's modular, with each block looking at 48 bits of code (the first 16 overlapping with the previous block) and decoding either two 16 bit instructions, or one aligned 32 bit instruction, or one misaligned 32 bit instruction with a following 16 bit instruction, or one misaligned 32 bit instruction followed by an ignored start of another misaligned 32 bit instruction. You can put as many of these modules side by side as you want. There is a serial dependency between them in that each block has to tell the next block whether its last 16 bits are the start of a misaligned 32 bit instruction or not. That could become an issue with really really wide but for something decoding e.g. 16 bytes at a time (4 to 8 instructions) it's not an issue. There is a trade-off between a little bit of decoder complexity and a lot of improved code density -- but nowhere near to the same extent as say x86.
- pohl 5y ago
  Ever wonder why M1 needs such huge L1 cache? Well, now you know. I'm not sure I follow this, but it reminds me to ask: does RISC-V allow for designs to have both efficiency & performance cores like the ARM big.LITTLE concept? Has anyone made one yet?
  - brucehoult 5y ago
    Of course you can do it. SiFive has been allowing customers to configure core complexes with a mixture of different core types for years -- for example mixing U84 cores with U74 or U54. If you want to do a BIG.little thing with transferring a running program from one core type to another that's just a software thing -- and using cores with the same ISA but different microarchitecture. To date the examples of this that have been shipped to the public have used cores with similar microarchitecture, but a different set of extensions. For example the U54-MC in the HiFive Unleashed and in the Microsemi Polarfire SoC FPGAs use four U54 cores plus one E51 core for "real time" tasks. The E51 doesn't have an FPU or MMU or Supervisor mode. The U74-MC in the HiFive Unmatched is similar. Alibaba's ICE SoC, which you may have seen videos of running Android, has two C910 Out-of-Order cores (similar to ARM A72/A73) implementing RV64GC, and a third C910 core that also has a vector processing unit with two pipes with 256 bit vector ALU each, plus 128 bit vector load and store pipes.
  - deleted 5y ago
    [deleted]
- adrian_b 5y ago
  ARMv8 code density is quite good for a fixed-length ISA and is of course much better than that of RISC-V. RISC-V has only one good feature for code density, the combined compare-and-branch instructions, but even this feature was designed poorly, because it does not have all the kinds of compare-and-branch that are needed, e.g. if you want safe code that checks for overflows, the number of required instructions and the code size explode. Only unsafe code, without run-time checks, can have an acceptable size in RISC-V. ARMv8 has an adequate unused space in the branch opcode map, where combined compare-and-branch instructions could be added, and with a larger branch offset range than in RISC-V, in which case the code size advantage of ARMv8 vs. RISC-V would increase significantly. While the combined compare-and-branch of RISC-V are good for code density, because branches are very frequent, the rest of the ISA is bad and the worst is the lack of indexed addressing, which frequently requires 2 RISC-V instructions instead of 1 ARM instruction.
  - snvzz 5y ago
    >in which case the code size advantage of ARMv8 vs. RISC-V would increase significantly. Many things could be said about ARMv8, but that it has good code size is not one of it. It does, in fact, have abysmal code density. Both RISC-V and x86-64 produce significantly smaller binaries. For RISC-V, we're talking about a 20% reduction of size. There's a wealth of papers on this, but you can verify this trivially yourself, by either compiling binaries for different architectures from the same sources, or comparing binaries in Linux distributions that support RISC-V and ARM. >where combined compare-and-branch instructions could be added, and with a larger branch offset range than in RISC-V If your argument is that ARMv8 could get better over time, I hate to be the bearer of bad news. ARMv9 code density isn't any better. >and the worst is the lack of indexed addressing, which frequently requires 2 RISC-V instructions instead of 1 ARM instruction. These patterns are standardized, and they become one instruction after fusion. RISC-V, unlike the previous generation of ISAs, was thoroughly designed with hindsight on fusion. The simplest microarchitectures can of course omit it altogether, but the cost of fusion in RISC-V is low; I have seen it quoted at 400 gates.
    - brucehoult 5y ago
- crest 5y ago
  While I haven no personal experience writing aarch64 assembler code my experience with ARM v6m an v7m makes me doubt your implied insult that ARM just failed/didn't give a fuck about their instruction set. Thumb 1 and 2 are well designed instruction sets optimized for a certain kind of uarch. Almost all quirks exposed to the low level programmer are there for good reasons and while some of the constraints are a pose a challenge for compiler writers they are not beyond the capabilities of GCC or LLVM. There are several possible reasons for ARM to return to a fixed length 32 bit encoding e.g. to allow very wide OoO designs like Apple's Firestorm cores or because the gain is smaller for 64 bit code with larger constants and better served by PC relative constant pools. And while the quirky LDMIA function prologue is very flexible, appeals to me as assembler programmer and saves code space having a single instruction potentially modify most integer registers as well as change the program counter and the active instruction set is hard to implement well while easier to implement register pair load/store instructions are enough for most common instruction sequences. The tradeoff was different for in-order ARM2/3 CPUs with single ported memory and a tiny unified cache (if that).
  - throwaway81523 5y ago
    > Thumb 1 and 2 are well designed instruction sets I had thought that Thumb 1 had serious shortcomings, which is why they ended up needing Thumb 2.
FullyFunctional 5y ago
I'm a fan of RISC-V but the freedom is a large part of it. Aarch64 is a very well designed ISA and clearly has a lot of benefit of hindsight. The load pair/store pair instructions, the addressing modes, fixed 32-bit instruction size, etc. It all really helps. I suspect that Apple was actively part of designing it. I think however that RISC-V isn't that much worse and because of the freedom we will almost certainly see more implementation of RISC-V. I'd be watching Tenstorrent, SiFive, Rivos, Esperanto, and maybe Alibaba/T-Head.
brucehoult 5y ago
Aarch64 obviously isn't a completely clean sheet design. It was constrained by having to execute on the same CPU pipelines as 32 bit code, at least for the first decade or so. And the 32 bit mode has to perform well. There are tens of millions of Raspberry Pi 3s and 4s (and later model Pi 2s) which have 64 bit CPUs but have never seen a 64 bit instruction in their lives. Android phones have been supporting both 32 and 64 bit apps for a long time. The "by people who know what they are doing" thing is just pure FUD. Sure, ARM employs some competent people, but no more so than IBM, Intel, AMD or the various members of RISC-V International.

snvzz 5y ago

>Why do all the riscv fans Conveniently ignore aarch64 when they make statements like this? It was in fact a completely clean new design, based on hindsight, by people who know what they are doing, and with no legacy Cruft. aarch64 seems poorly designed to me. ARMv7 had thumb, but for some reason ARMv8 did not incorporate any lessons from that. As a result, code density is bad; ARMv8 binaries are huge. ARMv9, to be available in chips next year, is just a higher profile of required extensions, and does nothing to fix that. Ever wonder why M1 needs such huge L1 cache? Well, now you know. Considering ARMv9 will be competing against RVA22, I don't have much hope for ARM.

dmitrygr 5y ago
> for some reason ARMv8 did not incorporate any lessons from that. I used to think so too, until I asked some more knowledgeable people about it. Turns out the lesson IS that not having it is better. Fixed-sized instructions make a decoding significantly simpler, making it much easier to make very wide front ends
- brucehoult 5y ago
  A little easier, not much easier. A number of organisations are making very wide RISC-V implementations, and one has already published how their decoder works. It's modular, with each block looking at 48 bits of code (the first 16 overlapping with the previous block) and decoding either two 16 bit instructions, or one aligned 32 bit instruction, or one misaligned 32 bit instruction with a following 16 bit instruction, or one misaligned 32 bit instruction followed by an ignored start of another misaligned 32 bit instruction. You can put as many of these modules side by side as you want. There is a serial dependency between them in that each block has to tell the next block whether its last 16 bits are the start of a misaligned 32 bit instruction or not. That could become an issue with really really wide but for something decoding e.g. 16 bytes at a time (4 to 8 instructions) it's not an issue. There is a trade-off between a little bit of decoder complexity and a lot of improved code density -- but nowhere near to the same extent as say x86.
pohl 5y ago
Ever wonder why M1 needs such huge L1 cache? Well, now you know. I'm not sure I follow this, but it reminds me to ask: does RISC-V allow for designs to have both efficiency & performance cores like the ARM big.LITTLE concept? Has anyone made one yet?
- brucehoult 5y ago
  Of course you can do it. SiFive has been allowing customers to configure core complexes with a mixture of different core types for years -- for example mixing U84 cores with U74 or U54. If you want to do a BIG.little thing with transferring a running program from one core type to another that's just a software thing -- and using cores with the same ISA but different microarchitecture. To date the examples of this that have been shipped to the public have used cores with similar microarchitecture, but a different set of extensions. For example the U54-MC in the HiFive Unleashed and in the Microsemi Polarfire SoC FPGAs use four U54 cores plus one E51 core for "real time" tasks. The E51 doesn't have an FPU or MMU or Supervisor mode. The U74-MC in the HiFive Unmatched is similar. Alibaba's ICE SoC, which you may have seen videos of running Android, has two C910 Out-of-Order cores (similar to ARM A72/A73) implementing RV64GC, and a third C910 core that also has a vector processing unit with two pipes with 256 bit vector ALU each, plus 128 bit vector load and store pipes.
- deleted 5y ago
  [deleted]
adrian_b 5y ago
ARMv8 code density is quite good for a fixed-length ISA and is of course much better than that of RISC-V. RISC-V has only one good feature for code density, the combined compare-and-branch instructions, but even this feature was designed poorly, because it does not have all the kinds of compare-and-branch that are needed, e.g. if you want safe code that checks for overflows, the number of required instructions and the code size explode. Only unsafe code, without run-time checks, can have an acceptable size in RISC-V. ARMv8 has an adequate unused space in the branch opcode map, where combined compare-and-branch instructions could be added, and with a larger branch offset range than in RISC-V, in which case the code size advantage of ARMv8 vs. RISC-V would increase significantly. While the combined compare-and-branch of RISC-V are good for code density, because branches are very frequent, the rest of the ISA is bad and the worst is the lack of indexed addressing, which frequently requires 2 RISC-V instructions instead of 1 ARM instruction.
- snvzz 5y ago
  >in which case the code size advantage of ARMv8 vs. RISC-V would increase significantly. Many things could be said about ARMv8, but that it has good code size is not one of it. It does, in fact, have abysmal code density. Both RISC-V and x86-64 produce significantly smaller binaries. For RISC-V, we're talking about a 20% reduction of size. There's a wealth of papers on this, but you can verify this trivially yourself, by either compiling binaries for different architectures from the same sources, or comparing binaries in Linux distributions that support RISC-V and ARM. >where combined compare-and-branch instructions could be added, and with a larger branch offset range than in RISC-V If your argument is that ARMv8 could get better over time, I hate to be the bearer of bad news. ARMv9 code density isn't any better. >and the worst is the lack of indexed addressing, which frequently requires 2 RISC-V instructions instead of 1 ARM instruction. These patterns are standardized, and they become one instruction after fusion. RISC-V, unlike the previous generation of ISAs, was thoroughly designed with hindsight on fusion. The simplest microarchitectures can of course omit it altogether, but the cost of fusion in RISC-V is low; I have seen it quoted at 400 gates.
  - brucehoult 5y ago
crest 5y ago
While I haven no personal experience writing aarch64 assembler code my experience with ARM v6m an v7m makes me doubt your implied insult that ARM just failed/didn't give a fuck about their instruction set. Thumb 1 and 2 are well designed instruction sets optimized for a certain kind of uarch. Almost all quirks exposed to the low level programmer are there for good reasons and while some of the constraints are a pose a challenge for compiler writers they are not beyond the capabilities of GCC or LLVM. There are several possible reasons for ARM to return to a fixed length 32 bit encoding e.g. to allow very wide OoO designs like Apple's Firestorm cores or because the gain is smaller for 64 bit code with larger constants and better served by PC relative constant pools. And while the quirky LDMIA function prologue is very flexible, appeals to me as assembler programmer and saves code space having a single instruction potentially modify most integer registers as well as change the program counter and the active instruction set is hard to implement well while easier to implement register pair load/store instructions are enough for most common instruction sequences. The tradeoff was different for in-order ARM2/3 CPUs with single ported memory and a tiny unified cache (if that).
- throwaway81523 5y ago
  > Thumb 1 and 2 are well designed instruction sets I had thought that Thumb 1 had serious shortcomings, which is why they ended up needing Thumb 2.

FullyFunctional 5y ago

I'm a fan of RISC-V but the freedom is a large part of it. Aarch64 is a very well designed ISA and clearly has a lot of benefit of hindsight. The load pair/store pair instructions, the addressing modes, fixed 32-bit instruction size, etc. It all really helps. I suspect that Apple was actively part of designing it. I think however that RISC-V isn't that much worse and because of the freedom we will almost certainly see more implementation of RISC-V. I'd be watching Tenstorrent, SiFive, Rivos, Esperanto, and maybe Alibaba/T-Head.

brucehoult 5y ago

Aarch64 obviously isn't a completely clean sheet design. It was constrained by having to execute on the same CPU pipelines as 32 bit code, at least for the first decade or so. And the 32 bit mode has to perform well. There are tens of millions of Raspberry Pi 3s and 4s (and later model Pi 2s) which have 64 bit CPUs but have never seen a 64 bit instruction in their lives. Android phones have been supporting both 32 and 64 bit apps for a long time. The "by people who know what they are doing" thing is just pure FUD. Sure, ARM employs some competent people, but no more so than IBM, Intel, AMD or the various members of RISC-V International.