3 ms·

The base ISA is very plain and RISCy. But I'd encourage you to go read the Bitmanip extension and find an opcode in there that doesn't have at least one obscure

by tux3 6y ago

The base ISA is very plain and RISCy. But I'd encourage you to go read the Bitmanip extension and find an opcode in there that doesn't have at least one obscure alternate use! =) As for addressing modes, yeah I do wish we had a little bit more as a software person (but not as a hobby/toy cpu writer!). The current stuff can encode a surprising number of simple loops efficiently if you do it right, but of course if you come from x86 you'll have to do more with less...

Taniwha 6y ago
Essentially it wouldn't be RISC is there were more complex addressing modes (if you can't do it in one clock at speed .....)
- msla 6y ago
  Complex addressing modes are un-RISCy because they're harder to pipeline: Memory accesses might result in page faults, and if you have complicated addressing modes, all of a sudden you have some nontrivial ALU state to back out before you can handle the fault. It's a lot simpler to have rock-dumb load/store opcodes and then do all ALU work in terms of register-register opcodes which don't touch memory. John Mashey (helped design the MIPS architecture) has a great account of how complex addressing modes are difficult to work with partway down this page: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html I can't link to it directly, but it starts with this text: > General comment: this may sound weird, but in the long term, it might be easier to deal with a really complicated bunch of instruction formats, than with a complex set of addressing modes, because at least the former is more amenable to pre-decoding into a cache of decoded instructions that can be pipelined reasonably, whereas the pipeline on the latter can get very tricky (examples to follow). This can lead to the funny effect that a relatively "clean", orthogonal archiecture may actually be harder to make run fast than one that is less clean. Obviously, every weirdness has it's penalties.... But consider the fundamental difficulty of pipelining something like (on a VAX): ADDL @(R1)+,@(R1)+,@(R2)+ > (I.e., something that, might theoretically arise from: register **r1, **r2; **r2++ = **r1++ + **r1++; ... and he then goes on a detailed step-by-step process of what has to happen to execute that opcode in the world of page faults and unaligned memory accesses, another thing classic RISC chips were very down on, but I think they've gotten a bit looser on them in recent decades.
  - devit 6y ago
    This only applies to addressing modes with side effects, which e.g. x86 doesn't have.
    - Taniwha 6y ago
      well except for push/pop, and all the microcoded stuff. IMHO the x86 has been successful because it started out semi-RISCy - no indirect addressing modes, no auto inc/dec, only one memory access per instruction - (except for push/pop and the microcoded segment stuff). It means either an instruction goes to completion, or it faults, there's no state change to undo if something takes a TLB miss - compared with a 68k etc it's an easy implementation
    - ordu 6y ago
      rep movsb
throwaway_pdp09 6y ago
I guess these are the bitmanip stuff you mention https://github.com/riscv/riscv-bitmanip https://github.com/riscv/riscv-bitmanip They're a proposal only (and I don't think they're an official proposal), and having read them it seems the guy just shoehorned in anything he could think of. I'm curious to see how much of it will be accepted.
- tux3 6y ago
  I can see why you'd say that yeah, it could probably use some trimming down of the less widely applicable instructions. But I don't otherwise think having a set of disparate, seemingly unrelated instructions is a bad thing for something like bitmanip, as long as they all pull their weight. I think they do have an official working group. I remember reading a few months ago their working GCC PoC had ~4% dynaminc instruction reduction in SPECint and some 5% perf improvement. Nothing world-shattering, but considering that the instructions are pretty lightweight to implement in hardware, the cost-benefit seems decent. (Full disclosure: I am not a RISC-V member or particularly invested in bitmanip, just some random person going off of what I remember!)
msla 6y ago
> The base ISA is very plain and RISCy. But I'd encourage you to go read the Bitmanip extension and find an opcode in there that doesn't have at least one obscure alternate use! =) Ah, the Hacker's Delight opcodes! :) https://en.wikipedia.org/wiki/Hacker%27s_Delight https://en.wikipedia.org/wiki/Hacker%27s_Delight https://www.eetimes.com/book-review-hackers-delight-by-henry-s-warren-jr/ https://www.eetimes.com/book-review-hackers-delight-by-henry...

by tux3 6y ago

Taniwha 6y ago

Essentially it wouldn't be RISC is there were more complex addressing modes (if you can't do it in one clock at speed .....)

msla 6y ago
Complex addressing modes are un-RISCy because they're harder to pipeline: Memory accesses might result in page faults, and if you have complicated addressing modes, all of a sudden you have some nontrivial ALU state to back out before you can handle the fault. It's a lot simpler to have rock-dumb load/store opcodes and then do all ALU work in terms of register-register opcodes which don't touch memory. John Mashey (helped design the MIPS architecture) has a great account of how complex addressing modes are difficult to work with partway down this page: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html I can't link to it directly, but it starts with this text: > General comment: this may sound weird, but in the long term, it might be easier to deal with a really complicated bunch of instruction formats, than with a complex set of addressing modes, because at least the former is more amenable to pre-decoding into a cache of decoded instructions that can be pipelined reasonably, whereas the pipeline on the latter can get very tricky (examples to follow). This can lead to the funny effect that a relatively "clean", orthogonal archiecture may actually be harder to make run fast than one that is less clean. Obviously, every weirdness has it's penalties.... But consider the fundamental difficulty of pipelining something like (on a VAX): ADDL @(R1)+,@(R1)+,@(R2)+ > (I.e., something that, might theoretically arise from: register **r1, **r2; **r2++ = **r1++ + **r1++; ... and he then goes on a detailed step-by-step process of what has to happen to execute that opcode in the world of page faults and unaligned memory accesses, another thing classic RISC chips were very down on, but I think they've gotten a bit looser on them in recent decades.
- devit 6y ago
  This only applies to addressing modes with side effects, which e.g. x86 doesn't have.
  - Taniwha 6y ago
    well except for push/pop, and all the microcoded stuff. IMHO the x86 has been successful because it started out semi-RISCy - no indirect addressing modes, no auto inc/dec, only one memory access per instruction - (except for push/pop and the microcoded segment stuff). It means either an instruction goes to completion, or it faults, there's no state change to undo if something takes a TLB miss - compared with a 68k etc it's an easy implementation
  - ordu 6y ago
    rep movsb

throwaway_pdp09 6y ago

I guess these are the bitmanip stuff you mention https://github.com/riscv/riscv-bitmanip https://github.com/riscv/riscv-bitmanip They're a proposal only (and I don't think they're an official proposal), and having read them it seems the guy just shoehorned in anything he could think of. I'm curious to see how much of it will be accepted.

tux3 6y ago
I can see why you'd say that yeah, it could probably use some trimming down of the less widely applicable instructions. But I don't otherwise think having a set of disparate, seemingly unrelated instructions is a bad thing for something like bitmanip, as long as they all pull their weight. I think they do have an official working group. I remember reading a few months ago their working GCC PoC had ~4% dynaminc instruction reduction in SPECint and some 5% perf improvement. Nothing world-shattering, but considering that the instructions are pretty lightweight to implement in hardware, the cost-benefit seems decent. (Full disclosure: I am not a RISC-V member or particularly invested in bitmanip, just some random person going off of what I remember!)

msla 6y ago

> The base ISA is very plain and RISCy. But I'd encourage you to go read the Bitmanip extension and find an opcode in there that doesn't have at least one obscure alternate use! =) Ah, the Hacker's Delight opcodes! :) https://en.wikipedia.org/wiki/Hacker%27s_Delight https://en.wikipedia.org/wiki/Hacker%27s_Delight https://www.eetimes.com/book-review-hackers-delight-by-henry-s-warren-jr/ https://www.eetimes.com/book-review-hackers-delight-by-henry...