I didn't personally downvote you, but I'll give you my best guesses: 1) The percentage of die used for decoding is actually already quite low. Per Anandtech 20

I didn't personally downvote you, but I'll give you my best guesses: 1) The percentage of die used for decoding is actually already quite low. Per Anandtech 2014, it was at 10% for x86 and decreasing: http://www.anandtech.com/show/8776/arm-challinging-intel-in-the-server-market-an-overview/12 http://www.anandtech.com/show/8776/arm-challinging-intel-in-... Since there is a floor to the number of transistors needed for decoding, there might not be a whole lot to gain there. 2) Progress has already been made towards updating instruction sets to reflect what CPUs do quickly, well etc. It started with MMX back in the stone age, and has progressed through a plethora of SIMD and media acceleration instructions. 3) Instruction sets are already not designed as if they were supposed to be run directly. Quite to the contrary, they are abstracted -- the instruction set is the API, and the microoperations are the instructions. Designing them as if they were to run directly would mean exposing the micro-ops, which would require backwards compatibility breaking changes to the CPU each generation when there were changes to the micro ops. 4) The current system already pretty well levels energy consumption between competing ISAs. See: http://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient http://www.extremetech.com/extreme/188396-the-final-isa-show... You're describing something that sounds like a bytecode VM, but in essence, that's what modern processors already are. Unfortunately, x86 (at least 32 bit) assembly is pretty unpleasant as an 'API', but ARM and PowerPC are both pretty good. As far as pointer tagging, that's something that's probably mostly limited by memory bandwidth (it's not a particularly compute heavy thing to do), so unless the HW support came in the form of a dedicated on-chip cache, it probably wouldn't get you very much ... and then, if you're going to the expense of adding a dedicated on-chip cache, it's probably going to be more effective as a general purpose cache -- if the code is accessing the pointer metadata often, it will be in cache, and therefore accelerated. Not trying to rain on your parade, I like seeing creative ideas, and I have no idea why people are downvoting you. Have an upvote on me :). EDIT: Also, ARM has NEON.