3 ms·

I saw this when it was a twitter thread[1] and noted then, some good points and some not so good points. One of the things that comes up with Risc-V a lot is c

I saw this when it was a twitter thread[1] and noted then, some good points and some not so good points. One of the things that comes up with Risc-V a lot is code density, and it is a sore spot for many CPU designers because it is shamelessly abused by marketing departments as a measure of 'goodness'. This has sort of trained these engineers to flinch when something doesn't exhibit good code density, and the author is no exception. However, FLASH/RAM volume has gone up hugely. This is in part because once you run out of logic to lay down in a chip you flood fill the rest with RAM and/or FLASH because hey the chip has to be big enough to hold pad landings for all of its pins. This has taken a lot of pressure off the code density thing and now it seems appropriate to look at algorithmic capacity. I agree with the author that it is a much better use of resources to put a hard multiplier on a chip than it is to have more space in flash so that you can do that with instructions. But from a algorithmic capacity question? It is all Turing complete so really what is the practical difference? Now I started life programming on PDP-11's that had a "native" instruction set that was not unlike RISC-V in being maximally simple. We called it "microcode" :-) And the "real" instructions were actually sequences of microcode in a microcode ROM. That was pretty cool because you could swap out floating point instructions for vector instructions or string handling instructions if you wanted. I will not be surprised in the least if people design "custom instruction sets" that layer on top of a RISC-V core, just like layering a front end stack on web assembly. And the available resources to do that are pretty plentiful. One of the coolest architectures I got to play with was the Xerox "D" machines. They took this to an extreme and some amazing software was written for them. You could get really close to maximizing utilization. It was very interesting to load a new instruction set, recompile your Mesa code, and have it run faster with no changes to the hardware at all. Of course DEC and Xerox didn't invent this, the IBM 360 had a big button on the front "IMPL" which was "Initial Micro Program Load" which prepped the instruction set for what ever OS you were about to start up. And now you can build systems like this with open source tools and off the shelf FPGA dev boards. Such a great time to be interested in systems architecture. [1] https://twitter.com/erincandescent/status/1154535799423229952 https://twitter.com/erincandescent/status/115453579942322995...

audunw 6y ago
> However, FLASH/RAM volume has gone up hugely. This is in part because once you run out of logic to lay down in a chip you flood fill the rest with RAM and/or FLASH because hey the chip has to be big enough to hold pad landings for all of its pins. This has taken a lot of pressure off the code density thing and now it seems appropriate to look at algorithmic capacity. I don’t agree. I’m working on a chip right now where NVM and RAM is extremely constrained. There will probably be many millions made, so it’s still relevant. On the last chip I worked on, it was perhaps true to some degree. But that chip, even though it was a microcontroller, had a decent cache. Access to NVM is slow. And code density can have a significant impact on cache performance.

audunw 6y ago

> However, FLASH/RAM volume has gone up hugely. This is in part because once you run out of logic to lay down in a chip you flood fill the rest with RAM and/or FLASH because hey the chip has to be big enough to hold pad landings for all of its pins. This has taken a lot of pressure off the code density thing and now it seems appropriate to look at algorithmic capacity. I don’t agree. I’m working on a chip right now where NVM and RAM is extremely constrained. There will probably be many millions made, so it’s still relevant. On the last chip I worked on, it was perhaps true to some degree. But that chip, even though it was a microcontroller, had a decent cache. Access to NVM is slow. And code density can have a significant impact on cache performance.