SERV: 32-bit is the New 8-bit [video] | Hacker News Reader

SERV: 32-bit is the New 8-bit [video]

youtube.com

49 pointsJoachimS28 comments

Z80 was a bit... err 4 bit a like this. Used in for example Sinclair Spectrum, MSX, CP/M, Gameboy (although modified), TI-8x calculators, etc. had an ALU that computed 8 bit operations in two 4 bit slices.

Edit: and now that I think about it, Motorola 68000 was also like this. Internally 16-bit ALU, but operated on 32 bit registers. 32-bit operations were done in two phases, just like on Z80.

More recently doesn't the AMD AVX 512 implementation do this too? [1] There is very little truly new!

[1] https://www.phoronix.com/review/amd-zen4-avx512

The IBM 360/30 (lowest end of the 360 mainframe line other than the not-quite-compatible 360/20) used an 8-bit ALU to implement a 32-bit ISA in microcode.

So he's talking about making 2 and 4 bit versions of this. I take it that means making it not-quite bit serial, but making it take 2 or 4 bits at a time? It would still have a 32-bit RISC V instruction set, right?

Correct; a 2 bit version would double the width of the ALU and all data paths. And preserve the instruction set.

bit-serial cpus were common in the 01950s and still sold up to the 01970s; the lgp-30, the pdp-8/s, and the rca 1802 were three historically significant examples. the bit-serial approach cuts your hardware complexity by about half while cutting your performance by, typically, about a factor of 20. for a couple of decades, computers that weren't bit-serial were described as 'parallel' even if they only ran one instruction at a time (you can find this in early intel literature)

probably 32 bits is wider than optimal for this kind of thing but not having to write your own c compiler and assembler toolchain is worth a lot, especially if, as in serv, your cpu doesn't try to trap on illegal instructions

even if you're writing asm, risc-v asm requires a lot less bending over backwards than, say, 8051 or 6502 or pic or even avr, and you don't have to worry about overflow much. it's not quite as pseudocody as i386 assembly tho

there are an awful lot of control tasks where one frame of doom every four seconds is much more performance than you actually need, like kindgren's examples in this talk: ddr memory initialization, logging, slow sensor data aggregation, and control planes; i'd add pid control, motor control waveform generation, and guitar pedals and other audio dsp applications (maybe using the serv core to orchestrate the activities of a larger dsp core, similar to how the s1 mp3 used a z80)

wrt the question about educational applications, femtorv32 is probably an easier implementation of risc-v to understand; it's a lot less verilog and a lot more straightforward

— ⁂ —

for videos like this that are mostly slides and somebody talking, if you're interested in the verbal information and not the pretty face, i recommend

    yt-dlp --write-auto-sub --sub-lang en,es -f '[height<800]' https://www.youtube.com/watch?v=GSHasXHvZaQ

(or possibly even just downloading the .vtt files without the video at all; it is unfortunate that youtube doesn't have an 0.5 fps 640×480 option for things like this)

and then

    devtt.py < SERV：\ 32-bit\ is\ the\ New\ 8-bit\ -\ Olof\ Kindgren\,\ Qamcom\ \[GSHasXHvZaQ\].en.vtt |
        less

where devtt.py is http://canonical.org/~kragen/sw/dev3/devtt.py or equivalent (i can't have been the first person to want this, and probably someone has written a better version)

the transcript is only 2130 words and so reading it only takes about 6 minutes, while the video is 21 minutes

the transcript has a lot of errors but is adequate

> there are an awful lot of control tasks where one frame of doom every four seconds is much more performance than you actually need, like kindgren's examples in this talk: ddr memory initialization, logging, slow sensor data aggregation, and control planes; i'd add pid control, motor control waveform generation, and guitar pedals and other audio dsp applications (maybe using the serv core to orchestrate the activities of a larger dsp core, similar to how the s1 mp3 used a z80)

You can get proper 32 bit core for less than $1 these days, I can't see it competing. It has a niche, saving gates on FPGA, but that's about it

It being awfully slow also means it will be awful on power usage.

> It being awfully slow also means it will be awful on power usage.

On the contrary; for every RISCV32 instruction you'd expect the same energy requirement as in a bit parallel implementation. If you take 32x longer by processing 1 bit at a time, your power (energy per time unit) could be as much as 32x lower.

you probably know more, but my ignorant guess is that you need about half as many gates, but about 20× as many cycles (because things that would stall for an entire instruction time in a bit-parallel implementation only stall for a single cycle), it might consume about 10× as much energy?

but generally the kinds of places you'd want to use something like this, the cpu won't be even 1% of the power draw

You can get 32 bit MCUs for much less (~20ct). But many sensors, USB Hubs, specialized chips have some kind of small processor inside (which is often an 8051 right now) where this could be a good replacement, being low-gate-count, having good tools and a very low licensing cost (0$).

i agree that it doesn't make sense to fabricate serv as a discrete chip, but i think of fabricating cpus as discrete chips as being the small niche, not embedding cpus inside fpgas or asics

Not only that, but you could replace a lot of fixed logic in that FPGA with s very small programmable thing. "Fast" only matters if it is on the critical path.

> You can get proper 32 bit core for less than $1 these days, I can't see it competing. It has a niche, saving gates on FPGA, but that's about it

Competing for what? Having a super small subcent CPU is an interesting niche (in ASICs). Having a well documented, really small CPU for FPGAs and a ecosystem is great for hobbyist and academia who need to string something together without tripping themselves. Even it serves as an educational example of a RISC-V CPU SERV is competing pretty well.

Off-topic, but this is a brilliant comment, and exactly the type of stuff I come to HN for.

Historical insight, and a tip on how to get transcriptions with yt-dlp. I didn't even know it could do that!

Thanks for sharing this.

thanks, i'm feeling pretty unappreciated here, and comments like yours help a lot

fuck the haters, man

Just to add my thanks too! Especially the point about control tasks - brought a new perspective for me.

You are very much appreciated, for your well-informed comments on this topic and many others on HN. Most HN readers don't reply to comments they appreciate, only the ones they disagree with. And many don't understand about upvoting, or don't bother.

You are one of the commenters here who I am on the lookout for. You always have something insightful to say.

aw, thanks to all four of you

How fast is it?

Fast enough to run doom at 1/4 fps, according to the video.

Academics, doing useless stuff just to publish. This takes more space than 6502 or Z80 while also being slower.

µC performance doesn't always matter. Sometimes you need something that takes very little FPGA or ASIC space. This leaves more space for the actually important stuff. When performance does matter, you just use something speedier.

More choice is good.

This is bigger than 8bit cores.

SERV seems to be very comparable to a 6502 in size in terms of ASIC gates required.

On an FPGA, SERV's implementation seems to be a times smaller.

if you ignore register file

True, unless you use a reduced one.

Olof Kindgren is not in academia. He is an embedded consultant working for Qamcom, a consultancy in Sweden, USA etc.

https://www.qamcom.com

And as he points out in the presentation, SERV is used in several (and growing) real world systems as a flexible control plane in ASICs, FPGAs etc.

Reply on news.ycombinator.com