3 ms·
It means that in the end, maintaining duplicated assembly code paths for different ISAs would have been cheaper and much easier than the absurdely complex linux
by sylware 4y ago
It means that in the end, maintaining duplicated assembly code paths for different ISAs would have been cheaper and much easier than the absurdely complex linux+gcc(or clang) duo. And I could bet than some code paths could be kept in simple and plain C (compiling with _not_ only gcc/clang) without that much loss of performance.
All that is a very strong case for RISC-V.
- yjftsjthsd-h 4y agoErm. So that's a language/compiler issue, nothing to do with the ISA? And I might be on board with embedding assembly, but AFAIK that also requires compiler extensions. And I'm not an expert on compilers or C, but I suspect that still doesn't cover all the uses of compiler extensions.
- pjmlp 4y agoNo need of compiler extensions for external Assembly modules, just as it used to be quite common a couple of decades ago.
- sylware 4y agoThe issue is the compiler/language. Since RISC-V should be an international standard for assembly level interoperability, that removes in a reasonable way this "compiler/language" issue ... until no technically very expensive code generators/code preprocessors are used since those would not be that less worse than an optimizing compiler. Write RISC-V assembly once, run anywhere. The cherry on top, RISC-V ISAs do not have toxic IP tied to them, like x86_64 or ARM, and that at a worldwide level. I would be ready to pay the price of losing some speed on C code paths until I can compile them with "toy"/small/alternative compilers which are not gcc/clang, BUT I cannot even do that since linux code is hard dependent on gcc extensions.