> Loongson Corporation has yet to release the remaining volumes of the LoongArch manual
Why? The first thing people will want to do on a new weird computer is run Linux on it. How can the manufacturer possibly benefit from not releasing the manual? Are they still writing/editing it?
> LoongArch is now a fully legitimate, upstreamed ISA—with mainline Linux, Debian, and Rust support—ensuring it will be maintainable and usable at scale, but its momentum is institutional and domestic rather than market-driven: it exists to guarantee China a sovereign, unblockable CPU stack on a short timeline, not to attract global vendors, startups, or cloud ecosystems. In contrast, RISC-V is accumulating multi-vendor, cross-border adoption and economic gravity that define a global ISA; LoongArch’s success criteria are different, narrower, and largely already met.
Loongson started with MIPS CPUs but current CPUs are not MIPS-compatible. LoongArch, while being very similar to MIPS, uses a different encoding. And some other details have changed. Better to say, MIPS-inspired.
What are LoongArch's technical advantages over RISC-V? In other words, why should a company develop their own architecture (which then they need to push support for) rather than use an existing, free one?
Back when LoongArch was announced, RISC-V did not yet have enough (ratified) extensions to achieve feature-parity.
Even if it had, LoongArch is much more similar to MIPS. LoongSon would have had to make more microarchitectural changes before being able to tape out their first non-MIPS CPU.
I don't know about advantages, but lead times in the chip business are long and you're not turning around on a dime without very pressing reasons. Loongson has probably had many things in the pipeline as RISC-V started gaining steam. Their current processors are more advanced designs than the best known RISC-Vs.
I mean isn't this equivalent to "are we MIPS yet?"? I don't know the technicalities, but aren't they suspiciously close aren't they? ...and MIPS has been supported for a loong time already.
"suspiciously close" isn't close enough, unfortunately, though it might make the task less work:
If your uname output, compiler architecture ifdefs, etc, don't match the existing architecture then basically every program that does per architecture specialisation will need updating, even if fairly trivially so.
If you're not building and running identical binaries, then anybody who distributes binaries needs to be persuaded that it's worthwhile to get hold of build machines and devote archive space and maintenance time to your new architecture.
There may be political issues where neither the owners of the old architecture nor the owners of the new clone want to come out and admit that it's very similar. This may result in projects treating it as "genuinely new architecture" rather than "variant of an existing one", which is more work. (There are also technical concerns about future divergence that might argue for "not just a variant".)
If you have to have the code structure of a complete new architecture then this can also trigger more work where the old arch code got to get away with legacy practices and APIs but the newcomer is expected to reach any project standards for new code, so "copy, paste, rename" is insufficient. Sometimes this imposes constraints that make more work elsewhere: for instance a new architecture in Linux is expected to follow a modern syscall numbering scheme and set of syscalls, so it won't have a userspace ABI that's compatible with the arch it is cloning.
If the architecture you're cloning is a "declining" architecture now mostly in legacy setups, then modern projects you care about for your new architecture might not have good or any support for it. (If you cloned sh4 you won't have easy rust support, for example.)
Overall, getting a new architecture from "we have a spec" to comprehensive open source ecosystem support is a heavy lift, and clone and copy doesn't get you out of all of it. (Look back at how long it took 32 bit Arm and then 64 bit Arm and now how riscv is following similar paths. These have all been years long efforts with a very long tail.)
> Loongson Corporation has yet to release the remaining volumes of the LoongArch manual
Why? The first thing people will want to do on a new weird computer is run Linux on it. How can the manufacturer possibly benefit from not releasing the manual? Are they still writing/editing it?
The LoongArch initiative made sense before Risc-V, when RMS was using it, etc. Now it makes more sense to put more wood behind one arrow.
Related:
Debian adds LoongArch as officially supported architecture (113 points, 3 days ago, 29 comments) https://news.ycombinator.com/item?id=46334333
Loongson 3A6000: A Star Among Chinese CPUs (98 points, 2024, 135 comments) https://news.ycombinator.com/item?id=39726124
Can regular people or companies buy a loongson system somewhere without going through shady hoops or is this fanfare essentially self-celebration?
The Orange Pi Nova will use Loongson's 2K3000 SoC and should be available on Amazon. Looking forward to getting one in for review.
> will
So no?
[dead]
NetBSD appears to support Loongson but is not listed on this website: https://wiki.netbsd.org/ports/evbmips/ (Loongson MIPS64 based devices)
It's not. Before LoongArch, Loongson made MIPS64 CPUs. But this is about LoongArch which is similar but incompatible with MIPS64.
https://www.youtube.com/shorts/Ub5x-4KC03s I wish I could just beloong
First time I heard about this, for those like me:
https://en.wikipedia.org/wiki/Loongson
TLDR: it's a MIPS-compatible CPU architecture
> LoongArch is now a fully legitimate, upstreamed ISA—with mainline Linux, Debian, and Rust support—ensuring it will be maintainable and usable at scale, but its momentum is institutional and domestic rather than market-driven: it exists to guarantee China a sovereign, unblockable CPU stack on a short timeline, not to attract global vendors, startups, or cloud ecosystems. In contrast, RISC-V is accumulating multi-vendor, cross-border adoption and economic gravity that define a global ISA; LoongArch’s success criteria are different, narrower, and largely already met.
Loongson started with MIPS CPUs but current CPUs are not MIPS-compatible. LoongArch, while being very similar to MIPS, uses a different encoding. And some other details have changed. Better to say, MIPS-inspired.
What are LoongArch's technical advantages over RISC-V? In other words, why should a company develop their own architecture (which then they need to push support for) rather than use an existing, free one?
Back when LoongArch was announced, RISC-V did not yet have enough (ratified) extensions to achieve feature-parity.
Even if it had, LoongArch is much more similar to MIPS. LoongSon would have had to make more microarchitectural changes before being able to tape out their first non-MIPS CPU.
I don't know about advantages, but lead times in the chip business are long and you're not turning around on a dime without very pressing reasons. Loongson has probably had many things in the pipeline as RISC-V started gaining steam. Their current processors are more advanced designs than the best known RISC-Vs.
Context: https://en.wikipedia.org/wiki/Loongson
I mean isn't this equivalent to "are we MIPS yet?"? I don't know the technicalities, but aren't they suspiciously close aren't they? ...and MIPS has been supported for a loong time already.
"suspiciously close" isn't close enough, unfortunately, though it might make the task less work:
If your uname output, compiler architecture ifdefs, etc, don't match the existing architecture then basically every program that does per architecture specialisation will need updating, even if fairly trivially so.
If you're not building and running identical binaries, then anybody who distributes binaries needs to be persuaded that it's worthwhile to get hold of build machines and devote archive space and maintenance time to your new architecture.
There may be political issues where neither the owners of the old architecture nor the owners of the new clone want to come out and admit that it's very similar. This may result in projects treating it as "genuinely new architecture" rather than "variant of an existing one", which is more work. (There are also technical concerns about future divergence that might argue for "not just a variant".)
If you have to have the code structure of a complete new architecture then this can also trigger more work where the old arch code got to get away with legacy practices and APIs but the newcomer is expected to reach any project standards for new code, so "copy, paste, rename" is insufficient. Sometimes this imposes constraints that make more work elsewhere: for instance a new architecture in Linux is expected to follow a modern syscall numbering scheme and set of syscalls, so it won't have a userspace ABI that's compatible with the arch it is cloning.
If the architecture you're cloning is a "declining" architecture now mostly in legacy setups, then modern projects you care about for your new architecture might not have good or any support for it. (If you cloned sh4 you won't have easy rust support, for example.)
Overall, getting a new architecture from "we have a spec" to comprehensive open source ecosystem support is a heavy lift, and clone and copy doesn't get you out of all of it. (Look back at how long it took 32 bit Arm and then 64 bit Arm and now how riscv is following similar paths. These have all been years long efforts with a very long tail.)