Buses and the ALU in the 8086

Question

Intel's 8086 manual shows the following diagram for the CPU's architecture (in page 2-5):

If I understand correctly, the ALU's two operands and result are retrieved from / sent to the same 16-bit bus.

If I understand correctly, this causes every calculation to take a minimum of three cycles: Cycle #1: put the first operand on the bus, and copy it to a temporary register. Cycle #2: put the second operand on the bus, and copy it to a temporary register. Cycle #3: allow the ALU result on the bus.

This seems consistent with the timing tables (e.g. a register-register ADD is said to take exactly three clock cycles). (or not? I EDITed below)

However, this doesn't seem very efficient, and also, I saw other diagrams, like this one:

http://www.cosc.brocku.ca/~bockusd/3p92/Local_Pages/8086_achitecture.htm

that also show the Flags as being sent to the same bus, which doesn't really make sense to me.

So - is this the actual physical implementation, or an abstraction, and actually the "ALU bus" consists of multiple 16-bit lines?

EDIT: I wrote: "This seems consistent with the timing tables (e.g. a register-register ADD is said to take exactly three clock cycles).". In second thought, I'm not sure that it's consistent, because the IP register also needs to be incremented, so with 3 cycles per ALU add, the entire ADD instruction should take 6 cycles...

Answer 1

If there was a parallel set of ALU bus line, they would be shown.

The 8086 is a Complex Instruction Set Computer (CISC), where microcode inside processor is multi-purposed to get as much done using minimal memory. Everything is operating in parallel. It's not a matter of efficiency, but rather the decisions made by the designers within the technology of the day (1979). No cache, no cores, 29000 transistors.

Prefetch/Execute queue: Prefetch next sequential (n+1) instruction and execute present (n) instruction.

From MP and MC 8086 Microprocessor

The 8086 uses pipelining with instruction fetching and execution running in parallel.

On the Execution side, published execution cycles refer to execution.

Once it is in the 8086, a register-to-register ADD executes in 3 machine cycles.

ADD AX, BX

Clock Cycle 1: 16-bit AX transferred to Temp registers.

Clock Cycle 2: BX transferred to Temp registers.

Clock Cycle 3: ALU adds AX to BX and transfers result back to AX. Flags are set based on result.

On the Bus Interface Unit: While the ADD instruction is being processed the BIU is attempting to fetch the next instruction, which is completely dependent on memory timing.

The 16-bit IP and the Code Segment Register work together to point to a 20-bit address in a 64kbyte segment in memory to fill up the instruction queue.

Due to locality, the next instruction should be sequential. But any branch will trash the queue because it is fetching the next sequential instruction, which is not correct. Once the queue is trashed, the processor stalls while the next instruction is fetched.

Essentially, all Instruction Pointers are +1 counters. This has to be the case since the Prefetch queue has to fetch the n+1 instruction.

But there are two types of math involved with the IP.

• Precompiled math from the program compiler (Call sub-routine), where address is hard-coded in advanced (no ALU).
• Relative branching, where the execution of the instruction requires math (BNE +3) so IP is loaded into ALU, math is performed, result is loaded into IP. The Prefetched instruction is ignored (pipeline stalls - no execution) and next instruction pointed to by new IP is loaded into pipeline.

The flags are set by the contents of the present ALU calculation. So they have to be available to be tested by the ALU (in the next cycle).

CMP AX, 10 // Flags are set.

BNE Here // Check flags and Branch if AX <> 10,

// otherwise continue to next instruction.

Answer 2

"lines" and "buses" on MOS chips are abstractions. Usually any one "line" is actually implemented as complex trees of metal wire segments connected by pass logic, buffers, pipeline stages, and/or multiplexors. And not all "lines" on a bus are implemented with the same geography. Some lines in a bus might not even exist, but simply be logically optimized out of physical existence in a mux tree or destination input.