> If that's all you're using it for, isn't qemu good enough? You can never quite be sure qemu correctly represents real hardware. There have been a number of c

> If that's all you're using it for, isn't qemu good enough? You can never quite be sure qemu correctly represents real hardware. There have been a number of cases where qemu was more permissive and programs developed on it didn't work on real hardware. The emphasis is on running valid code, not catching invalid code. Qemu-user on recent PCs is a bit faster than this board for long-running scalar programs with a small amount of code e.g. my primes benchmark: 5.052 sec i9-13900HX, qemu-riscv64 @ 5.1 GHz 10.430 sec Sipeed LM4A TH1520 4x C910 @1.848 GHz https://hoult.org/primes.txt https://hoult.org/primes.txt However, this changes if you run a lot of short programs in quick succession (as e.g. autoconf does) as you get dominated by JIT time. Or if you run full-system emulation using qemu-system, which gets hit by MMU emulation on every load/store. Also, this CPU core implements draft 0.7.1 of the RISC-V Vector spec with 256 bit ALU. Qemu emulates such SIMD code element by element, which is far slower than real hardware. NB there are significant differences between draft 0.7.1 and the final Vector 1.0, but the style is the same, most code doesn't hit the differences, and some code (e.g. memcpy/move/cmp, strcpy/cmp/len) is even binary compatible. Moreover, if you write code using the C intrinsics for the vector instructions then the newly-released GCC 14 can generate code for either 0.7.1 (as "XTHeadVector") or 1.0 from exactly the same source code with just a compiler flags change. > Osborne effect I was at university at the time. Osborne computers cost as much as a new car. RISC-V SBCs in this class cost as much as a dinner date. That makes a HUGE difference to people's willingness to buy something to throw away after a year. All the more so as the engineer using it is probably on a salary sufficient to earn enough to pay for one before morning tea.