4 ms·

I’ve had a lot of fun learning RISC-V assembly off and on over the last year. I went through a colleague of mine’s tutorial series on implementing an operating

I’ve had a lot of fun learning RISC-V assembly off and on over the last year. I went through a colleague of mine’s tutorial series on implementing an operating system targeting RISC-V using Rust. Now I’m working on my own small assembler for RISC-V. It’s been so much more fun to learn than x86! Edit: link to the tutorial (http://osblog.stephenmarz.com/ http://osblog.stephenmarz.com/)

faitswulff 6y ago
Is this the tutorial you mentioned? EDIT - ah nevermind, turns out there are at least two RISC-V OS tutorials in Rust: - https://gist.github.com/cb372/5f6bf16ca0682541260ae52fc11ea3bb https://gist.github.com/cb372/5f6bf16ca0682541260ae52fc11ea3... - http://osblog.stephenmarz.com/ http://osblog.stephenmarz.com/
- azhenley 6y ago
  The second one! Sorry, I meant to include it. I updated my comment.
msla 6y ago
To me, a fun ISA is one which provides opportunities for golf, which basically means CISC ISAs with lots of different ways to do things. RISC-V is proudly, definitively not that and that's a good design decision, but you'll never be able to replace a stretch of straightforward code with a handful of more obscure opcodes and complicated addressing modes. I'll always have SIMH.
- garmaine 6y ago
  Yeah that’s a bit like saying you enjoy spelling bees, whereas a language that is idiomatic enough to allow for competitive spelling to exist as a real thing has fundamentally failed at its job.
  - msla 6y ago
    Orthography is orthogonal to a language, as transliteration proves. Putonghua is Putonghua regardless of whether it's written in Sinitic characters, Yale Romanization, or Pinyin. Also, don't run down someone else's hobbies. It's uncouth.
    - garmaine 6y ago
      I’m not..? It’s fine to play code golf with CISC-y architectures. But being able to do that is an anti-goal to a compiler-friendly architecture, as RISC tries to be.
- 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.
- zozbot234 6y ago
  > but you'll never be able to replace a stretch of straightforward code with a handful of more obscure opcodes and complicated addressing modes. It just changes the target for a (human or computer) superoptimizer. Instead of using weird CISCy instructions, you're optimizing things like register allocation and the binary 'interfaces' between parts of your code. At a slightly higher level than a single insn, assembly coding is always about having "lots of different ways to do things"!
- rwmj 6y ago
  Sort of. The fun optimizations are a little different now: Can you choose your registers so you can make maximum use of Compressed instructions? And for higher performance chips, can you select sequences of instructions that trigger macro-op fusion?
pjmlp 6y ago
I grew up with Z80, back in the day when business applications had enough Assembly into them. Used 68000 and all x86 variants until Pentium (by then it was too much effort to write Assembly by hand), also had to deal with MIPS, PowerPC, SPARC, ARM and various bytecode formats. X86 remains my favourite, in tooling and high level opcodes with cool tricks.
- rwmj 6y ago
  Really? Z80 and even moreso 68000 had lovely orthogonal assembly languages which were a pleasure to program in.
  - pjmlp 6y ago
    Yes really, I never got the point of that, specially given the weaker addressing modes. Actually the only thing that pissed me off, but was sorted out with 386 anyway, was the segmented memory.
fwsgonzo 6y ago
Is there a std-variant for rv64g? And if not, how easy is it to setup for rv64gc? I have an emulator with a known rv64gc bug, and it's faster to emulate uncompressed instructions (until I start translating them, I guess). Also, what language is the assembler written in? Is it embeddable?

faitswulff 6y ago

Is this the tutorial you mentioned? EDIT - ah nevermind, turns out there are at least two RISC-V OS tutorials in Rust: - https://gist.github.com/cb372/5f6bf16ca0682541260ae52fc11ea3bb https://gist.github.com/cb372/5f6bf16ca0682541260ae52fc11ea3... - http://osblog.stephenmarz.com/ http://osblog.stephenmarz.com/

azhenley 6y ago
The second one! Sorry, I meant to include it. I updated my comment.

msla 6y ago

To me, a fun ISA is one which provides opportunities for golf, which basically means CISC ISAs with lots of different ways to do things. RISC-V is proudly, definitively not that and that's a good design decision, but you'll never be able to replace a stretch of straightforward code with a handful of more obscure opcodes and complicated addressing modes. I'll always have SIMH.

garmaine 6y ago
Yeah that’s a bit like saying you enjoy spelling bees, whereas a language that is idiomatic enough to allow for competitive spelling to exist as a real thing has fundamentally failed at its job.
- msla 6y ago
  Orthography is orthogonal to a language, as transliteration proves. Putonghua is Putonghua regardless of whether it's written in Sinitic characters, Yale Romanization, or Pinyin. Also, don't run down someone else's hobbies. It's uncouth.
  - garmaine 6y ago
    I’m not..? It’s fine to play code golf with CISC-y architectures. But being able to do that is an anti-goal to a compiler-friendly architecture, as RISC tries to be.
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.
zozbot234 6y ago
> but you'll never be able to replace a stretch of straightforward code with a handful of more obscure opcodes and complicated addressing modes. It just changes the target for a (human or computer) superoptimizer. Instead of using weird CISCy instructions, you're optimizing things like register allocation and the binary 'interfaces' between parts of your code. At a slightly higher level than a single insn, assembly coding is always about having "lots of different ways to do things"!
rwmj 6y ago
Sort of. The fun optimizations are a little different now: Can you choose your registers so you can make maximum use of Compressed instructions? And for higher performance chips, can you select sequences of instructions that trigger macro-op fusion?

pjmlp 6y ago

I grew up with Z80, back in the day when business applications had enough Assembly into them. Used 68000 and all x86 variants until Pentium (by then it was too much effort to write Assembly by hand), also had to deal with MIPS, PowerPC, SPARC, ARM and various bytecode formats. X86 remains my favourite, in tooling and high level opcodes with cool tricks.

rwmj 6y ago
Really? Z80 and even moreso 68000 had lovely orthogonal assembly languages which were a pleasure to program in.
- pjmlp 6y ago
  Yes really, I never got the point of that, specially given the weaker addressing modes. Actually the only thing that pissed me off, but was sorted out with 386 anyway, was the segmented memory.

fwsgonzo 6y ago

Is there a std-variant for rv64g? And if not, how easy is it to setup for rv64gc? I have an emulator with a known rv64gc bug, and it's faster to emulate uncompressed instructions (until I start translating them, I guess). Also, what language is the assembler written in? Is it embeddable?