6 ms·

The Intel 8088 processor's instruction prefetch circuitry: a look inside

185 points by matt_d 3y ago

kens 3y ago
Author here for your 8086/8088 questions...
- Tuna-Fish 3y ago
  From the blog: > However, the 8-bit bus enabled cheaper computer hardware. I wonder if that can be expanded on. An old (now departed) friend once said to me that this was a mirage, because the only thing that the narrower bus really bought them was that it made the 16kB configuration possible, which no-one actually bought (the minimum for using floppies was 32kB!). He claimed that the narrower bus didn't actually make the configurations with more RAM cheaper because it made them require more support chips. Is there any truth to this?
  - gary_0 3y ago
    It's mentioned at the bottom of this article[0] that Intel had an obsession with using the smallest packaging and pin count possible, while competitors did not see any need to be that conservative. I wonder if that has something to do with it. [0] https://www.righto.com/2023/07/8086-pins.html https://www.righto.com/2023/07/8086-pins.html
    - phire 3y ago
      The 8088 and 8086 actually have the same number of pins and almost identical pinouts, despite the the difference in data bus width. This is because the data and address are multiplexed onto the same pins, because of intel's obsession with lowest pincount (each pin does add quite a bit of cost to packaging). On the 8086, the bottom 16 address pins (of 20) are multiplexed with data, on the 8088, only the bottom 8 address pins are multiplexed. So you had to demultiplex the bus no matter which chip you chose. I think the cost savings mostly come from being able to configure systems with only 8 DRAM chips per bank (instead of 16 DRAM chips per bank with the 8086). A 16 bit bus also requires that your ROM chips are in pairs, and it probably increases the motherboard routing complexity. And a small bit of extra decoding logic. A 16 bit bus would have also required IBM to skip straight over the 8 bit ISA standard with it's smaller sockets and forced up the complexity of all PC expansion cards (which would also require double the ROM chips, double the RAM chips and extra logic) Edit: And now that I think about it, the fact that the upper bit of the address bus aren't multiplexed might actually allow you to simplify the DRAM row/column addressing logic... But only if you put the column into the upper bits of the address.
  - kens 3y ago
    According to Dave Bradley, one of the creators of the IBM PC, "We chose the 8088 [over the 8086] because of its 8-bit data bus. The smaller bus saved money in the areas of RAM, ROM, and logic for the simple system." Another thing is that even if almost nobody bought the minimal RAM configuration, having a low-cost configuration can be very important from a marketing standpoint. (By the way, it's kind of amazing that the base RAM for an IBM PC was just 16 kilobytes, and now 16 gigabytes is a base RAM configuration.) https://www.tech-insider.org/personal-computers/research/1990/09.html https://www.tech-insider.org/personal-computers/research/199...
  - adrian_b 3y ago
    The cost saving was more a marketing trick. Most of the savings were not from memory but from the reuse of the existing 8-bit peripherals without additional hardware and without software changes. On a 16-bit bus, you could connect an 8-bit peripheral to one of its halves, but then the internal registers that previously were at consecutive addresses now were spread at multiples of 2. When doing only 8-bit transfers, you could rewrite the software drivers to use the modified addresses. However you could not do 16-bit transfers, because the bytes were no longer in the same word. This could be fixed with additional buffers, decoders and registers, to convert 16-bit transfers into pairs of 8-bit transfers on the same bus half (like 8088 did internally), but that would increase the cost. Even if these compatibility problems were not too difficult to solve, most preferred to avoid them, in the quest for minimum cost.
h2odragon 3y ago
> The 8086/8088 do not provide consistency ... self-modifying code can be used to determine the queue length, distinguishing the 8086 from the 8088 in software. I sincerely doubt I was the first to work that out; but I remember being so incredibly happy when I figured that one out, when it solved a problem i had. Cannot now recall why the difference was significant, something about installing different routines for bashing serial ports i think.
- kens 3y ago
  Neat! Eventually, Intel added the CPUID instruction so you could determine the processor type without trickery.
  - temac 3y ago
    IIRC it was added on Pentium and maybe late 486. You had to do classic tricks to identify the model before that.
    - userbinator 3y ago
      I beieve in the Pentium, the prefetch queue became snooped, which coincides nicely with the introduction of CPUID.
      - convolvatron 3y ago
        it also may have something to do with why CPUID is strongly serializing? that always really confused me..its not like, the CPU type is going to race with a load or a store
        phire 3y ago
        I suspect the serialising is just a side effect of the CPUID instruction being implemented as a massive microcode routine.
      - adrian_b 3y ago
jecel 3y ago
A 4116 DRAM chip with a 250 ns access time would have a 500 ns cycle time, so could read or write 2 million words per second. The Acorn people called this a 2 MHz memory. You could have shorter cycle times in "column mode" where you pulsed the /CAS signal only to access words in the same row and the Acorn designers made good use of that for the Electron (reading 8 bits from a 4 bit wide memory) and the ARM based Archimedes (fetching instructions other than jump, load or store as well as loading the video and audio FIFOs). From one DRAM generation to the next the cycle time might be different for chips with the same access time. This allowed me to make the 512KB Macintosh faster than the 128KB one (http://www.merlintec.com/lsi/mac512.html http://www.merlintec.com/lsi/mac512.html).
- djmips 3y ago
  That's a fantastic read! Thanks for sharing. What are you working on these days?
  - jecel 3y ago
    Thanks! I still design Smalltalk computers like I did back then but now I also design my own processors.
- tom_ 3y ago
  You could also have shorter cycles times by just doing it and assuming it'll be fine. Acorn's Master Turbo uses 4864-2 DRAMs, which have a 150 ns access time/270 ns cycle time, for, I think, a max throughput of 1e9/270=3,703,703 bytes/sec - but the Master Turbo's 65c02 CPU runs at 4 MHz, and therefore requires 4,000,000 bytes/sec. And, somehow, it works...
  - jecel 3y ago
    That is probably similar to how you could use both sides of a single sided floppy. Both sides were tested and the factory ended up with a huge pile of floppies that passed both sides and a small pile that failed one side (and some that failed both sides and were discarded). The market wanted more single sided disks so they simply moved a number of floppies from the first pile to the second. That meant that you mostly likely got a double sided product when you paid for a single sided one. But it was a risk. Same thing of processor and memory speed bins.
kinj28 3y ago
I wonder if queue length is already maintained by queue counter then is there really a need for MT flag? Let’s say even if it is possible to do it, would the resulting saving of real estate and power would be worth the effort?
- phire 3y ago
  Two reasons: 1. The queue is 4 bytes long, which fits neatly in a two bit counter. You would have to switch to a three bit counter to store the 5th state, which increases the area and power usage by ~50% 2. The MT signal is explictly needed to stall the execution unit when the prefetch queue is empty. If you replaced the flag register with a 5th state of the queue counter, then you would still need combination logic to generate the MT signal (queue[0] != 1 || queue[1] != 1 || queue[2] != 1) I'm guessing this two bit counter + MT flag scheme is actually optimal from a transistor count perspective.
- jameshart 3y ago
  The queue length isn’t maintained by the queue counter. For a start, there are two queue counters - the write counter and the read counter, each of which is a two bit counter. Each points to one of the four positions in the queue. The queue itself though can be in one of five states - its length can be 0, 1, 2, 3, or 4. The difference between the position of the read and write counters (which is always available through the hardcoded XOR subtraction circuit detailed in the article) is either 0, 1, 2, or 3. The flag allows you to tell whether the 0 result of that subtraction is a zero length queue or a full queue.
userbinator 3y ago
It's quite humbling to look at how much they had to know to implement all these little details, and then realise that this is a 45-year-old design which is several orders of magnitude less complex than modern processors. Even other well-known CPUs of the time like the 6502 and Z80 are only a few years older, yet far simpler.
- deleted 3y ago
  [deleted]
tester756 3y ago
>Whenever I mention x86's domination of the computing market, people bring up ARM, but ARM has a lot more market share in people's minds than in actual numbers. One research firm says that ARM has 15% of the laptop market share in 2023, expected to increase to 25% by 2027. (Surprisingly, Apple only has 90% of the ARM laptop market.) In the server market, just an estimated 8% of CPU shipments in 2023 were ARM. See Arm-based PCs to Nearly Double Market Share by 2027 and Digitimes. (Of course, mobile phones are almost entirely ARM. "ARM has a lot more market share in people's minds than in actual numbers" haha, that's true, especially on HN
- klelatti 3y ago
  Domination apart from the CPUs that power the main computing devices for the large majority of people (billions) around the world.
- Dalewyn 3y ago
  I think it's grossly disingenuous to say "computing market" and then ignore the entire smartphone/tablet market. Hell, smartphones are by far the most personal computers we have ever had.
  - h2odragon 3y ago
    How about "user programmable computers," whereas phones are "terminals". I mean, I agree with your point; but the distinction is there. We need some way to differentiate between computers for hacking and computers that are vending machines for the hacks of others
    - Dalewyn 3y ago
      What meaningful distinction is there to be made? Computers are computers.
    - cesarb 3y ago
      > How about "user programmable computers," whereas phones are "terminals". My install of Termux from F-Droid on my Android phone disagrees with that. While more limited than a PC, most smartphones can still be considered "user programmable computers".

185 points by matt_d 3y ago

kens 3y ago

Author here for your 8086/8088 questions...

Tuna-Fish 3y ago
From the blog: > However, the 8-bit bus enabled cheaper computer hardware. I wonder if that can be expanded on. An old (now departed) friend once said to me that this was a mirage, because the only thing that the narrower bus really bought them was that it made the 16kB configuration possible, which no-one actually bought (the minimum for using floppies was 32kB!). He claimed that the narrower bus didn't actually make the configurations with more RAM cheaper because it made them require more support chips. Is there any truth to this?
- gary_0 3y ago
  It's mentioned at the bottom of this article[0] that Intel had an obsession with using the smallest packaging and pin count possible, while competitors did not see any need to be that conservative. I wonder if that has something to do with it. [0] https://www.righto.com/2023/07/8086-pins.html https://www.righto.com/2023/07/8086-pins.html
  - phire 3y ago
    The 8088 and 8086 actually have the same number of pins and almost identical pinouts, despite the the difference in data bus width. This is because the data and address are multiplexed onto the same pins, because of intel's obsession with lowest pincount (each pin does add quite a bit of cost to packaging). On the 8086, the bottom 16 address pins (of 20) are multiplexed with data, on the 8088, only the bottom 8 address pins are multiplexed. So you had to demultiplex the bus no matter which chip you chose. I think the cost savings mostly come from being able to configure systems with only 8 DRAM chips per bank (instead of 16 DRAM chips per bank with the 8086). A 16 bit bus also requires that your ROM chips are in pairs, and it probably increases the motherboard routing complexity. And a small bit of extra decoding logic. A 16 bit bus would have also required IBM to skip straight over the 8 bit ISA standard with it's smaller sockets and forced up the complexity of all PC expansion cards (which would also require double the ROM chips, double the RAM chips and extra logic) Edit: And now that I think about it, the fact that the upper bit of the address bus aren't multiplexed might actually allow you to simplify the DRAM row/column addressing logic... But only if you put the column into the upper bits of the address.
- kens 3y ago
  According to Dave Bradley, one of the creators of the IBM PC, "We chose the 8088 [over the 8086] because of its 8-bit data bus. The smaller bus saved money in the areas of RAM, ROM, and logic for the simple system." Another thing is that even if almost nobody bought the minimal RAM configuration, having a low-cost configuration can be very important from a marketing standpoint. (By the way, it's kind of amazing that the base RAM for an IBM PC was just 16 kilobytes, and now 16 gigabytes is a base RAM configuration.) https://www.tech-insider.org/personal-computers/research/1990/09.html https://www.tech-insider.org/personal-computers/research/199...
- adrian_b 3y ago
  The cost saving was more a marketing trick. Most of the savings were not from memory but from the reuse of the existing 8-bit peripherals without additional hardware and without software changes. On a 16-bit bus, you could connect an 8-bit peripheral to one of its halves, but then the internal registers that previously were at consecutive addresses now were spread at multiples of 2. When doing only 8-bit transfers, you could rewrite the software drivers to use the modified addresses. However you could not do 16-bit transfers, because the bytes were no longer in the same word. This could be fixed with additional buffers, decoders and registers, to convert 16-bit transfers into pairs of 8-bit transfers on the same bus half (like 8088 did internally), but that would increase the cost. Even if these compatibility problems were not too difficult to solve, most preferred to avoid them, in the quest for minimum cost.

h2odragon 3y ago

> The 8086/8088 do not provide consistency ... self-modifying code can be used to determine the queue length, distinguishing the 8086 from the 8088 in software. I sincerely doubt I was the first to work that out; but I remember being so incredibly happy when I figured that one out, when it solved a problem i had. Cannot now recall why the difference was significant, something about installing different routines for bashing serial ports i think.

kens 3y ago
Neat! Eventually, Intel added the CPUID instruction so you could determine the processor type without trickery.
- temac 3y ago
  IIRC it was added on Pentium and maybe late 486. You had to do classic tricks to identify the model before that.
  - userbinator 3y ago
    I beieve in the Pentium, the prefetch queue became snooped, which coincides nicely with the introduction of CPUID.
    - convolvatron 3y ago
      it also may have something to do with why CPUID is strongly serializing? that always really confused me..its not like, the CPU type is going to race with a load or a store
      - phire 3y ago
        I suspect the serialising is just a side effect of the CPUID instruction being implemented as a massive microcode routine.
    - adrian_b 3y ago

jecel 3y ago

A 4116 DRAM chip with a 250 ns access time would have a 500 ns cycle time, so could read or write 2 million words per second. The Acorn people called this a 2 MHz memory. You could have shorter cycle times in "column mode" where you pulsed the /CAS signal only to access words in the same row and the Acorn designers made good use of that for the Electron (reading 8 bits from a 4 bit wide memory) and the ARM based Archimedes (fetching instructions other than jump, load or store as well as loading the video and audio FIFOs). From one DRAM generation to the next the cycle time might be different for chips with the same access time. This allowed me to make the 512KB Macintosh faster than the 128KB one (http://www.merlintec.com/lsi/mac512.html http://www.merlintec.com/lsi/mac512.html).

djmips 3y ago
That's a fantastic read! Thanks for sharing. What are you working on these days?
- jecel 3y ago
  Thanks! I still design Smalltalk computers like I did back then but now I also design my own processors.
tom_ 3y ago
You could also have shorter cycles times by just doing it and assuming it'll be fine. Acorn's Master Turbo uses 4864-2 DRAMs, which have a 150 ns access time/270 ns cycle time, for, I think, a max throughput of 1e9/270=3,703,703 bytes/sec - but the Master Turbo's 65c02 CPU runs at 4 MHz, and therefore requires 4,000,000 bytes/sec. And, somehow, it works...
- jecel 3y ago
  That is probably similar to how you could use both sides of a single sided floppy. Both sides were tested and the factory ended up with a huge pile of floppies that passed both sides and a small pile that failed one side (and some that failed both sides and were discarded). The market wanted more single sided disks so they simply moved a number of floppies from the first pile to the second. That meant that you mostly likely got a double sided product when you paid for a single sided one. But it was a risk. Same thing of processor and memory speed bins.

kinj28 3y ago

I wonder if queue length is already maintained by queue counter then is there really a need for MT flag? Let’s say even if it is possible to do it, would the resulting saving of real estate and power would be worth the effort?

phire 3y ago
Two reasons: 1. The queue is 4 bytes long, which fits neatly in a two bit counter. You would have to switch to a three bit counter to store the 5th state, which increases the area and power usage by ~50% 2. The MT signal is explictly needed to stall the execution unit when the prefetch queue is empty. If you replaced the flag register with a 5th state of the queue counter, then you would still need combination logic to generate the MT signal (queue[0] != 1 || queue[1] != 1 || queue[2] != 1) I'm guessing this two bit counter + MT flag scheme is actually optimal from a transistor count perspective.
jameshart 3y ago
The queue length isn’t maintained by the queue counter. For a start, there are two queue counters - the write counter and the read counter, each of which is a two bit counter. Each points to one of the four positions in the queue. The queue itself though can be in one of five states - its length can be 0, 1, 2, 3, or 4. The difference between the position of the read and write counters (which is always available through the hardcoded XOR subtraction circuit detailed in the article) is either 0, 1, 2, or 3. The flag allows you to tell whether the 0 result of that subtraction is a zero length queue or a full queue.

userbinator 3y ago

It's quite humbling to look at how much they had to know to implement all these little details, and then realise that this is a 45-year-old design which is several orders of magnitude less complex than modern processors. Even other well-known CPUs of the time like the 6502 and Z80 are only a few years older, yet far simpler.

deleted 3y ago
[deleted]

tester756 3y ago

>Whenever I mention x86's domination of the computing market, people bring up ARM, but ARM has a lot more market share in people's minds than in actual numbers. One research firm says that ARM has 15% of the laptop market share in 2023, expected to increase to 25% by 2027. (Surprisingly, Apple only has 90% of the ARM laptop market.) In the server market, just an estimated 8% of CPU shipments in 2023 were ARM. See Arm-based PCs to Nearly Double Market Share by 2027 and Digitimes. (Of course, mobile phones are almost entirely ARM. "ARM has a lot more market share in people's minds than in actual numbers" haha, that's true, especially on HN

klelatti 3y ago
Domination apart from the CPUs that power the main computing devices for the large majority of people (billions) around the world.
Dalewyn 3y ago
I think it's grossly disingenuous to say "computing market" and then ignore the entire smartphone/tablet market. Hell, smartphones are by far the most personal computers we have ever had.
- h2odragon 3y ago
  How about "user programmable computers," whereas phones are "terminals". I mean, I agree with your point; but the distinction is there. We need some way to differentiate between computers for hacking and computers that are vending machines for the hacks of others
  - Dalewyn 3y ago
    What meaningful distinction is there to be made? Computers are computers.
  - cesarb 3y ago
    > How about "user programmable computers," whereas phones are "terminals". My install of Termux from F-Droid on my Android phone disagrees with that. While more limited than a PC, most smartphones can still be considered "user programmable computers".