6

Why don't have a specific register to access this other part of register ( 16-32 )?

Like ah or al to access a 8-bits part of ax register.

enter image description here

sashoalm
  • 63,456
  • 96
  • 348
  • 677
Alexandre
  • 1,805
  • 1
  • 26
  • 52
  • Ok, I changed my question... – Alexandre Feb 10 '15 at 11:03
  • Rgister-accessors do not exist for this specific purpose, as they do not exist to access the higher 32 bits in a 64 bit size register. But You can shift the register contents so often, that they will be placed completely inside ax, which then is again accessible with the ax accessor, as well as ah/al. I always do it this way. – icbytes Feb 10 '15 at 11:15
  • If you're asking why the upper 16 bits don't have a name - it's because of history. The proper question to ask is why the lower 16 bits have name - because of 8086. As for AH - it's from 8088 days. Intel processors trace their lineage to 8088, which was an 8-bit processor. – sashoalm Feb 10 '15 at 11:15
  • 1
    @Alexandre I edited the question to be what you should have asked in the first place. – sashoalm Feb 10 '15 at 11:21

2 Answers2

5

The idea was to extend the registers to 32 bit, not to create a machine with twice as many 16 or 8 bit registers because you already had enough of those. To keep the encoding and the hardware simpler, they decided not to give direct access to the top 16 bits. Everything comes at a cost. Fun fact: the 64 bit extension did bring r8-r15 with it, but you can't access the top 32 bit of those directly either.

Jester
  • 52,795
  • 4
  • 67
  • 108
  • 1
    It's history - 8088, then 8086 and 286, then 386. Those are holdovers from those initial versions. See https://en.wikipedia.org/wiki/X86_instruction_listings#Original_8086.2F8088_instructions – sashoalm Feb 10 '15 at 11:20
  • 2
    @sashoalm: 8088 is post-8086: it's just an 8086 with an 8-bit data bus, but still 16-bit internally. – ninjalj Feb 10 '15 at 20:07
3

Because it is unnecessary. Most of the time you work with the full register. Even small low registers like AL and AX are not commonly used, let alone some arbitrary values in the middle of a register like AH or the high bytes of EAX which are hardly found in practice. Byte registers are mainly used with SETcc and MOVcc instructions. Word registers are even rarer and almost never used because the instructions are longer (need a prefix byte) and likely slower. Narrow values are usually sign or zero extended to the full register immediately

Allowing access to those high parts require the introduction of new opcodes which is difficult to find in the current tight free space, and that will pollute the x86 opcode space. Moreover, separate access to different parts of the registers will introduce more complex dependencies due to partial register update which may cause a stall

That's one of the reasons why all instructions with a 32-bit destination in x86-64 zero the upper part of the result instead of preserving it. Same to the high bytes of XMM in AVX. INC is also not preferred compared to ADD 1 nowadays because it introduces a partial flag update

See also

phuclv
  • 27,258
  • 11
  • 104
  • 360
  • `inc` doesn't normally lead to partial-flag stalls, only if you read the unmodified CF after `inc` on P6-family. Skylake seems to not even need flag-merge uops ever, even if you do something "clever" that intentionally reads both the unmodified CF *and* for example ZF. (But some `cmov` instructions like `cmovbe` and `cmova` that have both CF and SPAZO flag clusters as inputs decode to 2 uops, unlike most cmov predicates. Not a problem for JCC, it can have both flags as inputs.) – Peter Cordes Mar 03 '20 at 16:12