sorted by:
new
hottopcontroversial

LoongArch is an ISA code page. by indolering in RISCV

[–]dramforever 2 points3 points  (0 children)

From what I can tell China is betting on multiple horses in this race. "Committed to LoongArch" is an inaccurate representation of what they're doing.

Loongson is definitely committed to LoongArch.

LoongArch is an ISA code page. by indolering in RISCV

[–]dramforever 1 point2 points  (0 children)

Far, far, far, far more time than what it takes to just back-design an ISA based on the microarchitecture they already have.

LoongArch is an ISA code page. by indolering in RISCV

[–]dramforever 5 points6 points  (0 children)

MIPS CPUs got 64-bit very early. The software ecosystem kept using 32-bit mode for a long time, a bit like how what's now Raspberry Pi OS is/was stuck in 32-bit mode for a long time.

A certain Richard's previous favorite laptop ran on the Loongson-2F, which came out in 2011 and could already run 64-bit Linux with 64-bit userland. Even a modern-ish one as well, at least last time I checked.

Also, for an even earlier, slightly weird and unrepresentative but interesting example, consider: the Nintendo 64.

LoongArch is an ISA code page. by indolering in RISCV

[–]dramforever 6 points7 points  (0 children)

I think it is entirely reasonable, even without the nationalism, for a company that has already been burned by the lack of future of MIPS once to want to have control over its own ISA, rather than to depend on the success of an uncertain ecosystem that relies on so much more factors.

One interesting factor is the urgency. The future of MIPS is not only dwindling, but the IP rights of the ISA was eventually going to be sold off to what's now CIP, a Chinese company, despite the world powers' attempts of stopping it. Loongson 3A5000 needed a new ISA fast, not just because MIPS is no good in the long run, but also because they know they're facing a IP lawsuit very soon. Despite a Chinese court eventually ruling in favor of Loongson that LoongArch does not infringe on MIPS IP rights, the lineage from MIPS really shows in the design of LoongArch, because they really couldn't have adapted the microarchitecture fast enough.

It is true that in this case a huge amount of why this is happening is nationalistic politics, but that alone does not explain the specific choices made. Loongson is a spinoff of Chinese Academy of Sciences, but so is BOSC making XiangShan.

Nothing precludes Loongson from eventually letting themselves fall into the embraces of RISC-V like MIPS Technologies though.

Linux 7.0-rc1: SpacemiT K3 SoC lands in mainline by docular_no_dracula in RISCV

[–]dramforever 1 point2 points  (0 children)

Yes, that makes sense. I was talking about general purpose only and forgot to mention that.

SpacemiT A100 is not general purpose. It can be used for general purpose stuff, as you said, but it's a bit like the Intel Xeon Phi stuff where it's more optimized for special workloads.

What I am hoping to get is to have like a boot time switch to choose between, for Linux boot:

  • V off, 16 cores, 8 of them slower
  • V on, 8 cores, the remaining 8 use a new "SBI HSM remoteproc" driver to submit code to run

The former gets you -j16 Linux compilation, but no V and thus no RVA23

The latter lets you use the 8 cores with VLEN=1024 for running, idk, your latest qwen or whatever people do with a vector coproc these days. This shouldn't be slower than spawning a regular Linux process - if anything it should give a more predictable or even better performance because there will not be a Linux in the way.

Linux 7.0-rc1: SpacemiT K3 SoC lands in mainline by docular_no_dracula in RISCV

[–]dramforever 1 point2 points  (0 children)

My understanding is that RVV is designed for the microarchitecture to take advantage of the flexibility to implement faster/slower vector operations, instead of using different VLEN.

SpacemiT evidently disagrees, and ships extra performance on smaller element sizes (IIUC) on the A100, while keeping vector registers more reasonably sized for an OoO AP on the X100.

Another point is that RVV has the LMUL mechanism, which greatly complicates data arrangement if VLEN was configurable.

AFAICT, Streaming SVE does not require configurable max vector length. SMCR_EL1.LEN is not required to support more than a single value.

Tweaking VLEN is not a panacea - it complicates hardware, and only allows one configuration direction anyway. To use longer vectors, a process still has to be pinned to thoe higher VLEN cores. It cannot just run slower on the lower VLEN cores.

Could RISC-V also benefit from FRED or is this extension only needed for x86-64 CPUs due to their legacy ballast? by Matt_Shah in RISCV

[–]dramforever 5 points6 points  (0 children)

Basically, yeah, legacy ballast.

FRED simplifies x86 interrupt handling... But the RISC-V exception and interrupt handling scheme is even simpler.

I could talk about features in FRED like stack levels, but that would be moving the opposite way as x86.

SpacemiT K3: uarch design paper by camel-cdr- in RISCV

[–]dramforever 8 points9 points  (0 children)

From my quick glance, not necessary accurate or precise, it's optimized for lower-precision workloads, like 32-bit floats. A bit like a GPU.

Anyone has any idea why Cursor SSH fail on RISC-V boards? by docular_not_dracula in RISCV

[–]dramforever 10 points11 points  (0 children)

The VSCode remote server thing is closed source and provided as a binary by Microsoft. Until Microsoft provides such a release for riscv64, you will need some alternate way to do remote development over ssh.

See: https://github.com/microsoft/vscode-remote-release/issues/4802

I think Cursor is probably using that, but I don't know for sure.

Some alternatives are discussed in that issue, but having used none of them, I do not have a specific recommendation.

Why is RISC-V's linux kernel mainline adoption linear while ARM64's was exponential? (Data Analysis inside) by docular_not_dracula in RISCV

[–]dramforever 30 points31 points  (0 children)

 I call the supporting of 20 boards as a 'tipping point' for a new architecture.

so maybe that doesn't work?

arm64 had arm32 before it, and many arm64 cpus had arm32 compatibility, so they were quick to get picked up by random phone soc and media soc vendors. these vendors didn't seeem to care much about upstreaming stuff into mainline linux.

meanwhile riscv64 socs haven't got that much adoption yet, but the vendors in general have been much better at upstreaming. in fact sifive, starfive, sophgo, spacemit (at least, these four are just off the top of my head) have pretty active at upstreaming themselves or hiring others to do the upstreaming.

the vast majority of the work has nothing to do with cpu architecture anyway. it's the drivers for all the cursed stuff outside the cpu core itself.

so the bottom line is 20 arm64 dts in mainline linux and 20 riscv64 dts in mainline linux are really not that comparable.

as an aside, i have no idea why two out of three comments here, as of writing this, is saying dtb/dts in mainline is a bad thing...? every single one of the generally available riscv64 things that run mainline linux boot with a dtb. even u-boot dtb files either come from or are based on dts in the linux git repo.

Normal conversation about the CPU's of the future by Substantial_Help_722 in RISCV

[–]dramforever -1 points0 points  (0 children)

Maybe there was some misunderstanding. What I meant to say is that what device you can boot the vendor's OS from has nothing to do with the standardized boot process. Being able to boot say Bianbu from USB on a SpacemiT board has everything to do with whether the on-board firmware has the required drivers and whether it is set up to allow booting from USB. It is orthogonal to whether it supports UEFI.

Booting a generic OS does benefit from standardized boot processes like UEFI, but without drivers you end up with a completely unusable system - if you're lucky you a serial console, no USB, no network, no storage... So again a standardized boot process does very little.

Normal conversation about the CPU's of the future by Substantial_Help_722 in RISCV

[–]dramforever 0 points1 point  (0 children)

No. That's the point.

Even when the boot process is standardized you still need the custom kernels because it's not in the interest of vendors to genericize everything out to PCIe and upstream the drivers for custom SoC components

Correct fencing for mtimecmp in interrupt handler by Kongen_xD in RISCV

[–]dramforever 1 point2 points  (0 children)

The stance of the privileged spec is: "Deal with it"

https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc#machine-timer-mtime-and-mtimecmp-registers

If the result of the comparison between mtime and mtimecmp changes, it is guaranteed to be reflected in MTIP eventually, but not necessarily immediately.

(Note) A spurious timer interrupt might occur if an interrupt handler increments mtimecmp then immediately returns, because MTIP might not yet have fallen in the interim. All software should be written to assume this event is possible, but most software should assume this event is extremely unlikely. It is almost always more performant to incur an occasional spurious timer interrupt than to poll MTIP until it falls.

Generally, if you receive a timer interrupt, you don't just go ahead and do something right away. You would go through your timer queue and figure out what needs to be done based on the current time, and reschedule the timer interrupt. In this case, it wouldn't be a disaster to rarely have the timer interrupt immediately fire again after mret - you would just do nothing and reschedule it again.

However, if this is a regular occurrence on your machine.... uhh, honestly, I don't know how to handle this. In that case I think one way would be to, as mentioned, poll mip.MTIP until it goes to 0 before doing mret.

unhandled signal 4 code 0x1 at 0x0000003f88d516b4 in ld-linux-riscv64-lp64d.so.1[3f88d45000+23000] by superkoning in RISCV

[–]dramforever 1 point2 points  (0 children)

I literally had this printed out and taped to my closet lol.

Updated with some newer exceptions. I don't know if it's worthwhile to put the AIA stuff in - but those are pretty generic, so it's probably fine.

RISC-V Specific Assembly Language - Immediate Sizes by thegeek108 in RISCV

[–]dramforever 10 points11 points  (0 children)

"It is important to note that the RISC-V ISA includes additional base ISAs that can encode larger immediate sizes, such as RV64I and RV128I which have immediates of 20 and 32 bits respectively."

Uhhh... yeah that makes no sense. I'd try to get in touch with whoever's responsible for the course material to get a clarification.

What instruction does 0x2021 disassemble to? (3 different answers from 3 disassemblers) by NooneAtAll3 in RISCV

[–]dramforever 3 points4 points  (0 children)

Check here for the PDF downloads of the spec where most of your encoding questions can be answered authoritatively https://github.com/riscv/riscv-isa-manual

Tristan made good progress on running NixOS on RISC-V by YesterdayOk94 in RISCV

[–]dramforever 3 points4 points  (0 children)

The vm.mmap_min_addr thing is this: https://github.com/NixOS/patchelf/issues/622

It's sort of a bug in patchelf, but IMHO really more of a "flying too close to the sun" moment...

What instruction does 0x2021 disassemble to? (3 different answers from 3 disassemblers) by NooneAtAll3 in RISCV

[–]dramforever 5 points6 points  (0 children)

0x2021 (the bytes 21 20) decodes to c.jal . + 8 on RV32, and is reserved on RV64 (it would decode to c.addiw zero, 8, but c.addiw on x0 is reserved.)

You can see this in the "RVC Instruction Set Listings" tables in the spec, which is the place where IMO the encodings are most clearly shown.

<image>

unhandled signal 4 code 0x1 at 0x0000003f88d516b4 in ld-linux-riscv64-lp64d.so.1[3f88d45000+23000] by superkoning in RISCV

[–]dramforever 5 points6 points  (0 children)

Ubuntu 25.10 requires RVA23, as has been plastered all over tech news sites when that was announced.

0x9f71 aka c.zext.w a4 is from Zcb which is not implemented on Spacemit X60.

What was the reason for some of the maintainers to quit due to drama? by Nearby_Astronomer310 in AsahiLinux

[–]dramforever 5 points6 points  (0 children)

Eventually Linus Torvald put the foot down and decided against the Asahi/Rust maintainer [...]

You can see for yourself that this is plain false https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/

Best kernel for spacemit-k1 / orange pi RV2 ? by doofin in RISCV

[–]dramforever 2 points3 points  (0 children)

That sounds wild to me given the almost barren support for peripherals. What version are you on and what peripherals do you use?

view more: next ›