5 ms·

What's very nice about RISC-V 64bits: code assembly once, run it everywhere, almost quite literaly... no absurdely and grotesquely massive and complex compilers

What's very nice about RISC-V 64bits: code assembly once, run it everywhere, almost quite literaly... no absurdely and grotesquely massive and complex compilers anywhere, no planned obsolescence, feature creeps on computer language syntax nowhere to be found, ultra stable in time, near 0 SDK.

magicalhippo 3y ago
That's not really true though is it? A lot of the speed and interesting bits for HPC would come in the form of ISA extensions, and the paper even mentions challenges in this area due to the chip only supporting version 0.7.1 of the RVV vectorisation extension. Regardless, I imagine in HPC you'll want to recompile anyway to get the most bang for your buck, unless you're doing a short run. Why throw away performance if you'll be running your code for days or months?
- sylware 3y ago
  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...
  - formerly_proven 3y ago
    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.
    - sylware 3y ago
      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.
  - magicalhippo 3y ago
    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/ https://julialang.org/
    - eigenspace 3y ago
      > 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.
KingLancelot 3y ago
[dead]
bigbillheck 3y ago
> no absurdely and grotesquely massive and complex compilers anywhere Absence of evidence is not evidence of absence, and anyway there's not even an absence: https://github.com/riscv-collab/riscv-gnu-toolchain https://github.com/riscv-collab/riscv-gnu-toolchain https://llvm.org/docs/RISCVUsage.html https://llvm.org/docs/RISCVUsage.html > feature creeps on computer language syntax nowhere to be found At least one of us is very confused, and in case it's me, how do language details matter to RISC-V?
znpy 3y ago
you might do the same on x86 as long as you code using only the instructions you'd find on a 286 or a 386 (if you feel fancy you can assume you always have the x87 math coprocessor)
dezgeg 3y ago
Yeah, no. I have a bad feeling that fragmentation will become a mess in RISC-V world. Just few month ago Qualcomm threatened to not support the existing C extension and proposed their own 16-bit instruction set. Also another example of such mess from a sibling post by davidlt (https://news.ycombinator.com/item?id=38591977 https://news.ycombinator.com/item?id=38591977): > SG2042 itself is T-HEAD C920 design which is a mess, and might not be even called a RISC-V compliant design. [...] There are other design issues discovered IIRC (atomic might not work properly [at least on the kernel side workarounds required]; floating point failures in glibc testsuite because FP not being compliant) Guess what in the above T-HEAD C920 situation would be to best way to achieve "code once"? Add the workaround for the buggy instructions in the compiler and then recompile, with no changes.
- photonbeam 3y ago
  I think once google picks their minimum riscv extension set for android (soon?) then the rest of the vendors will aim at that leaving everything else as obsolete
- sylware 3y ago
  "Rome was not built in one day": Mistakes, debugging, fixing MUST happen. And it is going to hurt. To get rid of the plague of optimizing compilers, I am willing to pay that price. And instead of having to to fix assembly code generation in those ultra-complex compilers, it is much more reasonable to hook in an assembler which is beyond orders of magnitude saner than dealing with any optimizing compilers.
  - GeorgeTirebiter 3y ago
    Would love it you would expand more. "Mistakes, debugging, fixing" ? 'plague' of optimizing compilers? Who really cares what they do, as long as the code it produces executes the abstract machine that the compiled language provides? If you're saying optimizing compilers are broken, that's different. I fully expect AI to be bolted on to optimizing compilers - especially for global optimization - that is going to be mind-blowing when it works error-free.

magicalhippo 3y ago

That's not really true though is it? A lot of the speed and interesting bits for HPC would come in the form of ISA extensions, and the paper even mentions challenges in this area due to the chip only supporting version 0.7.1 of the RVV vectorisation extension. Regardless, I imagine in HPC you'll want to recompile anyway to get the most bang for your buck, unless you're doing a short run. Why throw away performance if you'll be running your code for days or months?

sylware 3y ago
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...
- formerly_proven 3y ago
  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.
  - sylware 3y ago
    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.
- magicalhippo 3y ago
  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/ https://julialang.org/
  - eigenspace 3y ago
    > 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.

KingLancelot 3y ago

[dead]

bigbillheck 3y ago

> no absurdely and grotesquely massive and complex compilers anywhere Absence of evidence is not evidence of absence, and anyway there's not even an absence: https://github.com/riscv-collab/riscv-gnu-toolchain https://github.com/riscv-collab/riscv-gnu-toolchain https://llvm.org/docs/RISCVUsage.html https://llvm.org/docs/RISCVUsage.html > feature creeps on computer language syntax nowhere to be found At least one of us is very confused, and in case it's me, how do language details matter to RISC-V?

znpy 3y ago

you might do the same on x86 as long as you code using only the instructions you'd find on a 286 or a 386 (if you feel fancy you can assume you always have the x87 math coprocessor)

dezgeg 3y ago

Yeah, no. I have a bad feeling that fragmentation will become a mess in RISC-V world. Just few month ago Qualcomm threatened to not support the existing C extension and proposed their own 16-bit instruction set. Also another example of such mess from a sibling post by davidlt (https://news.ycombinator.com/item?id=38591977 https://news.ycombinator.com/item?id=38591977): > SG2042 itself is T-HEAD C920 design which is a mess, and might not be even called a RISC-V compliant design. [...] There are other design issues discovered IIRC (atomic might not work properly [at least on the kernel side workarounds required]; floating point failures in glibc testsuite because FP not being compliant) Guess what in the above T-HEAD C920 situation would be to best way to achieve "code once"? Add the workaround for the buggy instructions in the compiler and then recompile, with no changes.

photonbeam 3y ago
I think once google picks their minimum riscv extension set for android (soon?) then the rest of the vendors will aim at that leaving everything else as obsolete
sylware 3y ago
"Rome was not built in one day": Mistakes, debugging, fixing MUST happen. And it is going to hurt. To get rid of the plague of optimizing compilers, I am willing to pay that price. And instead of having to to fix assembly code generation in those ultra-complex compilers, it is much more reasonable to hook in an assembler which is beyond orders of magnitude saner than dealing with any optimizing compilers.
- GeorgeTirebiter 3y ago
  Would love it you would expand more. "Mistakes, debugging, fixing" ? 'plague' of optimizing compilers? Who really cares what they do, as long as the code it produces executes the abstract machine that the compiled language provides? If you're saying optimizing compilers are broken, that's different. I fully expect AI to be bolted on to optimizing compilers - especially for global optimization - that is going to be mind-blowing when it works error-free.