7 ms·

What does ARM and RISC-V spend their weirdness budget on?

qikInNdOutReply 5y ago
wasnt there also the long jump limitation weirdness that forced it to create little hopping points, were the instructions were stored to hop to the next point, all of that to get to some memory whos pointer it could not fit into loadInstructions Register? Sorry, its been a while, but i found the idea, to generate those instruction isles into the code quite weird.
jmgao 5y ago
ARM spends it on pc being wrong: when you mov from it, it's off by 8 in ARM mode, and off by 4 in Thumb mode, and if you're using it for pc-relative loads (and stores, if you're crazy), it uses a word aligned value. edit: oh, and softfloat vs softfp vs hardfp vs vfp edit: oh, and how they have two incompatible assembly language dialects that are mostly the same, but in non-trivial code, incompatible
- danachow 5y ago
  > ARM spends it on pc being wrong. Heh, having dealt with x86 for years, this is comparatively such a nothing burger. It's always a simple known fixed offset. > softfloat vs softfp vs hardfp vs vfp That's something not really unique to ARM per se. Any architecture with options for hardware FPU are going to practically need ABI specs for the soft and hard cases (you don't absolutely need anything more than hardfp since you can always emulate but it will be slow as shit) - and ARM is certainly not unique in having multiple hardware floating point implementations either. > two incompatible assembly language dialects Curious what you're referring to here - but I personally wouldn't consider assembly language dialects to be part of a CPU architecture.
  - kelnos 5y ago
    > Curious what you're referring to here - but I personally wouldn't consider assembly language dialects to be part of a CPU architecture. I assume they're talking about ARM vs. Thumb?
    - jmgao 5y ago
      Belated, but no, I was referring to UAL vs old syntax.
- curling_grad 5y ago
  By pc you mean "program counter"?
  - deleted 5y ago
    [deleted]
snvzz 5y ago
As far as I am aware, RISC-V spends it on not being weird (which is itself weird).
- TNorthover 5y ago
  The hoops they had to go through to get PIC address calculations to work make it quite weird. Because `auipc` adds an offset from its `pc`, the corresponding `add` or `lw` relocation needs refer back to that instruction rather than the symbol it's actually looking for. The poor ELF specification ends up quite tortured by this, IMO.
  - brucehoult 5y ago
    That affects ELF relocations but not the code. Arm64 is even worse! There is almost exactly the same instruction, but it also zeroes the low bits of the target address, so as you relocate code you also have to change the offset in the 2nd instruction even if the distance between the reference and the target stays the same.
- rwmj 5y ago
  Probably on copying Arm too much :-) I hit "char is unsigned" (not really architectural, more of a toolchain issue) only this morning. RISC-V was originally going to implement a hypervisor mode which would only have worked with Xen-like hypervisors. Luckily we were able to head that off early and the actual hypervisor extension we got can run KVM efficiently.
  - exikyut 5y ago
    Not sure if you'll see this - going through old tabs - but I was curious, and just in case: what are the practical differences between Xen and KVM here?
- kryptiskt 5y ago
  It doesn't have a condition code register, which scores it plenty of weirdness points.
pjc50 5y ago
RISC-V spends it on the "R": either not having single instructions to do certain stuff, or that those instructions are in one of the extension blocks so you have to customize your binaries to a particular RISC-V subset. Most architectures only do this for the high-performance SIMD numeric instructions. ARM endianness is switchable at runtime.
- rwmj 5y ago
  You keep saying this about RISC-V and it keeps not being true. Instruction sequences that fuse are standardized. RISC-V defines various profiles (like "Unix server") which mandate a minimum set of extensions. Extensions beyond the mandated ones will be detected at runtime, just like on x86.
  - gchadwick 5y ago
    > Instruction sequences that fuse are standardized They are? Care to point to a ratified RISC-V standard that lists said instruction sequences?
    - rwmj 5y ago
      Go to the user spec here: https://riscv.org/technical/specifications/ https://riscv.org/technical/specifications/ and search for "fusion", "macro-op", "hint", "two-instruction sequences". A lot of it is through register choice. For other proposals (not standards yet) see https://en.wikichip.org/wiki/macro-operation_fusion#Proposed_fusion_operations https://en.wikichip.org/wiki/macro-operation_fusion#Proposed...
      - Annatar 5y ago
        just one example of weird insanity from that table: slli rd, rs1, {1,2,3} add rd, rd, rs2 Fused into a load effective address ...this is so insane. Whoever thought that this is okay and good, has, in my opinion, severe psychological and psychiatric problems and would do well to seek professional help. If this gets "fused" into a lea, why just not implement a hex code for lea? I'm just completely at a loss as to how messed up that is. You know what, I'd like to know what a person who thinks that this is okay looks and behaves like.
pm215 5y ago
You could argue that Arm mostly doesn't get too weird and that that's part of why it succeeded, but some things include: + 'char' being unsigned + handling of unaligned accesses (in early architecture versions a value is read from the aligned address and rotated, which is useless behaviour that falls out of the original implementation because of how it dealt with byte loads; subsequently it was at least made to fault, but it wasn't until I think v6 that unaligned accesses were made to Just Work) + the weak memory model
- bpye 5y ago
  I’m pretty sure it’s x86 that is weird in having a strong memory model, most other architectures (including ARM) are weak.
renox 5y ago
In RISC-V with the C-extension 32bit instructions are 16bit aligned. Far from x86-level of weirdness but my must be quite annoying for those who want to make 'high performance' CPUs..
- rwmj 5y ago
  RISC-V instructions are variable length, from 16 bits up to 192 bits[0]. The instruction stream is self-synchronising though so from a hardware decode point of view it's not a problem, unlike x86. [0] See "Expanded Instruction-Length Encoding" in the user spec.
  - monocasa 5y ago
    I don't think the instruction stream is self synchronizing; if you jump to the middle of an instruction there's no guarantee you'll ever get back to not parsing garbage.
    - rwmj 5y ago
      I didn't put that very well. I didn't mean it was self-synchronising when executing, but that you can (I think?!) always find the next instruction boundary by looking at the bottom bits. At least, that's my understanding from reading that part of the user spec.
  - pm215 5y ago
    It can still get you into some extra corner cases for the insn fetch hardware to have to handle when an insn crosses a cache line boundary, though...
  - brucehoult 5y ago
    RISC-V instructions longer than 32 bits are just a theoretical possibility at this point. An extension escape hatch for the future. No one has done it, no one seems to be keen to be the first to do it, and even how the instruction length encodings work is not a ratified part of the spec -- it's just a proposal at the moment, even for the next step of 48 bit instructions. There has been discussion of encodings better than the one proposed in the current spec, especially around instruction length encoding schemes that would make more opcode bits available in 80 bit instructions than in the scheme in the spec, so as to have a possibility of encoding 64 bit literals in an 80 bit instruction. https://github.com/riscv/riscv-isa-manual/issues/280 https://github.com/riscv/riscv-isa-manual/issues/280
cesarb 5y ago
For traditional 32-bit ARM, off the top of my head: - Every instruction being conditional (all instructions have a four-bit condition field, with one of the 16 possible modes being "always"); - The barrel shifter, which can be used on nearly every data processing instruction; - The program counter being one of the general-purpose registers (and on the original ARM, the same register also containing the flags), so that any register move can alter the program flow; - The load-multiple/store-multiple instructions, which can load or store up to 16 registers, plus incrementing or decrementing the base register; and since the program counter is one of these registers, it can restore several registers from the stack, update the stack pointer, change the program counter, and switch to Thumb mode (stored on the least significant bit of the program counter), all in a single instruction.
- Annatar 5y ago
  Loading and storing multiple registers is by no means weird: the MC68000 family has the movem.(b|w|l) instructions which do exactly that, and it's one of the best things since sliced bread because performance can be gained when used cleverly. Being able to manipulate the program counter in the ARM processors directly is just being honest, simple and straightforward, rather then having it always done implicitly. Seems very intuitive to me now that I think about it.
  - brucehoult 5y ago
    Being able to manipulate the program counter directly plays hell with a superscalar and especially OoO processor where you want to be able to predict what the program counter does very accurately so the instruction fetch and decode can run far ahead of the execution. There are four kinds of instructions that play hell with pipeline and OoO design: - instructions that might cause traps, dependent on the values processed - instructions that you don't know whether they will change the control flow - instructions that you don't know where the control flow is going to go to - instructions where you don't know how long they will take to execute RISC-V, for example, bans the first category entirely other than load/store, and carefully separates the other three so any one instruction only had at most one of those problems. ARM load multiple has all of those problems. At least you can examine the register mask at instruction decode time and know whether it will change the PC or not and tag the instruction in the pipeline as being a Jump or not. Imagine if there was a version that took the bitmap from a register instead of being hard-coded... Load/store multiple don't increase performance much if at all on a CPU with an instruction cache and/or an instruction prefetch buffer. On an original 68000 or ARM without any cache, sure, a series of load or store instructions requires interleaving reading the opcodes with reading or writing the data, while load/store multiple eliminates the opcode reads. An instruction cache also eliminates them, leaving only the code size benefits. But load/store multiple is a perfect candidate for using a simple runtime function instead, at least if you have lightweight function call/return as RISC designs usually do.

wasnt there also the long jump limitation weirdness that forced it to create little hopping points, were the instructions were stored to hop to the next point, all of that to get to some memory whos pointer it could not fit into loadInstructions Register? Sorry, its been a while, but i found the idea, to generate those instruction isles into the code quite weird.

jmgao 5y ago

ARM spends it on pc being wrong: when you mov from it, it's off by 8 in ARM mode, and off by 4 in Thumb mode, and if you're using it for pc-relative loads (and stores, if you're crazy), it uses a word aligned value. edit: oh, and softfloat vs softfp vs hardfp vs vfp edit: oh, and how they have two incompatible assembly language dialects that are mostly the same, but in non-trivial code, incompatible

danachow 5y ago
> ARM spends it on pc being wrong. Heh, having dealt with x86 for years, this is comparatively such a nothing burger. It's always a simple known fixed offset. > softfloat vs softfp vs hardfp vs vfp That's something not really unique to ARM per se. Any architecture with options for hardware FPU are going to practically need ABI specs for the soft and hard cases (you don't absolutely need anything more than hardfp since you can always emulate but it will be slow as shit) - and ARM is certainly not unique in having multiple hardware floating point implementations either. > two incompatible assembly language dialects Curious what you're referring to here - but I personally wouldn't consider assembly language dialects to be part of a CPU architecture.
- kelnos 5y ago
  > Curious what you're referring to here - but I personally wouldn't consider assembly language dialects to be part of a CPU architecture. I assume they're talking about ARM vs. Thumb?
  - jmgao 5y ago
    Belated, but no, I was referring to UAL vs old syntax.
curling_grad 5y ago
By pc you mean "program counter"?
- deleted 5y ago
  [deleted]

snvzz 5y ago

As far as I am aware, RISC-V spends it on not being weird (which is itself weird).

TNorthover 5y ago
The hoops they had to go through to get PIC address calculations to work make it quite weird. Because `auipc` adds an offset from its `pc`, the corresponding `add` or `lw` relocation needs refer back to that instruction rather than the symbol it's actually looking for. The poor ELF specification ends up quite tortured by this, IMO.
- brucehoult 5y ago
  That affects ELF relocations but not the code. Arm64 is even worse! There is almost exactly the same instruction, but it also zeroes the low bits of the target address, so as you relocate code you also have to change the offset in the 2nd instruction even if the distance between the reference and the target stays the same.
rwmj 5y ago
Probably on copying Arm too much :-) I hit "char is unsigned" (not really architectural, more of a toolchain issue) only this morning. RISC-V was originally going to implement a hypervisor mode which would only have worked with Xen-like hypervisors. Luckily we were able to head that off early and the actual hypervisor extension we got can run KVM efficiently.
- exikyut 5y ago
  Not sure if you'll see this - going through old tabs - but I was curious, and just in case: what are the practical differences between Xen and KVM here?
kryptiskt 5y ago
It doesn't have a condition code register, which scores it plenty of weirdness points.

pjc50 5y ago

RISC-V spends it on the "R": either not having single instructions to do certain stuff, or that those instructions are in one of the extension blocks so you have to customize your binaries to a particular RISC-V subset. Most architectures only do this for the high-performance SIMD numeric instructions. ARM endianness is switchable at runtime.

rwmj 5y ago
You keep saying this about RISC-V and it keeps not being true. Instruction sequences that fuse are standardized. RISC-V defines various profiles (like "Unix server") which mandate a minimum set of extensions. Extensions beyond the mandated ones will be detected at runtime, just like on x86.
- gchadwick 5y ago
  > Instruction sequences that fuse are standardized They are? Care to point to a ratified RISC-V standard that lists said instruction sequences?
  - rwmj 5y ago
    Go to the user spec here: https://riscv.org/technical/specifications/ https://riscv.org/technical/specifications/ and search for "fusion", "macro-op", "hint", "two-instruction sequences". A lot of it is through register choice. For other proposals (not standards yet) see https://en.wikichip.org/wiki/macro-operation_fusion#Proposed_fusion_operations https://en.wikichip.org/wiki/macro-operation_fusion#Proposed...
    - Annatar 5y ago
      just one example of weird insanity from that table: slli rd, rs1, {1,2,3} add rd, rd, rs2 Fused into a load effective address ...this is so insane. Whoever thought that this is okay and good, has, in my opinion, severe psychological and psychiatric problems and would do well to seek professional help. If this gets "fused" into a lea, why just not implement a hex code for lea? I'm just completely at a loss as to how messed up that is. You know what, I'd like to know what a person who thinks that this is okay looks and behaves like.

pm215 5y ago

You could argue that Arm mostly doesn't get too weird and that that's part of why it succeeded, but some things include: + 'char' being unsigned + handling of unaligned accesses (in early architecture versions a value is read from the aligned address and rotated, which is useless behaviour that falls out of the original implementation because of how it dealt with byte loads; subsequently it was at least made to fault, but it wasn't until I think v6 that unaligned accesses were made to Just Work) + the weak memory model

bpye 5y ago
I’m pretty sure it’s x86 that is weird in having a strong memory model, most other architectures (including ARM) are weak.

renox 5y ago

In RISC-V with the C-extension 32bit instructions are 16bit aligned. Far from x86-level of weirdness but my must be quite annoying for those who want to make 'high performance' CPUs..

rwmj 5y ago
RISC-V instructions are variable length, from 16 bits up to 192 bits[0]. The instruction stream is self-synchronising though so from a hardware decode point of view it's not a problem, unlike x86. [0] See "Expanded Instruction-Length Encoding" in the user spec.
- monocasa 5y ago
  I don't think the instruction stream is self synchronizing; if you jump to the middle of an instruction there's no guarantee you'll ever get back to not parsing garbage.
  - rwmj 5y ago
    I didn't put that very well. I didn't mean it was self-synchronising when executing, but that you can (I think?!) always find the next instruction boundary by looking at the bottom bits. At least, that's my understanding from reading that part of the user spec.
- pm215 5y ago
  It can still get you into some extra corner cases for the insn fetch hardware to have to handle when an insn crosses a cache line boundary, though...
- brucehoult 5y ago
  RISC-V instructions longer than 32 bits are just a theoretical possibility at this point. An extension escape hatch for the future. No one has done it, no one seems to be keen to be the first to do it, and even how the instruction length encodings work is not a ratified part of the spec -- it's just a proposal at the moment, even for the next step of 48 bit instructions. There has been discussion of encodings better than the one proposed in the current spec, especially around instruction length encoding schemes that would make more opcode bits available in 80 bit instructions than in the scheme in the spec, so as to have a possibility of encoding 64 bit literals in an 80 bit instruction. https://github.com/riscv/riscv-isa-manual/issues/280 https://github.com/riscv/riscv-isa-manual/issues/280

cesarb 5y ago

For traditional 32-bit ARM, off the top of my head: - Every instruction being conditional (all instructions have a four-bit condition field, with one of the 16 possible modes being "always"); - The barrel shifter, which can be used on nearly every data processing instruction; - The program counter being one of the general-purpose registers (and on the original ARM, the same register also containing the flags), so that any register move can alter the program flow; - The load-multiple/store-multiple instructions, which can load or store up to 16 registers, plus incrementing or decrementing the base register; and since the program counter is one of these registers, it can restore several registers from the stack, update the stack pointer, change the program counter, and switch to Thumb mode (stored on the least significant bit of the program counter), all in a single instruction.

Annatar 5y ago
Loading and storing multiple registers is by no means weird: the MC68000 family has the movem.(b|w|l) instructions which do exactly that, and it's one of the best things since sliced bread because performance can be gained when used cleverly. Being able to manipulate the program counter in the ARM processors directly is just being honest, simple and straightforward, rather then having it always done implicitly. Seems very intuitive to me now that I think about it.
- brucehoult 5y ago
  Being able to manipulate the program counter directly plays hell with a superscalar and especially OoO processor where you want to be able to predict what the program counter does very accurately so the instruction fetch and decode can run far ahead of the execution. There are four kinds of instructions that play hell with pipeline and OoO design: - instructions that might cause traps, dependent on the values processed - instructions that you don't know whether they will change the control flow - instructions that you don't know where the control flow is going to go to - instructions where you don't know how long they will take to execute RISC-V, for example, bans the first category entirely other than load/store, and carefully separates the other three so any one instruction only had at most one of those problems. ARM load multiple has all of those problems. At least you can examine the register mask at instruction decode time and know whether it will change the PC or not and tag the instruction in the pipeline as being a Jump or not. Imagine if there was a version that took the bitmap from a register instead of being hard-coded... Load/store multiple don't increase performance much if at all on a CPU with an instruction cache and/or an instruction prefetch buffer. On an original 68000 or ARM without any cache, sure, a series of load or store instructions requires interleaving reading the opcodes with reading or writing the data, while load/store multiple eliminates the opcode reads. An instruction cache also eliminates them, leaving only the code size benefits. But load/store multiple is a perfect candidate for using a simple runtime function instead, at least if you have lightweight function call/return as RISC designs usually do.