> legacy compatibility features [...] those CPUs won't be as efficient, cheap, reliable or secure as they otherwise could be [...] we can't rely on increasing t

> legacy compatibility features [...] those CPUs won't be as efficient, cheap, reliable or secure as they otherwise could be [...] we can't rely on increasing transistor density to bail us out. Legacy features shouldn't have a large impact on transistor usage, and they should have almost no impact on efficiency (although that may involve design choices). Almost all of the transistors are going to be used to implement the cache, routing between the high level blocks (external IO, cores, shared cache), and routing between the various microarchitecture units. Using Broadwell as an example, the CPU cores[1] only use a relatively small amount of amount of area. However, even that is misleading, because most of the acre within each core is dedicated to the microarchitecture, which implements a far smaller set of micro-ops. Inside each core[2], the only place affected by legacy instructions is the decode stage (mostly in the "4-Way Decode" block in [2], probably less in the "PreDecode" block"), and a larger MicoCode ROM. The legacy instructions might not be as efficient as they used to be in older CPUs; as low-priority instructions they may be implemented with less-convenient micro-ops that were designed for other, faster instructions. The software that uses those instructions was probably designed for a far slower CPU anyway, so it's probably no important if those instructions are a "slow" when the CPU overall is much faster. I agree that the interactions between instructions might increase the difficulty of security, concurrency, or other higher-level concerns, but that will depend on the specific instruction. I'm not sure how large these concerns might be, unfortunately, so I cannot say if it's a serious issue. > so their complexity ends up being "dead weight" This sounds suspiciously like the unfortunate recent practice of labeling "old" things as "bad" or "holding back progress" and thus must be removed. In most cases backwards compatibility is a very important feature that adds very little cost. The low cost is possible because you can usually implement older features in terms of the newer features. This is true in CPU microcode, just like it's true in software. [1] http://i59.tinypic.com/2mrxso9.jpg http://i59.tinypic.com/2mrxso9.jpg [2] https://en.wikichip.org/w/images/thumb/a/a1/broadwell_block_diagram.svg/850px-broadwell_block_diagram.svg.png https://en.wikichip.org/w/images/thumb/a/a1/broadwell_block_...