Howard Chu (hyc.delete@this.symas.com) on November 22, 2020 1:52 pm wrote:
> Brett (ggtgp.delete@this.yahoo.com) on November 20, 2020 8:56 pm wrote:
> > David Hess (davidwhess.delete@this.gmail.com) on November 20, 2020 6:35 pm wrote:
> > > This is in contrast to Intel and AMD who develop for the desktop market and adapt
> > > for the server and portable markets. Both have run concurrent development for
> > > lower power applications in the past but that has never turned out well.
> >
> > 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.
> >
> > 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?
>
> You should look at VX64, someone has already gone thru the exercise of
> rationalizing the x86-64 encoding
>
> http://www.emulators.com/docs/nx05_vx64.htm

Reasonable for the era, but has the code density of Itanic which will cost 3% in performance.
A heads and tails packed format that is cache line sized (or half cache line sized) is the best bet for what Intel/AMD will do for the next instruction format.
And you will be able to jump into the middle of a packet, or again the code density would be to horrible to use.

> > 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.