4 ms·

Again: have you looked at the assembler code? Are you able to compare MC68000 assembler and RISC-V assembler? Are you able to compare SPARC assembler and RISC-V

Again: have you looked at the assembler code? Are you able to compare MC68000 assembler and RISC-V assembler? Are you able to compare SPARC assembler and RISC-V assembler? Without being able to do that, it's going to be exceptionally difficult for me to contribute any more to the discussion, especially typing on a mobile telephone. That's my contribution for now, I'm pointing out what to compare with. That point was obviously missed. You have to bring something to the table too, instead of just demanding everything be spoon fed and served on a Silver platter to you.

waterhouse 8y ago
I carefully studied the 2.1 and 2.2 versions of the spec. I wrote, in Racket, a miniature interpreter for lists of RISC-V instructions (just symbolic lists, not the byte strings they assemble into), then wrote programs to compute triangular numbers and Fibonacci, and verified they worked. I've built the RISC-V toolchain and compiled a few test C programs and run them in "spike". I don't think I took more than a glance at the "gcc -S" output. I have no familiarity with SPARC or Motorola assembly, but I have decent familiarity with x86-64 assembly, having written what looks like a couple dozen miniature test programs and one medium-sized program, and having tried a few times to write a decent x86-64 assembler. I found the RISC-V spec enjoyable to read, especially with all the rationales; it felt clean, minimal, and well-thought-out. Writing a program in it was probably not much different from writing in x86-64 assembly. The encodings seemed much easier to deal with than x86-64, though as mentioned I didn't go as far as writing an encoder. What kinds of important features are present in SPARC or MC68k but not in RISC-V? Are they absent from x86-64 as well?
- Annatar 8y ago
  Motorola assembler is what is known as orthogonal instruction set. The flow is logical: move.b for byte, move.w for word, move.l for longword, from source to destination, which reflects real life. The assembler reads almost like a high level programming language. The register scheme is intuitive as well, from a0-a7 being the address, to d0-d7 being the data registers. Now, let's do a mental exercise: I'm going to load an effective address relative to the program counter, 32-bits wide, into the 1st address register. Then, I'm going to load an arbitrary value from an arbitrary memory location into the second address register. Do the same in RISC-V; compare intuitiveness. lea MemoryAddress(pc), a0 move.l $00bfe001, a1 rts MemoryAddress: DC.l 0
  - waterhouse 8y ago
    Indeed, in RISC-V, full 32-bit constants must be broken across two instructions. The translation goes: ; 1. lea MemoryAddress(pc), a0 auipc a0, [upper 20 bits of (MemoryAddress - label)] addi a0, a0, [lower 12 bits of (MemoryAddress - label)] label: ; 2. move.l #$00bfe001, a1 lui a1, 0x00bfe000 addi a1, a1, 0x001 ; 3. rts jalr x0, x1, 0 It is cumbersome in that sense. But it will probably be handled by an assembler (as a macro or builtin). The spec contains an appendix of "pseudoinstructions", which gives the first translation above. There isn't even a dedicated "move" instruction—it's just "addi dst, src, 0" by convention! Clearly anyone writing assembly will use at least that pseudoinstruction. If there's a canonical format for "pseudoinstructions", and all assemblers handle them in the same way, and the abstraction doesn't leak in any way (i.e. the only temporary registers you use are ones you overwrite fully by the end; it is true that now some "instructions" have longer encodings, but that comes with the compressed instructions anyway; and it is true that an interrupt could happen between the two halves of the "instruction", but I think that shouldn't make a difference), then I don't think there's much of a problem.
    - Annatar 8y ago
      "Indeed, in RISC-V, full 32-bit constants must be broken across two instructions." Any RISC processor has that issue, because encoding is fixed at 32-bits to keep the hardware simple. That's not what I'm referring to. Look at that retardation, "auipc". Because "auipc" is intuitive, right? (For the record, I'm being sarcastic.) What the hell was the instruction designer smoking? Then there is the square bracket notation, like on intel, and intel has some of the most idiotic, non-conventional assembler syntax -- and this thing mimics something so bad? Every other processor uses parenthesis, that's a well understood norm. Then there is more intel retardation in the form of dst, src (or dst, src, src on RISC). What kind of a warped, twisted mind came up with that? What was going on in that person's head to work in such twisted ways? Then there's the "cherry on top": jalr x0, x1, 0 ; because "jalr" is intuitive as well, it immediately tells you what it does? You'll know a bad processor design by its instruction set. Always and forever.
      - 8y ago
- brandmeyer 8y ago
  There are a few instructions that nearly every modern processor ended up adopting, but RISC-V still lacks. Off the top of my head, (with the RV ISA developers response in parenthesis): - bitwise rotate (let them eat macro-op fusion) - byte and bit swapping (strictly missing from RV, although proposals exist) - leading zero count, trailing zero count, and popcount (strictly missing from RV, proposals exist) - efficient multiword arithmetic (let them eat macro-op fusion, or long dependency chains) - base + [scaled] index addressing modes (you don't really need those) - multi-register save/restore instructions (ARMv8 doesn't have them / RVC is equivalent in density to ARMv8, nanoMIPS is irrelevant, let them eat millicode) So yeah, there are deficiencies. None of them are crippling, but I wouldn't say that RV is super-wham-o-dyne, either.

waterhouse 8y ago

I carefully studied the 2.1 and 2.2 versions of the spec. I wrote, in Racket, a miniature interpreter for lists of RISC-V instructions (just symbolic lists, not the byte strings they assemble into), then wrote programs to compute triangular numbers and Fibonacci, and verified they worked. I've built the RISC-V toolchain and compiled a few test C programs and run them in "spike". I don't think I took more than a glance at the "gcc -S" output. I have no familiarity with SPARC or Motorola assembly, but I have decent familiarity with x86-64 assembly, having written what looks like a couple dozen miniature test programs and one medium-sized program, and having tried a few times to write a decent x86-64 assembler. I found the RISC-V spec enjoyable to read, especially with all the rationales; it felt clean, minimal, and well-thought-out. Writing a program in it was probably not much different from writing in x86-64 assembly. The encodings seemed much easier to deal with than x86-64, though as mentioned I didn't go as far as writing an encoder. What kinds of important features are present in SPARC or MC68k but not in RISC-V? Are they absent from x86-64 as well?

Annatar 8y ago
Motorola assembler is what is known as orthogonal instruction set. The flow is logical: move.b for byte, move.w for word, move.l for longword, from source to destination, which reflects real life. The assembler reads almost like a high level programming language. The register scheme is intuitive as well, from a0-a7 being the address, to d0-d7 being the data registers. Now, let's do a mental exercise: I'm going to load an effective address relative to the program counter, 32-bits wide, into the 1st address register. Then, I'm going to load an arbitrary value from an arbitrary memory location into the second address register. Do the same in RISC-V; compare intuitiveness. lea MemoryAddress(pc), a0 move.l $00bfe001, a1 rts MemoryAddress: DC.l 0
- waterhouse 8y ago
  Indeed, in RISC-V, full 32-bit constants must be broken across two instructions. The translation goes: ; 1. lea MemoryAddress(pc), a0 auipc a0, [upper 20 bits of (MemoryAddress - label)] addi a0, a0, [lower 12 bits of (MemoryAddress - label)] label: ; 2. move.l #$00bfe001, a1 lui a1, 0x00bfe000 addi a1, a1, 0x001 ; 3. rts jalr x0, x1, 0 It is cumbersome in that sense. But it will probably be handled by an assembler (as a macro or builtin). The spec contains an appendix of "pseudoinstructions", which gives the first translation above. There isn't even a dedicated "move" instruction—it's just "addi dst, src, 0" by convention! Clearly anyone writing assembly will use at least that pseudoinstruction. If there's a canonical format for "pseudoinstructions", and all assemblers handle them in the same way, and the abstraction doesn't leak in any way (i.e. the only temporary registers you use are ones you overwrite fully by the end; it is true that now some "instructions" have longer encodings, but that comes with the compressed instructions anyway; and it is true that an interrupt could happen between the two halves of the "instruction", but I think that shouldn't make a difference), then I don't think there's much of a problem.
  - Annatar 8y ago
    "Indeed, in RISC-V, full 32-bit constants must be broken across two instructions." Any RISC processor has that issue, because encoding is fixed at 32-bits to keep the hardware simple. That's not what I'm referring to. Look at that retardation, "auipc". Because "auipc" is intuitive, right? (For the record, I'm being sarcastic.) What the hell was the instruction designer smoking? Then there is the square bracket notation, like on intel, and intel has some of the most idiotic, non-conventional assembler syntax -- and this thing mimics something so bad? Every other processor uses parenthesis, that's a well understood norm. Then there is more intel retardation in the form of dst, src (or dst, src, src on RISC). What kind of a warped, twisted mind came up with that? What was going on in that person's head to work in such twisted ways? Then there's the "cherry on top": jalr x0, x1, 0 ; because "jalr" is intuitive as well, it immediately tells you what it does? You'll know a bad processor design by its instruction set. Always and forever.
    - 8y ago
brandmeyer 8y ago
There are a few instructions that nearly every modern processor ended up adopting, but RISC-V still lacks. Off the top of my head, (with the RV ISA developers response in parenthesis): - bitwise rotate (let them eat macro-op fusion) - byte and bit swapping (strictly missing from RV, although proposals exist) - leading zero count, trailing zero count, and popcount (strictly missing from RV, proposals exist) - efficient multiword arithmetic (let them eat macro-op fusion, or long dependency chains) - base + [scaled] index addressing modes (you don't really need those) - multi-register save/restore instructions (ARMv8 doesn't have them / RVC is equivalent in density to ARMv8, nanoMIPS is irrelevant, let them eat millicode) So yeah, there are deficiencies. None of them are crippling, but I wouldn't say that RV is super-wham-o-dyne, either.