Is it hard for managed languages to support RISC-V for some architectural reason?

RISC-V is basically a MIPs ripoff with healthy architectural inspiration from ARM. There is a linux distro for RISC-V, and there's no reason Python or nodejs etc. can't run on it. https://riscv.org/2015/01/a-linux-distribution-for-risc-v/

There is a perfectly good reason that NodeJS does not run on RISC-V Linux, which is that NodeJS has not been ported to RISC-V. Projects like Node (or rather the underlying V8 engine) have nontrivial amounts of architecture-specific code.

I can attest to that, though it looks as though the work involved in each part is decreasing.

That's a plus, at least the platform won't get infected by node.js virus

JS is inevitable, it just has a flattened curve.

MIPS is the original RISC one. RISC V is the fifth iteration of the line.

No, Stanford MIPS is a separate lineage from Berkeley RISC.

  RISC
  RISC II
  SOAR
  SPUR
  RISC-V

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-...

As for the original OG RISC, I think that'd be the Cray 1.

As always, the obsession with firsts is a fools errand. The IBM 801 and the CDC 6600 are often mentioned as some of the earliest candidates. As so often with technology, it's a function of the context. In the case of RISC, integrated circuits were reaching capabilities that made it worthwhile reconsidering the conventional wisdom.

The 6600 didn't have general purpose registers. It had operand, address and increment registers. The 801 development began in October 1975. The Cray 1 had been in development for 4 years when it was released in 1975.

So I'll go with the Cray as being to OG RISC. But yes, firsts don't really matter except to say it sure wasn't the Berkeley RISC or the Stanford MIPS.

Never seek after "firsts" too avidly. I've seen people claim the rock is the first computer, and an IBM mainframe running VM/CMS is the first personal computer. (You get your own personal CMS instance running on the massive, institutional big iron, see?)

I guess not, it is just that the whole ecosystem is still on its infancy, and as usual C and C++ get the first class treatment.

Just as well in this instance, since uLisp is a C program.

Yeah, as always in compiler design, bootstraping versus depending on widespread systems programming languages, is an engineering decision.

uLisp could also take advantage of cross compiling, the author just chose another path that allowed him the focus on other areas instead.

What's preventing you from cross-compiling uLisp?

I guess not feeling like rewriting uLisp compiler/runtime in uLisp/Assembly, and not being the author,

Certainly not, and for interpreters it's a trivial port. JITs require more work. I imagine the biggest challenge for uLisp wasn't RISC-V per se, but the very limited amount of data memory on this particular chip (16 KiB IIRC).

Nope

I think Go is there also, the riscv-go repo proclaims itself obsolete with "This port has been upstreamed in Go 1.14.".

Also probably most interpreted languages work out of the box (Ruby, Python etc)

I see, thanks for the heads up.

Interpreter languages is easier, given the existence of C and C++ compilers.