How do Intel systems know how much to increment the instruction pointer?

[chrstrbrts]

Hello,

OK, so it's obvious to me, through reading the Intel "master manual", that Intel systems are definitely not RISC systems.

I suppose, in my limited experience, that one aspect of CISC systems is complicated opcode schemes.

That is, CISC systems based on n-bit architectures don't necessarily operate on a set of purely n-bit opcodes.

For example, modern Intel 64-bit processors operate on opcodes that may be anywhere from one byte long to 15 bytes long.

My question is: how do Intel systems know that the next instruction is n bytes long and that the instruction pointer register should be adjusted accordingly?

 

[exdeath]

Part of the prefetcher and decoder hardware and predictor hardware. It's already parsing each operand size override and extended instruction prefix, opcode, and parameters as it encounters them so it already just knows.

Simplified its like how you would write an emulator core:

fetch next byte at [IP], IP++;
byte is a prefix? yes/no, handle accordingly
byte is a opcode? yes/no, handle accordingly
fetch next byte at [IP], IP++;
byte is an opcode for ???
fetch next n parameter bytes at [IP] where n is determined by opcode and prefix and current mode settings, IP+= num bytes fetched;
whole instruction fetch completed, commit final IP back to IP register and start over.

Say you have 66 B8 13 00 CD 10 in memory.

If you are in 32 bit mode that becomes:

mov ax, 0x0013
int 10

If you are in 16 bit mode that becomes

mov eax, 0x10CD0013
???

Which it is, and if IP is +=4 or +=6 is determined by the combination of: a) upon reading 0x66 and recognizing it as the 16/32 bit override prefix b) the B8 opcode being mov ax/mov eax, and c) the current operating mode.

Part of the reason modern x86 decoders are so complex. So many prefixes and overrides, variable instruction lengths, and numerous opcodes that mean different things with the same opcode.

If you really want to see the hardware logic go look at a 8086 core in VHDL or Verilog. You'll see what looks almost exactly as you would imagine an emulator loop except expressed in concurrent logic statements with various IP increments based on the computed prefix, opcode, and parameters.

Modern CPU of course the 8086 instruction set is just a user interface and they are translated to uops and sent to a scheduler buffer, but the front end fetch and decode hardware parsing from L1 code cache is keeping track of bytes parsed as they are linearly in RAM and uses that to increment IP as it goes.

 

[chrstrbrts]

Thanks for the reply; it was very enlightening.

However, I have a question about the following (emphasis mine):

Say you have 66 B8 13 00 CD 10 in memory.

If you are in 32 bit mode that becomes:

mov ax, 0x0013
int 10

If you are in 16 bit mode that becomes

mov eax, 0x10CD0013
???

Which it is, and if IP is +=4 or +=6 is determined by the combination of: a) upon reading 0x66 and recognizing it as the 16/32 bit override prefix b) the B8 opcode being mov ax/mov eax, and c) the current operating mode.

If I remember correctly, the ultimate arbiter regarding setting default operand sizes isn't necessarily the operating mode; it's the D/B bit in the descriptor for the active code segment.

Right?

 

[exdeath]

Yup that's the one. I know dozens of CPUs and mix them up sometimes. 65816 and ARM 7 for example have explicit mode settings for 8/16 or 16/32 operation.

X86 uses the D(efault) bit in the code segment active in CS to determine default operand mode. I did alot of 32 bit hacking in the DOS days which was 16 bit so got familiar with prefixes and overrides and manual opcode entry.

 

[chrstrbrts]

Thanks.