Re:X86 Register Encoding
by gens on Tuesday November 01, 2016 @02:41PM
(#12848922)
AFAIK the reason for amd64 being what it is are intels lawyers.
[ Parent
| on HN ]
That makes little sense, could you elaborate? AMD could have done anything they wanted with amd64 instruction encodings.
Well, not lawyers directly. More through lack of cooperation (due to competitive mentality).
I don't see how that matters in this case, AMD took the lead on AMD64 and Intel had to copy them afterward. They really could have done anything they wanted. As someone else here mentioned it was probably more to re-use the existing investment in x86 decoders.
Amd64 encoding, as is the case with most x86 encodings, is longer then it should be. Due to the two companies not communicating/cooperating.
That is the one advantage that i think ARM has over x86/amd64. That ARM encoding is much shorter.
You just repeated your point without adding anything new, that doesn't help your argument.
They couldn't use the shorter code space. So no, they could not do whatever they wanted. (note that making a completely new instruction encoding scheme would fail for obvious reasons)
I disagree, 64bit mode did not have to have any kind of instruction compatibility. It could have been a completely new instruction encoding scheme. A 64bit process must run all 64bit code, there is no invoking 32bit code from a 64bit process on any modern OS for AMD64.
And adding to that, they could've probably come up with some sort of 32bit per instruction risc structure where the the makeup overlaps with the cisc x86 encoding. For example, pack the 16 bits of a normal x86 instruction into the first bits of the risc, then add second source register and a bit or to each operand to increase the number of registers.