Anon (anon.delete@this.anon.com) on January 8, 2020 8:37 pm wrote:
> David Kanter (dkanter.delete@this.realworldtech.com) on January 8, 2020 8:27 am wrote:
> > Honestly, the biggest problems for x86 seem like the truly variable length decode.
> >
> > It's a good idea to look at it in historical context; a lot of ISAs in a similar time frame were far more
> > ugly. Also, some of the annoying things like reg,mem instructions are actually nice when you rename.
>
> At that time CPUs were fetching one byte at a time, variable
> length was not a problem at all, code density was.
>
> Probably nobody at Intel imagined that basic CPU architecture would be alive 40 years later,
> code density got worst after extensions had to search for exotic unused opcodes.
>
> To name one bad feature I will say segments, of all methods of addressing
> data beyond the native int size Intel probably choose the worst of them.
>


For me, the worst feature of Intel 8086, which was inherited by all its successors, was that all the registers were different. There were not even 2 equivalent registers.


Even if for some instructions the 8 GPRs were equivalent, for each register there was a set of instructions that used it in a special way.

The lack of equivalent registers made it difficult to really optimize the programs, especially in an automatic way, because it was hard to predict which will be the optimal allocation of the registers without doing an exhaustive search among all possible allocations.


While the AMD 64-bit extensions is a little better, because the 16 GPRs can be partitioned in a few groups, some of which contain several equivalent registers, especially when one no longer uses some obsolete instructions with implicit registers, this still is very far from an architecture where all the GPRs are equivalent, so that the optimal register allocation is much simpler.

For example, if we look at the 64-bit addressing modes, even if they are slightly more regular than the 32-bit addressing modes, the instruction length depends on which registers happen to be used for address computation, so this already partitions the GPRs in several non-equivalent classes.

After we also consider the many other instructions that have a length dependent on the register used or which use certain implicit registers, then the register equivalence classes fragment even more.