Comment by sylware | Hacker News Reader

Comment by sylware | Hacker News Reader

Parent Full thread

Well, this is much more true that with classic computer languages. That's more than enough when you look at the desastrous stability of classic computer languages. Not even reasonable with C, and I have strong suspicions about rust syntax (it seems it became not much less complex and insane than c++, wrong?). Most other real life computer language syntaxes are hopeless if you are honest with yourself, that on even less than 10 years cycles (blame ISO and compiler extensions).

If one cannot write reasonably a naive but real-life alternative compiler for a computer language syntax, which would be REALLY stable in time -> full frontal compiler planned obsolescence and feature creep.

That's why risc-v has a very high potential: roughly speaking, you exit the compilers, which is a very good thing.

That's why I wish RISC-V to succeed, we all know once some code paths are assembly written, we get a very strong independence of those absurdely and grotesquely massive and complex compilers, that with a world wide/PI lock free standard ISA: this is priceless.

I see risc-v compiler support as legacy support.

You can even get a nice middleground with high level language program interpreters written directly in 64bits risc-v assembly. Think about a python3 interpreter, a javascript interpreter, lua, etc etc...

I'll admit I have a fever so perhaps that is why, but you're not making much sense to me.

It's not like we haven't had ISAs spanning different core architectures already. Take Intel's NetBurst (Pentium 4) vs Core (Core 2 Duo fex) architectures. Same ISA, quite different optimization targets.

I don't see why RISC-V will be different in this regard.

Of course relying on higher-level languages with JIT compliation is a thing, thats why Julia[1] exists. And with RISC-V you do have those extensions that languages like Julia could take advantage of. But it would have to be implemented in Julias complier and libraries, there's no free lunch.

[1]: https://julialang.org/

> But it would have to be implemented in Julias complier and libraries, there's no free lunch.

Actually, for the most part Julia itself doesn't need to be concerned at all with the ISA or hardware differences. That's mostly LLVM's job. So yes, someone does need to implement it, but many languages would get to benefit from that work, not just Julia.

It may not be a free lunch, but you can pay for one lunch and feed many mouths.

I don't think it has anything to do with your fever- the post looks like autogenerated garbage. Below they were speaking about "planned obsolescence of compilers" which makes no sense as many make efforts to support legacy architectures.

Hey maybe you can get together with the grand unified pure pipeline dataflow functions theory guy and make some kind of HN self-help group.

That was more than a decade ago.

Nowadays you write pipeline generic assembly as a lot happen at runtime in modern micro-archs. If some static "optimizations" go in, it is mostly those who are likely to be "true or benign" enough across most if not all micro-archs, for instance cache line or code fetch window alignment (and even that...), branching reduction, etc.

You can still have pipeline specific optimized assembly code, usually just a matter of installing/branching to the right assembly code path at runtime, hardly more.

We have to realize than with that, the entire insane (the word is fair) cost and planned obsolescence of optimizing compilers are literaly... gone... and just for that, even if some assembly code paths are a bit slower, oh god, this is worth billions!

But there is a pitfall though: if the assembly code is written using an ultra powerfull macro preprocessor, "c++ grade" (you get the picture), this would be a complete loss, at it is just displacing the core of the issue from an optimizing compiler to an omega preprocessor.

Reply on news.ycombinator.com