5 ms·

What do you mean a risc-v kernel? One written in RISC v assembly? Because that would be terrible. Risc-v is the instruction set architecture, rust is a program

What do you mean a risc-v kernel? One written in RISC v assembly? Because that would be terrible. Risc-v is the instruction set architecture, rust is a programming language. You can port languages to target ISAs. Linux can already run in riscv. The ISA of the hardware and the language the software it runs are completely different issues.

sylware 3y ago
Well, I think you are wrong, and that would actually be the real way forward: an assembly written kernel using a worldwide standard ISA, aka RISC-V. Of course, it would have not to abuse any preprocessor, because moving the issue which is the complexity of the compiler dependency to a preprocessor complexity dependency would nullify everything. Doing that in rust, is just doing the mistake of linux all over again, actually even worse, since rust syntax is much more complex than C with gcc extensions.
- vkazanov 3y ago
  You can get your assembly-written kernel right now for every OS out there: just compile Linux using a RISC-V backend of your favourite compiler.
  - sylware 3y ago
    This is severely wrong: you cannot compare hand written and properly commented assembly with compiler generated one.
    - bluGill 3y ago
      Compare in what way? Handwritten and commented assembly will be much easier for a human to maintain. However modern optimizers are much more likely to apply the correct micro optimization tricks to get the best performance - and they can output different assembly for different variations of the same instruction set with ease, something that would make the hand written assembly much more complex.
      - sylware 3y ago
        "Handwritten and commented assembly will be much easier for a human to maintain" It seems some people here have issue acknowledging that. But where you are wrong: for modern micro-archs, everything mostly happens at runtime. Specific micro-archs optimizations are not done anymore, the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end). Usually, you only just care of basic static optimizations, like cache line, fetch code window, alignment, which are more writing "correct" assembly code than anything else. And even with that, in the worst case scenarios, one could write some specific micro-arch code paths, not an issue while thinking long term of many software components life cycle, which would be "installed"/"branched to" at runtime. At least that knowledge would not be hidden deep in the absurd complexity of an optimizing compiler...
        bluGill 3y ago
        Unless you are building your own custom kernel (ie gentoo) CPU specific optimizations are not worth it as they are worse for any other CPU even if the code is still run. Most software never had those micro optimizations applied, because most software wants to have one build that runs any many different CPUs, but if you want to make an exception it is still possible with compiled code. While you can write those micro optimizations for each CPU by hand, they not worth the human cost except in very rare situations. In most cases of course you can't measure the difference, as only a couple CPU cycles are saved.
        sylware 3y ago
        This is what I just said. Then we agree on that matter.
        fl0ki 3y ago
        > the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end) This is not the reason why. Indeed x86_64 has a much broader instruction & register baseline than i386 did, so the impact of per-CPU tuning is less than it used to be. But even a generic compiled Linux selects CPU instruction sets at runtime for things like hardware-accelerated cryptography, because those instruction sets actually matter. If you have evidence that modern microcode magically recognizes hand-written AES and replaces it with the equivalent AES-NI instructions, please be sure to send Linus your patches with benchmarks.
- mkl 3y ago
  What you are proposing is so terrible in practice that people have invented hundreds of programming languages to escape it. Millions of person-hours have been spent on getting away from what you say is desirable.
  - sylware 3y ago
    You are right in a legacy context where the mess of ISAs required an abstraction of the assembly language. But where you are wrong is, moving forward in a world with a modern worldwide standard ISA (RISC-V) is actually writing a kernel in assembly (without abusing any preprocessing).
    - mkl 3y ago
      People have had the ability to do that for decades, and they have almost always chosen not to when they had the option, because it's terrible. RISC-V is nothing revolutionary on that front, and doesn't magically make it better. Without preprocessing you won't have variable names or jump label names or strings, which is even more terrible. Please give us some actual evidence, instead of just saying "you're wrong", because the position you're taking seems extreme and, frankly, bonkers.
      - sylware 3y ago
        I said without abusing the preprocessing, not without preprocessing at all. My opinion is this is wrong, and I did voice my disagrement and gave my own view on the matter. If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN.
        jodrellblank 3y ago
        > "If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN." It's refusing to backup your position with anything more than saying "you're wrong" "you're wrong" "you're wrong". You've repeatedly been asked to explain why RISC_V would be better, why RISC_V changes anything, what you propose for how it would work (e.g. emulators), and you haven't. That's annoying, timewasting, and downvoteworthy.
- BatmanAoD 3y ago
  Are you proposing a kernel that would only run on risc-v hardware, or expecting that people would run some kind of emulator? ....or do you think that because RISC-V is "standard", assembly for RISC-V would run on any hardware?
  - sylware 3y ago
    The "right way" would be CPU vendors to support that standard. But I have thought about running a 64bits RISC-V interpreter on x86_64 (Mr Bellard, ffmpeg, tinycc, etc, wrote a risc-v emulator which could be as a based for that), and that in the kernel. Basically, you would have RISC-V assembly for x86_64 arch: at least, RISC-V here would be stellar more robust and stable that all the features creeps we have in the linux kernel because of the never ending gcc extensions addition and latest ISO C tantrums...
    - BatmanAoD 3y ago
      So the "right way" is to replace all hardware with new hardware, and the second-best solution is for CISC systems to emulate a specific RISC architecture? And you think this will be more maintainable, performant, etc? Do you have even a shred of evidence that this makes any sense at all, beyond "RISC is a good standard"?
      - sylware 3y ago
        This would not happen overnight! It would a slow process. Of course you will need still RISC-V support in current compilers for legacy software. RISC-V is a modern "good enough" with "good balance" ISA, everything is about trade-off, hence "perfection" does not make any sense. What is really different with RISC-V: it is already there, moving forward, is worldwide PI lockfree (unlike x86_64 and arm). Ofc, without extremely performant implementations (micro-arch and silicium process), all over the board (server/mobile/workstation/"embedded") it will probably fail. And I do believe we could get a very good middle ground with very high level language interpreters (python/lua/etc) directly coded in RISC-V assembly. And I am thinking about RISC-V... as a computer language with some compilerS (not JIT). I may investigate how much out-of-the-box-thinking and disruptive this is, hopefully soon enough.

sylware 3y ago

Well, I think you are wrong, and that would actually be the real way forward: an assembly written kernel using a worldwide standard ISA, aka RISC-V. Of course, it would have not to abuse any preprocessor, because moving the issue which is the complexity of the compiler dependency to a preprocessor complexity dependency would nullify everything. Doing that in rust, is just doing the mistake of linux all over again, actually even worse, since rust syntax is much more complex than C with gcc extensions.

vkazanov 3y ago
You can get your assembly-written kernel right now for every OS out there: just compile Linux using a RISC-V backend of your favourite compiler.
- sylware 3y ago
  This is severely wrong: you cannot compare hand written and properly commented assembly with compiler generated one.
  - bluGill 3y ago
    Compare in what way? Handwritten and commented assembly will be much easier for a human to maintain. However modern optimizers are much more likely to apply the correct micro optimization tricks to get the best performance - and they can output different assembly for different variations of the same instruction set with ease, something that would make the hand written assembly much more complex.
    - sylware 3y ago
      "Handwritten and commented assembly will be much easier for a human to maintain" It seems some people here have issue acknowledging that. But where you are wrong: for modern micro-archs, everything mostly happens at runtime. Specific micro-archs optimizations are not done anymore, the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end). Usually, you only just care of basic static optimizations, like cache line, fetch code window, alignment, which are more writing "correct" assembly code than anything else. And even with that, in the worst case scenarios, one could write some specific micro-arch code paths, not an issue while thinking long term of many software components life cycle, which would be "installed"/"branched to" at runtime. At least that knowledge would not be hidden deep in the absurd complexity of an optimizing compiler...
      - bluGill 3y ago
        Unless you are building your own custom kernel (ie gentoo) CPU specific optimizations are not worth it as they are worse for any other CPU even if the code is still run. Most software never had those micro optimizations applied, because most software wants to have one build that runs any many different CPUs, but if you want to make an exception it is still possible with compiled code. While you can write those micro optimizations for each CPU by hand, they not worth the human cost except in very rare situations. In most cases of course you can't measure the difference, as only a couple CPU cycles are saved.
        sylware 3y ago
        This is what I just said. Then we agree on that matter.
      - fl0ki 3y ago
        > the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end) This is not the reason why. Indeed x86_64 has a much broader instruction & register baseline than i386 did, so the impact of per-CPU tuning is less than it used to be. But even a generic compiled Linux selects CPU instruction sets at runtime for things like hardware-accelerated cryptography, because those instruction sets actually matter. If you have evidence that modern microcode magically recognizes hand-written AES and replaces it with the equivalent AES-NI instructions, please be sure to send Linus your patches with benchmarks.
mkl 3y ago
What you are proposing is so terrible in practice that people have invented hundreds of programming languages to escape it. Millions of person-hours have been spent on getting away from what you say is desirable.
- sylware 3y ago
  You are right in a legacy context where the mess of ISAs required an abstraction of the assembly language. But where you are wrong is, moving forward in a world with a modern worldwide standard ISA (RISC-V) is actually writing a kernel in assembly (without abusing any preprocessing).
  - mkl 3y ago
    People have had the ability to do that for decades, and they have almost always chosen not to when they had the option, because it's terrible. RISC-V is nothing revolutionary on that front, and doesn't magically make it better. Without preprocessing you won't have variable names or jump label names or strings, which is even more terrible. Please give us some actual evidence, instead of just saying "you're wrong", because the position you're taking seems extreme and, frankly, bonkers.
    - sylware 3y ago
      I said without abusing the preprocessing, not without preprocessing at all. My opinion is this is wrong, and I did voice my disagrement and gave my own view on the matter. If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN.
      - jodrellblank 3y ago
        > "If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN." It's refusing to backup your position with anything more than saying "you're wrong" "you're wrong" "you're wrong". You've repeatedly been asked to explain why RISC_V would be better, why RISC_V changes anything, what you propose for how it would work (e.g. emulators), and you haven't. That's annoying, timewasting, and downvoteworthy.
BatmanAoD 3y ago
Are you proposing a kernel that would only run on risc-v hardware, or expecting that people would run some kind of emulator? ....or do you think that because RISC-V is "standard", assembly for RISC-V would run on any hardware?
- sylware 3y ago
  The "right way" would be CPU vendors to support that standard. But I have thought about running a 64bits RISC-V interpreter on x86_64 (Mr Bellard, ffmpeg, tinycc, etc, wrote a risc-v emulator which could be as a based for that), and that in the kernel. Basically, you would have RISC-V assembly for x86_64 arch: at least, RISC-V here would be stellar more robust and stable that all the features creeps we have in the linux kernel because of the never ending gcc extensions addition and latest ISO C tantrums...
  - BatmanAoD 3y ago
    So the "right way" is to replace all hardware with new hardware, and the second-best solution is for CISC systems to emulate a specific RISC architecture? And you think this will be more maintainable, performant, etc? Do you have even a shred of evidence that this makes any sense at all, beyond "RISC is a good standard"?
    - sylware 3y ago
      This would not happen overnight! It would a slow process. Of course you will need still RISC-V support in current compilers for legacy software. RISC-V is a modern "good enough" with "good balance" ISA, everything is about trade-off, hence "perfection" does not make any sense. What is really different with RISC-V: it is already there, moving forward, is worldwide PI lockfree (unlike x86_64 and arm). Ofc, without extremely performant implementations (micro-arch and silicium process), all over the board (server/mobile/workstation/"embedded") it will probably fail. And I do believe we could get a very good middle ground with very high level language interpreters (python/lua/etc) directly coded in RISC-V assembly. And I am thinking about RISC-V... as a computer language with some compilerS (not JIT). I may investigate how much out-of-the-box-thinking and disruptive this is, hopefully soon enough.