The “high-level CPU” challenge (2008)

Author here. I think today that apart from making my case in a bit of an obnoxious tone, I also somewhat overstated it: while it's true that many "high-level" constructs do have a cost that will not magically go away due to any logic built into hardware, at least not fully, it is also ought to be true that a lot can be done in hardware to make software's life easier given a particular HLL programming model, and I'm hardly…

"You don't think about memories when you design hardware" I found that comment interesting because memory is mostly what I think about when I design hardware. Memory access is by far the slowest thing, so managing memory bandwidth is absolutely critical, and it uses a significant portion of the die area. Also, a significant portion of the microarchitecture of a modern CPU is all about managing memory accesses. If there were a hypothetical high-level CPU language that somehow encoded all…

Suppose you want to support strings and have a string comparison instruction. You might think that "it's done in the hardware", so it's blindingly fast. It isn't, because the hardware still has to access memory, one word per cycle. A superscalar/VLIW assembly loop would run just as quickly; the only thing you'd save is a few bytes for instruction encoding. Actually if you've actually looked at things like SSE memory copying/comparison routines, it's not "a few bytes", it's more like…

Should be tagged (2008). Other than that, the follow up is interesting.