Hacker News Reader

Comment by sylware | Hacker News Reader

But GPU drivers require a fairly big team. We must have a GPU hardware programming "standard" first. And I would favor a risc-v kernel instead to avoid the dependency on a super complex syntax (rust) compiler and do gcc-dependency-like mistake all over again. For this reason, eating the bullet and moving on a modern worldwide standard ISA would actually be the real move forward. We have already linux and others tied to gcc extensions and very recent ISO tantrums (porting to not-inline assembly and back to c89/99 is carefully made not reasonable, not to mention assembly code paths tied to specific stack alignment features from the compiler). Namely there is a serious imbalance between the compiler complexity and what it is actually bringing on the table.

View on HN

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.

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.

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.

This is severely wrong: you cannot compare hand written and properly commented assembly with compiler generated one.

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.

"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...

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.

This is what I just said. Then we agree on that matter.

> 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.

This is not complete: I clearly stated in some scenarios we would still install specific code paths at runtime.

Nice try, but we do agree here ;)

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.

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).

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.

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.

> "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.

Again, this is wrong, actually a lie in regards of what I have been saying on this thrtead. I have been giving my opinion and explaining all along in all parts of this threads my views and opinions.

This is so bluntly disregading everything, I think you may very probably be a AI bot with a very small context window.

I'm not a bot. Can you clarify your answer for me, please?

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.

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.

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

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.

> 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.

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.

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.

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.

What makes RISC-V special here? You speak as if RISC-V has some fundamental differences that invalidates old limitations that keep us trapped. Why is this the case? I'm very curious, and don't understand.

Also, why does preprocessing matter so much?

RISC-V is a real free, worldwide standard for a modern and good enough ISA, and that changes everything, namely "moving forward" is not going to be the same than in a legacy context with those locked, non free ISAs.

Preprocessing does matter because it would be pointless to get rid of the compiler complexity to get instead preprocessing complexity.

For instance x86_64 assembler fasmg has the most powerful preprocessor out there.... because the assembler is actually written using this preprocessor language! So it is very easy to "slip" and to end up using excessively this prepropressor to actually write assembly code which is not an assembler!

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?

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...

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"?

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.

Nobody said anything about RISC-V being "perfect" or not. The problem isn't how good RISC-V is or isn't; it's that your desire for software to target one and only one type of hardware just doesn't make any sense. That's not how computers have ever worked.

By the way, what do you mean by "PI lockfree"? Googling "ISA PI lockfree" just leads me to...another hacker news thread where you're arguing that RISC-V should replace everything.

Anyway, yes, please do "investigate how much out-of-the-box-thinking and disruptive this is" before continuing to have these inane arguments.

If you keep explicitely ignoring the core reason why RISC-V is redefining the way to "move forward", I don't know what you want me to tell you.

...okay, so what is "PI lockfree"?

What do you mean? most complicated parts of the gpu driver are in userland and handled by Mesa or equivalent. Kernel drivers expose a standard interface(DRM) which userspace drivers use to upload compiled gpu programs and manage gpu memory. Also, linux is not tied to gcc extensions, it can be compiled with llvm(clang) for a long time now.

What you said is mostly wrong.

The kernel part of the GPU driver is massive. It is well known, maybe you were misguided: for instance the AMD GPU drivers are gigantic compared to the actual kernel.

clang(llvm) is playing cat and mouse with gcc extensions and recent ISO C tantrums which creeps into the kernel:Linus T. does not resist those, he does resist only the linux useland ABI(syscalls) breakers.

It's also well known the driver is massive because there are hundreds of thousands of lines of auto-generated register access code in there. Not because it's inherently very complex.

And again you are wrong. It was debunked not a long time ago, and I think it was here on HN. The AMD drivers, kernel side, are still gigantic even excluding the generated register descriptions. Is this what we call a AI lie?

But where you may be right: it seems nvidia hardware programming interface is much cleaner than AMD one and may require much much less code.

>We must have a GPU hardware programming "standard" first. Isn't that what WebGPU has become?

The WebGPU API is very far removed from the hardware. It's the common subset of Vulkan, D3D12 and Metal, each of those APIs also being fairly high level abstractions over different GPU architectures.

I don't know about webGPU, but it seems you missed the word "hardware" in "hardware programming interface", like NVMe is for non volatile memory device.

I was replying to the "Isn't that what WebGPU has become?".

The WebGPU programming model is already too high level for a "hardware programming interface". WebGPU is designed to sit on top of other 3D APIs, which in turn sit on GPU vendor drivers, and most of the complexity and 'hidden magic' is in those drivers.

oops! wrong reply button, my bad.

Reply on news.ycombinator.com