Hacker News Reader

Comment by kens | Hacker News Reader

Author here. Any questions about 8086 microcode?

What happens if you reference a segment greater than 4 in the ModR/M byte? For example, MOV Ew, Sw [8C] with "reg==5". Does the logic just ignore the upper bit?

On an 80186+, you'd get a #UD, but the 8086 doesn't have strictly "undefined" opcodes; everything does something.

I'm pretty sure that the extra bit will get ignored. There is internal circuitry that expands the register number in the instruction to a 5-bit register number. (You need 5 bits to handle 8-bit registers, 16-bit registers, segment registers, and internal registers.) For segment registers, it drops the third bit. But I haven't tested this case, so I can't guarantee there isn't some weird side-effect.

When accessing memory, is there also microcode dealing with generating a pagefault when the address is invalid?

The 8086 doesn't have virtual memory, so there is no such thing as a pagefault or invalid address. For a memory access, the microcode blocks until the bus interface circuitry completes the memory access. If there's physically nothing there, the memory access will either hang or come back with random garbage.

Don't believe there's an acknowledgement in the bus protocol. There's a RDY line with which a device can insert wait states before replying, and a HOLD that can be used for DMA from other devices. But there's no way for the CPU itself to detect the "there is physically nothing there" case. You indeed just get the arbitrary state of the data bus (the ISA bus was pull-up, I believe, so you'd get 1's on the data bus, which on the PC would then result in a parity error if the address was within RAM space).

(And yes, I'm still waiting with bated breath to see the teardown of the machine that implements this ridiculous bus.)

I was thinking the the READY line might cause problems. If nothing pulls it high, the memory access will be blocked forever. But I haven't looked much at how systems physically implement the bus, so maybe it defaults high.

Wouldn't the READY line get pulled up eventually when something else (a device, or possibly DRAM refresh?) uses the bus?

I got curious and went to check the schematics. On the original PC, the READY input to the 8088 is the synchronized version of the RDY input to the 8284 clock generator chip (which probably explains why Ken and I were spelling it differently). This is generated by a latch delay circuit automatically based on the IOCHRDY signal on the 8 bit ISA bus (and some other local stuff on the board), which itself is an open collector line pulled high.

So indeed, if nothing does anything, #READY will go active automatically, simultaneously with the data lines (not!) being driven, and the CPU will sample junk.

Which is to say: IBM had to add a bunch of hardware to the board just to synthesize a default/ignore behavior for this line, which wouldn't have been necessary had Intel done it right the first time.

Just curious, is there an unintended condition, a combination of commands to put the CPU into an undefined state?

Well, there are opcodes that aren't documented instructions. The 8086 doesn't trap on bad opcodes, so it will execute them and do something. I'm not sure if that's what you mean by "an undefined state". I think the undocumented 8086 instructions are all deterministic, as opposed to the 6502 where the results can depend on bus fluctuations.

On 6502 some of the undefined opcodes (usually named KIL) put the chip into an state where it no longer executes any instructions and doesn't respond to interrupts either. And such state isn't reachable via documented instructions. Maybe that kind of 'state' was meant?

If I remember correctly, that's because the decode PLA which takes opcode + current cycle number (one-hot signal) has a bit that indicates "last cycle" which resets the logic to check for interrupts and begin a new instruction cycle, and for the unused entries it isn't set in any cycle, so the cycle counter "runs off the end" and there's no more active bit to continue execution.

On the 8086, the microcode counter would eventually roll over and reach a "next instruction" bit even if it went into a normally unreachable part, so I don't think that such a state is possible.

Reply on news.ycombinator.com