4 ms·

RISC-v assembly is not substantially easier to write than any other assembly. RISC assemblies in general (aka MIPS, Arm, RV64 etc) require more instructions to

RISC-v assembly is not substantially easier to write than any other assembly. RISC assemblies in general (aka MIPS, Arm, RV64 etc) require more instructions to accomplish the same tasks. I would argue they are designed with compilers in mind more than human authors. Older assemblies expected the programmer to be programming in assembly directly, which is why they allow you to express your intent more directly than RISC. Humans of course can and do write assembly in all of these, but risc-v has not somehow made assembly programming any safer or more portable than it ever was.

sylware 3y ago
RISC-V is a modern load-store ISA. Is is very clean, much more than the mess of x86_64 for instance. It is actually better to write RISC-V than x86_64, even if the later is CISC.
- edgyquant 3y ago
  Even if this is true, which I agree it is, it’s still a 100x more painful than writing a programming language and compiling to RISC-V. That also gives you the benefit of compiling to multiple arch’s
  - sylware 3y ago
    This is where you are wrong: it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run. Short term-ists won't understand as this is going for the long run, and that requires perspective of what happened in software in the last decades.
    - fl0ki 3y ago
      > it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run. This is a bit of a stretch. Not one ISA has lived longer than C without making any changes whatsoevever, but I admit that this could at least be possible for some kinds of devices. What is utterly ludicrous is to suggest that people write code only in RISC-V because all hardware ever built in future will somehow agree to only use RISC-V. If any hardware ever uses any other ISA, then we're back where we started, writing in higher-level languages that can compile to multiple ISAs. What do you believe will fundamentally change this? Anyway, your argument about churn is flawed from a simpler angle anyway. When C, C++, or Rust evolves in future, existing code continues to work. That's the very opposite of "planned obsolescence", it's ensuring that past investment continues to pay future rewards. The ISO working groups and the Rust team go to enormous lengths to ensure code remains compatible while making new advancements. I don't know how much of these processes you've observed in the past, but if you're calling them "planned obsolescence" I would urge you to learn more about them before producing critiques. An ISA can also continue to evolve in strictly backwards-compatible ways, but history has shown there are many reasons that multiple ISAs can coexist and that newer ones may supersede older ones without backwards compatibility. RISC-V may avoid some of those factors, but as it's barely been adopted in the real world at all yet, it's a bit premature to somehow presume it's the last word on ISAs and no new ISAs should ever be created ever again.
      - sylware 3y ago
        I do severely disagree. Something is different with RISC-V as this is a modern ISA and is not locked by some absurd PI in many places in the world like x86_64 and arm, not to mention it is seems the RISC-V guys are actually "doing it". Ofc, RISC-V can still fail as it needs extremely performant implementations all over the board (mobile/server/workstation/"embedded"), and will have to survive the mistakes of its big CPU vendors (usually accute micro-arch bugs). About what you call "evolution" of computer languages, well after decades of coding, that "evolution" is to me mostly tantrums from developers and a scam: "planned obsolescence" and "developer locking" for the benefits of few vendors, that to justify permanent income. I now believe the people doing that are brain-washed, or actually really toxic people (a liability for humanity as a whole). Not to mention, those issues are exponentially boosted by language syntax complexity, with the worst being c++ and now rust. Of course, I did shape this opinion after decades of coding, this is will be alien to short term-ists or inexperienced people. From this global perspective, I think the real way forward would not be to code a kernel in rust, but to code one in RISC-V, and I was voicing my disagrement here, on HN, even though the pro-rust/AI bots are performing accute karma slash only because I have different views on the matter and voicing it... But some people made me think more about the issue of the computer language extremists a bit more, and now I am thinking RISC-V... as a computer language, namely with its "compiler" generating code for other ISA (not a JIT). I may have a look at that in the near future as RISC-V as a computer language should be much more resilient to syntax "planned obsolescence" and "vendor/developer lock-in for permanent income via compiler/syntax grotesque complexity". Hopefully, I did open the eyes of some non AI bots here, while providing some different paths of moving forward.
- MobiusHorizons 3y ago
  I agree that rv64 is easier to write than x86_64. My point was more that earlier ISAs were designed with human authors as a target audience, and that results in differences that are arguably (subjective) easier to hand write. Modern load store architectures are cleaner, but also quite verbose. 6502 is probably more representative of my point than 32bit x86, and most things in the 64 bit era are more compiler focused.
  - sylware 3y ago
    Yep. And from a hard real coding perspective, you are right about verbosity of load and store ISA. Hence the importance of having multi-instruction per line assemblers. Because, without that, coders may be too much tempted to abuse the preprocessor. In RISC-V, some hardware instructions are kind of meant to be used as a group (hardware instruction fusion here we come!), then instead of creating a macro, you would cut and past that group of instructions, properly "isolated" on its line. I say that, because currently I am coding some x86_64, with a intel syntax dialect I can assemble with several assemblers which are fasmg, gas, nasm/yasm. Some of them are not multi-instruction per line, and I am kind of glad this is only CISC x86_64 and not RISC-V :) But the feeling of freedom I get with assembly coding, because being independent of those abominations (I am sorry, but the word is fair...) of compilers (gcc|clang/llvm) is a breath of fresh air. I still code very simple and plain C from time to time, avoiding IS O C tantrum and gcc extension though (and using tinycc, cproc/qbe, simple-cc/qbe C compilers). BTW, thinking out of the box of using a compiler for classic high level and complex syntax languages made me thing about using RISC-V as a language with... its compiler. It "should" be much more resilient to all those pesky long term issues classic complex computer languages suffer from. Maybe, this is actually the sane way forward.

sylware 3y ago

RISC-V is a modern load-store ISA. Is is very clean, much more than the mess of x86_64 for instance. It is actually better to write RISC-V than x86_64, even if the later is CISC.

edgyquant 3y ago
Even if this is true, which I agree it is, it’s still a 100x more painful than writing a programming language and compiling to RISC-V. That also gives you the benefit of compiling to multiple arch’s
- sylware 3y ago
  This is where you are wrong: it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run. Short term-ists won't understand as this is going for the long run, and that requires perspective of what happened in software in the last decades.
  - fl0ki 3y ago
    > it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run. This is a bit of a stretch. Not one ISA has lived longer than C without making any changes whatsoevever, but I admit that this could at least be possible for some kinds of devices. What is utterly ludicrous is to suggest that people write code only in RISC-V because all hardware ever built in future will somehow agree to only use RISC-V. If any hardware ever uses any other ISA, then we're back where we started, writing in higher-level languages that can compile to multiple ISAs. What do you believe will fundamentally change this? Anyway, your argument about churn is flawed from a simpler angle anyway. When C, C++, or Rust evolves in future, existing code continues to work. That's the very opposite of "planned obsolescence", it's ensuring that past investment continues to pay future rewards. The ISO working groups and the Rust team go to enormous lengths to ensure code remains compatible while making new advancements. I don't know how much of these processes you've observed in the past, but if you're calling them "planned obsolescence" I would urge you to learn more about them before producing critiques. An ISA can also continue to evolve in strictly backwards-compatible ways, but history has shown there are many reasons that multiple ISAs can coexist and that newer ones may supersede older ones without backwards compatibility. RISC-V may avoid some of those factors, but as it's barely been adopted in the real world at all yet, it's a bit premature to somehow presume it's the last word on ISAs and no new ISAs should ever be created ever again.
    - sylware 3y ago
      I do severely disagree. Something is different with RISC-V as this is a modern ISA and is not locked by some absurd PI in many places in the world like x86_64 and arm, not to mention it is seems the RISC-V guys are actually "doing it". Ofc, RISC-V can still fail as it needs extremely performant implementations all over the board (mobile/server/workstation/"embedded"), and will have to survive the mistakes of its big CPU vendors (usually accute micro-arch bugs). About what you call "evolution" of computer languages, well after decades of coding, that "evolution" is to me mostly tantrums from developers and a scam: "planned obsolescence" and "developer locking" for the benefits of few vendors, that to justify permanent income. I now believe the people doing that are brain-washed, or actually really toxic people (a liability for humanity as a whole). Not to mention, those issues are exponentially boosted by language syntax complexity, with the worst being c++ and now rust. Of course, I did shape this opinion after decades of coding, this is will be alien to short term-ists or inexperienced people. From this global perspective, I think the real way forward would not be to code a kernel in rust, but to code one in RISC-V, and I was voicing my disagrement here, on HN, even though the pro-rust/AI bots are performing accute karma slash only because I have different views on the matter and voicing it... But some people made me think more about the issue of the computer language extremists a bit more, and now I am thinking RISC-V... as a computer language, namely with its "compiler" generating code for other ISA (not a JIT). I may have a look at that in the near future as RISC-V as a computer language should be much more resilient to syntax "planned obsolescence" and "vendor/developer lock-in for permanent income via compiler/syntax grotesque complexity". Hopefully, I did open the eyes of some non AI bots here, while providing some different paths of moving forward.
MobiusHorizons 3y ago
I agree that rv64 is easier to write than x86_64. My point was more that earlier ISAs were designed with human authors as a target audience, and that results in differences that are arguably (subjective) easier to hand write. Modern load store architectures are cleaner, but also quite verbose. 6502 is probably more representative of my point than 32bit x86, and most things in the 64 bit era are more compiler focused.
- sylware 3y ago
  Yep. And from a hard real coding perspective, you are right about verbosity of load and store ISA. Hence the importance of having multi-instruction per line assemblers. Because, without that, coders may be too much tempted to abuse the preprocessor. In RISC-V, some hardware instructions are kind of meant to be used as a group (hardware instruction fusion here we come!), then instead of creating a macro, you would cut and past that group of instructions, properly "isolated" on its line. I say that, because currently I am coding some x86_64, with a intel syntax dialect I can assemble with several assemblers which are fasmg, gas, nasm/yasm. Some of them are not multi-instruction per line, and I am kind of glad this is only CISC x86_64 and not RISC-V :) But the feeling of freedom I get with assembly coding, because being independent of those abominations (I am sorry, but the word is fair...) of compilers (gcc|clang/llvm) is a breath of fresh air. I still code very simple and plain C from time to time, avoiding IS O C tantrum and gcc extension though (and using tinycc, cproc/qbe, simple-cc/qbe C compilers). BTW, thinking out of the box of using a compiler for classic high level and complex syntax languages made me thing about using RISC-V as a language with... its compiler. It "should" be much more resilient to all those pesky long term issues classic complex computer languages suffer from. Maybe, this is actually the sane way forward.