PicoRV32 and FemtoRV32 are both excellent, conventional RISC-V implementations, and are more complete and proven than Minimax. Relative to the size of any 7-series or newer Xilinx FPGA, the difference in LUT cost between any of the three is pretty minor. I think you made a perfectly defensible decision. (I love me some SERV, too, and if you are willing to spend orthodoxy to save gates, it's an excellent choice too.)
Yes, PicoRV32 is very nice. However for what I was building, with limited RAM, compressed instructions would have made a lot of sense. I started porting a BASIC to my system (in C), and it quite easily would have filled almost the whole 512kB SRAM.
And the thought of handwriting one in RISC-V assembly convinced me that maybe RISC-V wasn't as "retro friendly" as I would have liked.
Understood. Maybe this landed after your project - but both PicoRV32 and SERV now support compressed extensions, at some additional resource cost. FemtoRV32 Quark doesn't - which is not a knock, since it's a beautifully simple implementation and that's the point.
The retrocomputing scene looks like a ton of fun and I'd be delighted if any of my work is used there.
Ah, yes, this was 2018/19, in the Before Times, and I don't recall if PicoRV32 had compressed yet but I don't think it did.
SERV always looked intriguing, too. Though I recall maybe its build process was a hassle.
Anyways, this is neat, keep on keeping on! I'm just a software guy, so I remain amazed by the world at the gate level and what it can do. Entirely different kind of abstraction building.
What is it about RISC-V assembly you didn't like? The little I've done seems like slightly more hassle than amd64 assembly but nothing like the level of bending over backwards of 6502 assembly.
RISC ISAs are about an assembly language that is for compilers to write, not humans. That's not to say you can't, but the dance in and out of the registers is tedious.
And RISC-V is more explicitly pure-RISC than ARM, and honestly I think ARM is "friendlier" to write with its conditional instructions and other conveniences. Also for some reason I find the ARM mnemonics easier to read. Maybe it's the 6502 influence, I dunno. FWIW I have never learned x86 assembly; when I went from 68000 to x86, I just started writing C instead.
I'm not saying any of this makes ARM superior. I think RISC-V's choices make more sense for a compiler target. It's not meant to be written by humans. But on a "retro" machine, assembly is kind of part of the deal.
Maybe a fancy macro assembler for RISC-V would be nice, to give a slightly higher level CISC-style set of semantics, but without going the whole hog to a high level language.
No other assembly is as nice to program as 68000 assembly!.
It sounds like your main frustration is saving and restoring registers on entry and exit to subroutines? I agree that that's a particular pain point in RISC-V. Have you considered using millicode for that? Even without assembly macros it's not that bad.
The article you cited, aside from being soft-paywalled, is clueless. The author says, "Actually in theory an x86 instruction could be of infinite length, but dealing with infinitely long instructions is impractical. Thus both Intel and AMD set a practical limit and refuse to process instructions which are encoded as longer than 15 bytes." This indicates they don't understand the x86 instruction encoding at all, and the article is full of careless errors: RISC-V MV and LI are canonically ADDI and not ANDI, not all RISC architectures have a zero register, 3-operand instructions don't reduce memory traffic, most RISC instruction sets don't have an instruction with a 16-bit address field (certainly RISC-V doesn't), there is no "rsp" register in the 16-bit 8086, a pipeline flush doesn't flush the cache (!), and on and on.
Try to forget everything you read in that article! Instead, read something by somebody who cares whether what they're writing is true or false.
