Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Z8086: Rebuilding the 8086 from Original Microcode

nand2mario.github.io

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Z8086: Rebuilding the 8086 from Original Microcode

#21

Post by rep_lodsb »

rasz wrote: post #15
tasty_freeze wrote: post #13

Earlier quoted context omitted.

The Z80 had LDIR which was a string copy instructions. The byte at (HL) would be read from memory, then written to (DE), HL and DE would be incremented, and BC decremented and then repeated until BC became zero. LDDR was the same but decremented HL and DE on each iteration instead. There were versions for doing IN and OUT as well, and there was an instruction for finding a given byte value in a string, but I never us…

LDIR sounds great on paper but is implemented terribly making it slower than manual unrolled loop https://retrocomputing.stackexchange.com/questions/4744/how-... Repeat is done by decrementing PC by 2 and re-loading whole instruction in a loop. 21 cycles per byte copied :o To be fair Intel did same fail implementation of REP MOVSB/MOVSW in 8088/8086 reloading whole instruction per iteration, REP MOVSW is ~14 cycles/b…

Only the Z80 refetched the entire instruction, x86 never did it this way. Each bus transfer (read or write) takes multiple clocks:

    CPU                        Cycles  per              theoretical minimum per byte for block move
    Z80 instruction fetch      4       byte
    Z80 data read/write        3       byte             6
    80(1)88, V20               4       byte             8
    80(1)86, V30               4       byte/word        4
    80286, 80386 SX            2       byte/word        1
    80386 DX                   2       byte/word/dword  0.5
LDIR (etc.) are 2 bytes long, so that's 8 extra clocks per iteration. Updating the address and count registers also had some overhead.

The microcode loop used by the 8086/8088 also had overhead, this was improved in the following generations. Then it became somewhat neglected since compilers / runtime libraries preferred to use sequences of vector instructions instead.

And with modern processors there are a lot of complications due to cache lines and paging, so there's always some unavoidable overhead at the start to align everything properly, even if then the transfer rate is close to optimal.

Re: Z8086: Rebuilding the 8086 from Original Microcode

#23

Post by adrian_b »

rep_lodsb wrote: post #21
rasz wrote: post #15

Earlier quoted context omitted.

LDIR sounds great on paper but is implemented terribly making it slower than manual unrolled loop https://retrocomputing.stackexchange.com/questions/4744/how-... Repeat is done by decrementing PC by 2 and re-loading whole instruction in a loop. 21 cycles per byte copied :o To be fair Intel did same fail implementation of REP MOVSB/MOVSW in 8088/8086 reloading whole instruction per iteration, REP MOVSW is ~14 cycles/b…

Only the Z80 refetched the entire instruction, x86 never did it this way. Each bus transfer (read or write) takes multiple clocks: CPU Cycles per theoretical minimum per byte for block move Z80 instruction fetch 4 byte Z80 data read/write 3 byte 6 80(1)88, V20 4 byte 8 80(1)86, V30 4 byte/word 4 80286, 80386 SX 2 byte/word 1 80386 DX 2 byte/word/dword 0.5 LDIR (etc.) are 2 bytes long, so that's 8 extra clocks per ite…

This is correct, but it should be noted that the 2-cycle transfers of 286/386SX/386DX could normally be achieved only from cache memory (if the MB had cache), while for DRAM accesses at least 1 or 2 wait states were needed, lengthening the access cycles to 3 or 4 clock cycles.

Moreover, the cache memories used with 286/386SX/386DX were normally write-through, which means that they shortened only the read cycles, not also the write cycles. Such caches were very effective to diminish the impact on performance of instruction fetching, but they brought little or no improvement to block transfers. The caches were also very small, so any sizable block transfer would flush the entire cache, then all transfers would be done at DRAM speed.

Re: Z8086: Rebuilding the 8086 from Original Microcode

#24

Post by CodeWriter23 »

tasty_freeze wrote: post #13
CodeWriter23 wrote: post #10

"Oddball string instructions", as an assembler coder bitd, they were a welcome feature as opposed to running out of registers and/or crashing the stack with a Z-80.

The Z80 had LDIR which was a string copy instructions. The byte at (HL) would be read from memory, then written to (DE), HL and DE would be incremented, and BC decremented and then repeated until BC became zero. LDDR was the same but decremented HL and DE on each iteration instead. There were versions for doing IN and OUT as well, and there was an instruction for finding a given byte value in a string, but I never us…

LDIR? We used DMA for that.

I was referring to LODSB/W (x86) which is quite useful for processing arrays.

Re: Z8086: Rebuilding the 8086 from Original Microcode

#25

Post by LargoLasskhyfv »

adrian_b wrote: post #16
tom_ wrote: post #9

Earlier quoted context omitted.

The 286 looks like it ought to be usefully quicker in general? Motorola did a good job on the programming model, but you can tell that the 68000 is from the 1970s. Nearly all the 68000 instructions take like 8+ cycles, and addressing modes can cost extra. On the 286, on the other hand, pretty much everything is like 2-4 cycles, or maybe 5-7 if there's a memory operand. (The manual seems to imply that every addressing…

The timings given in the datasheet of 286 are very optimistic and they can almost never be encountered in a real program. They assume that instructions have been fetched concurrently without ever causing a stall and that memory accesses are implemented with 0 wait states. In reality, instruction fetching was frequently a bottleneck and implementing a memory with 0 wait states for 80286 was much more difficult than fo…

> but by the time of the coexistence with 386 the 286 became the cheap option, so its motherboards never had cache memory

Not true. I vaguely remember servicing systems with chipsets from OPTI(only 2 large ones) having it. IIRC those were funtional(not exact) clones of Chips&Technologies NEAT(4 to 5 large chips), later shrunken to one by SCAT (Single Chip AT).

Also in times when the 386 ran at 33Mhz, or even at 40 if made by AMD, Compaq introduced 386SX systems with cache, and I remember wondering "why, oh why?". Talk about overengineering...

Re: Z8086: Rebuilding the 8086 from Original Microcode

#26

Post by rasz »

adrian_b wrote: post #23
rep_lodsb wrote: post #21

Earlier quoted context omitted.

Only the Z80 refetched the entire instruction, x86 never did it this way. Each bus transfer (read or write) takes multiple clocks: CPU Cycles per theoretical minimum per byte for block move Z80 instruction fetch 4 byte Z80 data read/write 3 byte 6 80(1)88, V20 4 byte 8 80(1)86, V30 4 byte/word 4 80286, 80386 SX 2 byte/word 1 80386 DX 2 byte/word/dword 0.5 LDIR (etc.) are 2 bytes long, so that's 8 extra clocks per ite…

This is correct, but it should be noted that the 2-cycle transfers of 286/386SX/386DX could normally be achieved only from cache memory (if the MB had cache), while for DRAM accesses at least 1 or 2 wait states were needed, lengthening the access cycles to 3 or 4 clock cycles. Moreover, the cache memories used with 286/386SX/386DX were normally write-through, which means that they shortened only the read cycles, not…

0 wait state 286 was pretty standard affair for 8-10 and some 12MHz gray boxes. Example https://theretroweb.com/motherboard/manual/g2-12mhz-zero-wai...

"12MHz/0 wait state with 100ns DRAM."

another https://theretroweb.com/chip/documentation/neat-6210302843ed...

"The processor can operate at 16MHz with 0.5-0.7 wait state memory accesses, using 100 nsec DRAMs. This is possible through the Page Interleaved memory scheme."

Re: Z8086: Rebuilding the 8086 from Original Microcode

#27

Post by helf »

tasty_freeze wrote: post #12
ErroneousBosh wrote: post #7

Earlier quoted context omitted.

Not only was it microcoded, but it was sufficiently divorced from the assumptions of the 68000 instruction set that IBM were able to have Motorola make custom "68000-based" chips that ran S/370 code directly. Want a different architecture? Sure, just draw it with a different ROM. Simple (if you've got IBM money to throw around).

I read (30 years ago) the book "Microprocessor Design" by Nick Tredennick. He was the architect and wrote the microcode for both the 68K and the S/370. The S/370 was based on his recent design experience with the 68K, but it wasn't just a microcode swap. In the book he describes his process where he would write the ucode for each instruction on a 3"x5" card (or was a 4"x7"). At times he'd find sequences that were too…

[dead]
Post reply on HN