Brett (ggtgp.delete@this.yahoo.com) on November 20, 2020 8:56 pm wrote:
>
> I have long brow beated Intel for not designing a 3 GHz chip for mobile, cheap
> ass morons they are. But to go wider x86 decoding becomes expensive in area and
> heat. x86 is stuck between a rock and a hard place, something has to give.

Even before Smartphones, I thought Intel's abandonment of the low power embedded market was a mistake because it would allow someone else, ARM in this case, to do to Intel what Intel did to the RISC workstation and server markets. They later made a token defense but it was too little and too late to do more than delay.

> If x86 stays stuck then ARM will pass it by in the next half decade.
>
> Will x86 be forced to change to a fixed width instruction format, or at least something easier to decode?

I suspect the effects of instruction format and decoding will be minor compared to other factors and less so with micro-operation cache.

> 32 bit opcodes are getting tight, how about 3+3 byte opcodes page aligned, 3 bytes is good for integer opcodes
> and 6 bytes gives you a big FPU register file with 4 operands, and all the oddball x86 add from memory stuff
> with bigger offsets. Yes you can do add from memory as two 3 byte opcodes but that burns a visible register,
> etc. RISC is stupid today, the way forward is more complex instructions to reduce code path lengths, etc.

It would not be the first time Intel extended an instruction set in a way that old programs could be translated at the level of assembly language. For full backwards compatibility, legacy operating modes could be replaced with firmware based emulation in some form.