5 ms·

The article missed out on context. The chip runs LoongSon's own "LoongArch" ISA which they had developed out of MIPS'. Chips and Cheeses test programs are writt

The article missed out on context. The chip runs LoongSon's own "LoongArch" ISA which they had developed out of MIPS'. Chips and Cheeses test programs are written in that ISA. There are other articles on the site that tell more about it. LoongSon does however supposedly have a instruction set extension for running binary-translated x86 code faster (and ARM and RISC-V), but they have not published much about it.

sylware 3y ago
Since RISC-V has also its roots in mips, maybe loongson should move to RISC-V for good with a x86/arm hardware translater. All that to run binary distributed x86 apps...
- Findecanor 3y ago
  Today I agree that it would make much sense for LoongSon to jump on the RISC-V bandwagon. However, designing a CPU takes years. Back when they transitioned from MIPS to LoongArch, RISC-V wasn't mature enough to have all the functionality that their MIPS cores did. There was no ratified Bitmanip extension and it was unclear what kind of vector extension that it would get.
- luyu_wu 3y ago
  Unfortunately, RISCV is really a mess right now, the Vector extensions are horrible. Amusingly, LoongArch has better Linux support than RISCV right now too... Would've definetly been nice to see them adopt RISCV though. ISAs are fragmented enough as is.
  - camel-cdr 3y ago
    > the Vector extensions are horrible How so?
    - luyu_wu 3y ago
      They're horribly fragmented (there's many ISA extensions that accomplish the same thing from different companies), and thus a headache to deal with for any compiler (which is why the compiler support sucks).
      - camel-cdr 3y ago
        There is one standard vector extension, and one company that released two chips with a non standard pre ratification version of the extension. It was released almost two years before the first rvv 1.0 hardware became available at the end of last year. Without out it, we wouldn't have had any hardware at all. rvv 1.0 has quite good upstream compiler support already, and before that the t-head had custom compilers that supported their rvv 0.7.1 version of the vector extension. Now upstream gcc supports it as an alternative codegen target as well, so you can write rvv 1.0 vector instrinsics and compile those to the thead rvv 0.7.1 implementation. I'm not aware of any company that plans to release a non rvv 1.0 rvv implementation.
        sylware 3y ago
        Each time somebody is spitting on risc-v vector extension, it is the same false argument of fragmentation, and each time somebody fixes it with the real truth (pre-ratification of some vendors). Arm/x86 fan boys?
        janwas 3y ago
        "Real truth" and "fan boys"? Let's have some facts: there are indeed a boatload of extensions, though perhaps not (yet) to the V extension itself. T-HEAD [1], Ventana's ternary op [2], Sifive also has a couple [3], including "Xsfvfwmaccqqq", one of at least four completely different matmul variants. In particular for the latter, I would say fragmentation is an absolutely valid concern at the moment. [1]: https://github.com/T-head-Semi/thead-extension-spec https://github.com/T-head-Semi/thead-extension-spec [2]: https://github.com/ventanamicro/ventana-custom-extensions/releases https://github.com/ventanamicro/ventana-custom-extensions/re... [3]: https://www.sifive.com/documentation https://www.sifive.com/documentation

sylware 3y ago

Since RISC-V has also its roots in mips, maybe loongson should move to RISC-V for good with a x86/arm hardware translater. All that to run binary distributed x86 apps...

Findecanor 3y ago
Today I agree that it would make much sense for LoongSon to jump on the RISC-V bandwagon. However, designing a CPU takes years. Back when they transitioned from MIPS to LoongArch, RISC-V wasn't mature enough to have all the functionality that their MIPS cores did. There was no ratified Bitmanip extension and it was unclear what kind of vector extension that it would get.
luyu_wu 3y ago
Unfortunately, RISCV is really a mess right now, the Vector extensions are horrible. Amusingly, LoongArch has better Linux support than RISCV right now too... Would've definetly been nice to see them adopt RISCV though. ISAs are fragmented enough as is.
- camel-cdr 3y ago
  > the Vector extensions are horrible How so?
  - luyu_wu 3y ago
    They're horribly fragmented (there's many ISA extensions that accomplish the same thing from different companies), and thus a headache to deal with for any compiler (which is why the compiler support sucks).
    - camel-cdr 3y ago
      There is one standard vector extension, and one company that released two chips with a non standard pre ratification version of the extension. It was released almost two years before the first rvv 1.0 hardware became available at the end of last year. Without out it, we wouldn't have had any hardware at all. rvv 1.0 has quite good upstream compiler support already, and before that the t-head had custom compilers that supported their rvv 0.7.1 version of the vector extension. Now upstream gcc supports it as an alternative codegen target as well, so you can write rvv 1.0 vector instrinsics and compile those to the thead rvv 0.7.1 implementation. I'm not aware of any company that plans to release a non rvv 1.0 rvv implementation.
      - sylware 3y ago
        Each time somebody is spitting on risc-v vector extension, it is the same false argument of fragmentation, and each time somebody fixes it with the real truth (pre-ratification of some vendors). Arm/x86 fan boys?
        janwas 3y ago
        "Real truth" and "fan boys"? Let's have some facts: there are indeed a boatload of extensions, though perhaps not (yet) to the V extension itself. T-HEAD [1], Ventana's ternary op [2], Sifive also has a couple [3], including "Xsfvfwmaccqqq", one of at least four completely different matmul variants. In particular for the latter, I would say fragmentation is an absolutely valid concern at the moment. [1]: https://github.com/T-head-Semi/thead-extension-spec https://github.com/T-head-Semi/thead-extension-spec [2]: https://github.com/ventanamicro/ventana-custom-extensions/releases https://github.com/ventanamicro/ventana-custom-extensions/re... [3]: https://www.sifive.com/documentation https://www.sifive.com/documentation