4 ms·

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 exten

by 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.
  - sylware 3y ago
    [flagged]
  - Iwan-Zotow 3y ago
    No ai will be able to solve np-hard problems
    - GeorgeTirebiter 3y ago
      It's not an issue of 'solving' arbitrarily large np-complete problems; it's solving the required problems (e.g. register usage across multiple function calls) better than today's compilers. And, AI will for sure do that.

by dezgeg 3y ago

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.
- sylware 3y ago
  [flagged]
- Iwan-Zotow 3y ago
  No ai will be able to solve np-hard problems
  - GeorgeTirebiter 3y ago
    It's not an issue of 'solving' arbitrarily large np-complete problems; it's solving the required problems (e.g. register usage across multiple function calls) better than today's compilers. And, AI will for sure do that.