Loongson CPU that performs like 2020 Core i3 makes its way to Chinese mini PCs(theregister.com)
theregister.com
Loongson CPU that performs like 2020 Core i3 makes its way to Chinese mini PCs
https://www.theregister.com/2024/04/13/loongson_cpu_mini_pc/
14 comments
Chips and Cheese reviewed it quite favourably, worth a read: https://chipsandcheese.com/2024/03/13/loongson-3a6000-a-star...
Also for anyone who's willing to put up with eng subs/underdtand mandarin, Geekerwan has a very in-depth video (+Linux and real world usage!) on the chip. https://youtu.be/GpUJHHwedCw
I am told that MIPS assembly is more regular or somehow "better" than x86, would be interesting to see if this translates to more assembler code being written for it.
Pretty much any modern architecture could be called 'better' than x86 by now! Loongson has a surprisingly high amount of compiler and toolchain support which is pretty interesting. They also have quite a lot of kernel code upstreamed and in the main branch by now. Windows is unlikely to ever support it for obvious reasons though :P Minor note: Loongson does not use MIPS anymore, they switched to LoongISA, which to my understanding (correct me if I'm wrong) is not very different, but adds instructions for faster binary translation for ARM and x86.
I'd say quite the opposite.
Reasons: - practically every developer who is remotely interested in assembly programming knows the x86 basics and most experts have a better knowledge of x86 than other architectures with the possible exception of ARM
- x86 is very hard for the hardware implementation, for the programmer (especially with the x86-64 improvements) is not bad at all. Its bigger defects are variable instruction length, something that has no impact on coding, and tge amount of legacy stuff that exists mostly for backward compatibility (e.g. x87, enter/leave, bcd instructions, hw task switching, segments, real mode and v86 mode, etc.) and are just being ignored by programmers as stuff that is now irrelevant if they have not been removed from 64bit long mode at all.
- I don't know modern MIPS, but the MIPS architectures of the past were not programming friendly at all, with stuff like delayed slots (basically instructions that are executed even if the code branched somewhere else), heavy reliance on the compiler to provide perfect instruction order, etc
Reasons: - practically every developer who is remotely interested in assembly programming knows the x86 basics and most experts have a better knowledge of x86 than other architectures with the possible exception of ARM
- x86 is very hard for the hardware implementation, for the programmer (especially with the x86-64 improvements) is not bad at all. Its bigger defects are variable instruction length, something that has no impact on coding, and tge amount of legacy stuff that exists mostly for backward compatibility (e.g. x87, enter/leave, bcd instructions, hw task switching, segments, real mode and v86 mode, etc.) and are just being ignored by programmers as stuff that is now irrelevant if they have not been removed from 64bit long mode at all.
- I don't know modern MIPS, but the MIPS architectures of the past were not programming friendly at all, with stuff like delayed slots (basically instructions that are executed even if the code branched somewhere else), heavy reliance on the compiler to provide perfect instruction order, etc
Variable-length instructions cause one bit of inconvenience for assembly programmers.
There are long and short JMP instructions that your assembler can possibly choose between depending on how far away the target is. Now, changing a JMP from short to long can change the length between another JMP and the target. Assemblers have different levels of intelligence for this situation: I programmed a lot of assembly for the 80286 (not protected mode but I used all the instructions that would speed up real mode) in the late 1980s and since we were working with little space a good assembler would try assembling the program multiple times until it got a consistent solution for what kind of JMP to use where.
There are long and short JMP instructions that your assembler can possibly choose between depending on how far away the target is. Now, changing a JMP from short to long can change the length between another JMP and the target. Assemblers have different levels of intelligence for this situation: I programmed a lot of assembly for the 80286 (not protected mode but I used all the instructions that would speed up real mode) in the late 1980s and since we were working with little space a good assembler would try assembling the program multiple times until it got a consistent solution for what kind of JMP to use where.
Loongson CPUs have long abandoned MIPS, they are now using their own (MIPS-derived) ISA without the branch delay slots and then some. I'd wager that it is more like RISC-V than MIPS now, at least on the surface.
Didn't know that, then the last point doesn't really apply
One advantage of a simpler/more regular ISA is that it's easier to maintain the tools (compilers, bits of assembly in low-level libraries / OS kernels etc) which enable you to avoid writing your software in assembly.
Read: easier for software tools to write the assembly code for you.
Read: easier for software tools to write the assembly code for you.
When RISC was getting popular in academia in the 1980s the conventional wisdom was hand-coding assembler was obsolete and it was all about being a compiler target.
Does it have proprietary microcode? If not, RMS can finally upgrade his machine from 2010 era to 2020.
Loongson would do well to adopt RISC-V, rather than opt-out to the fastest growing ecosystem.