I finally have a RISC-V based single board computer (SBC) – the Nezha from RV Boards shipped to me directly from China.
It’s tiny (about the same form-factor as a Raspberry Pi though) and relatively expensive (it cost me just over £100 to order and get it shipped here) but whilst I was slightly concerned I was being a bit naïve in buying it (as it was either a scam or it wouldn’t work), it boots (slowly) into Linux (see image) and works (slowly).
Can RISC-V cores (which are ‘open source hardware’ and free from licensing fees) break ARM’s grip on SBCs and similar devices? A year ago the answer looked like a very clear negative as, despite years of hype, RISC-V designs just weren’t moving off the page and into silicon. Now it looks much more uncertain as the Nezha is actually the second RISC-V SBC to ship (the other, the Beagle-V, has only been distributed to a select group of developers so far – and this didn’t include me despite my application – but is expected to be available globally in the autumn).
The plans are for RISC-V SBCs retailing for less than $20 inside a year and – crucially – for the RISC-V cores to feature vector extensions which could mean some interesting use-cases being opened up.
(If you want to know more about RISC-V or if you are thinking of starting a RISC-V assembly project I cannot recommend The RISC-V Reader highly enough.)
When I was much younger FORTH fascinated me as an alternative interpreted language for the Z80 eight-bit processor machines I was typically using.
Compared to BASIC – the language that the Sinclair ZX80, ZX81 and Spectrum came with – FORTH was reputedly lightening fast and very powerful.
My brother and I even obtained a tape copy of somebody’s FORTH for the ZX80 and we ran it – and it certainly was fast. But it also lacked the simplicity of BASIC and the tape was soon handed back.
But I’m back on the case again, inspired by this (long out of print but widely available on the web) book – Threaded Interpretive Languages – and by the prospect of a single board RISC-V computer – the BeagleV – coming out this year.
Currently I am targeting the PK proxy kernel on the Spike Risc-V emulator for RISCYFORTH but if and when I get a real BeagleV I’ll immediately switch to that (I applied to be an early user but have heard nothing so while the signs are that the project itself is making good progress it looks like I’ll have to wait to get my hands on one.)
I struggled with getting the mechanics of RISCYFORTH right for a long time but in the last week I’ve finally started to make serious progress and it actually does things (only in immediate mode for now). The picture shows my very first success with a multi-token command line from a couple of evenings ago and it’s come on a fair bit since then.
It’s nowhere near a releasable state but it’s rapidly improving.
Why bother? Well I think it’s important that RISC-V succeeds as a disruptor of what is starting to look like an ARM monopoly and so contributing to the ecosystem of the first single board seriously affordable RISC-V device matters. And, of course, because it’s there.
Always yield to the hands-on imperative (from this classic).
Update: My brother actually thinks we borrowed somebody’s Jupiter Ace which was a Z80-based FORTH computer of a very similar size to a ZX81 – and I think he might be right.
A few years ago I set out to write a clone of Sinclair BASIC as a domain-specific language (DSL) in Groovy. The end result was BINSIC, but it was much closer to an interpreter than a DSL: it turned out that strange ways that Groovy handled capitalised function/closure names meant that I could not match keywords at all and so interpretation became the only option (though there were DSL-like features lurking under the covers).
Now I have set out to write an interpreter for RISCV assembly and have written something which is much more like a DSL. My aim was to track the memory reference patterns of various real-time benchmarks running on RISCV systems – based on the disassembly generated by Spike, the RISCV emulator.
Getting that done requires tracking register state – because in true RISC fashion reads and writes are done not to immediates, but to addresses held in registers with immediates used as offsets.
To make this happen every (or at least every used) RISCV instruction is mapped to a closure and the operands treated as closure parameters. The closures are all inside the RegisterFile class so all can access the registers to keep the state updated. This makes it quite like a DSL but I make no claims for purity: every statement is passed through a regular expression based interpreter to separate out the parameters: if nothing else that eliminates a lot of boilerplate code that would have to be stuck inside the closures.
Memory is treated as a sparse array through a Groovy Map instance – with an address (64-bit Long) mapped to an 8-bit Byte.
The process isn’t perfect – a disassembly doesn’t given you the contents of initialised data, so an attempt to access those addresses is quite likely to raise an exception which needs to be trapped and the memory accounted for – by simply assigning zero to the address: it’s a kludge but it seems to work.