As an EE working as a, and with other programmers, I hear a lot of these arguments whenever the matter of "why CPUs aren't evolving" comes up. There's a lot of

As an EE working as a, and with other programmers, I hear a lot of these arguments whenever the matter of "why CPUs aren't evolving" comes up. There's a lot of misconception here. > Hardware design is still in pretty nascent stage, technology-wise. The languages used (say SystemC or Verilog) offer very little high-level abstraction There are a lot of things people outside microelectronics miss in this: * Much (most?) of the research invested into HDLs is not related to the languages themselves. Verilog and VHDL and SystemC are really good enough for the things they describe. Really, they are; they may not look like much in terms of "high-level abstraction", but when you need to understand the relation between what you write and what gets done on silicon, that's actually a feature. It's turning Verilog code into silicon that's actually challenging and where a lot of effort goes. The benefits of being able to describe something in a functional manner and 10% fewer lines of "code" are belittled by the benefits of getting better output from a Verilog compiler. * Some (not all, but some) ASIC design is actually done without HDLs. I don't know if Intel still does it. AMD stopped at one point and the results were tragic. * There are, seriously, realistically, very few actual obstacles that stem from HDLs. Physical obstacles -- not just the laws of physics, but the difficult technological processes -- are considerably bigger obstacles. And then there's market presure: > Sections of the CPU are still typically designed in isolation in an ad-hoc way, using barely any measurements, and rarely on anything more than a few small kernels. "Barely any measurements" is not an accurate description of the ASIC design process IMHO. Yes, simulation/model extraction tools are used a lot more than in other fields of electronics, but that's somewhat hard to avoid when a) you're designing for a barely tested technological process (because it's brand new!) and b) prototypes are kind of expensive. > Excel is about the most statistically advanced tool used in this. I haven't done CPU design but I've seen some IC design being done (and wrote tools for people who did it). Maybe it's true for some CPU manufacturers, but I doubt it. I'm pretty sure that it especially won't cut it for mixed-signal designs like microcontrollers. > As long as design teams only focus on their one little portion of the chip, without any overarching goal of global optimization, we're leaving a ton of performance on the table. I'm not sure what you understand by "global optimization" but there's a lot of research done on topics like power-efficient caches, which is at least a form of optimization of more than one trait. > The software people have just been treating hardware as a fixed target they have no control over, trusting that it will keep improving. This is, unfortunately, an accurate description. There has been a time when software people weren't treating hardware as such, due to lack of abstraction-level tools, and I'm quite sure not even Wirth wishes to go back in time to then. > To optimize hardware parameters, you need to make lots of measurements of representative software workloads. But where do those come from, and how are they compiled? Compiler writers have the liberty to change the way code is compiled to optimize performance on a specific chip (even if this isn't done so much in practice). This is actually done quite a lot in practice, even within a single CPU family, like on x86, although granted not as much as it could be done. However, optimizing hardware parameters is somewhat meaningless as long as you need a general-purpose CPU. You can only go so far when considering potential workloads -- but that is being done, too. IBM's POWER cores, for instance, still try to improve sequential performance, because many of them still run single-threaded batch jobs for much of their functioning time. > To get an actually representative measurement of hardware, these compiler changes need to be taken into account. Ideally, you'd be able to tune parameters at all layers of the stack, and design software and hardware together as one entity. This has actually been attempted since the first reconfigurable logic arrays emerged in the late 70s/ early 80s. Unfortunately, it's plagued by the problem that the infrastructure required to dynamically reconfigure logic circuits is a drag. That's actually what makes FPGAs so slow. I don't think FPGAs are the end of it, but "almost zero progress" is many light-years away from being an accurate description of the progress that has been made since MMI's PAL. > Backwards compatibility is another reason. New instructions get added regularly, but those are only for cases where big gains are achieved in important workloads. It's also done because practical experience has shown that, barring extreme stuff like OISC or perverted register-starved architecture design, instruction sets literally have negligible gain in terms of performance. Given enough time on the market, compilers that efficiently exploit any architecture will be designed. I mean shit it worked for the 80386! However, not adding new instructions != not adding new features, not since microcoded architectures appeared. Granted, manual optimization is (sometimes?) still needed for extended sets (e.g. SSE), but their applications are niched enough that those applications that can't make use of them based on compiler inference alone are bound to be hand-optimized anyway. Edit: compulsory disclaimer. I didn't do industrial level IC design, but I used to do research directly related to it and write software for that. This does mean I never actually did anything significantly more complex than a couple of current mirrors and logic circuits, but I did work with people who did. However, my experience is more on the analog IC side. I'm only casually familiar with logic IC design, so I may be unintentionally bullshitting you :-).