5 ms·

Author here if anyone has any questions.

by ajenner 6y ago

soufron 6y ago
Yup. Who did write the microcode at the time? And for how long?
- ajenner 6y ago
  According to https://en.wikipedia.org/wiki/Intel_8086 https://en.wikipedia.org/wiki/Intel_8086: "The architecture was defined by Stephen P. Morse with some help and assistance by Bruce Ravenel (the architect of the 8087) in refining the final revisions. Logic designer Jim McKevitt and John Bayliss were the lead engineers of the hardware-level development team and Bill Pohlman the manager for the project." I expect the microcode was developed in tandem with the rest of the chip, so probably took about 2 years.
schoen 6y ago
What's "random logic"? From context, it sounds like circuitry that explicitly implements the functionality of an opcode, as opposed to circuitry that can be used by the microcode, or something?
- ajenner 6y ago
  Yes, exactly - the logic that implements the simpler instructions directly as special-purpose gates rather than microcode.
  - kens 6y ago
    To expand on that, "random logic" means that it looks random; it's not actually random. This is in contrast to circuits that have an underlying structure to them, like a PLA or ROM.
derefr 6y ago
> While most of the unused parts of the ROM (64 instructions) are filled with zeroes, there are a few parts which aren't. The following instructions appear right at the end of the ROM [...] Given that they're right at the end — and seemingly intentionally written there after the rest of the unused space before them was zeroed — might those bytes be a checksum of the ROM?
- ajenner 6y ago
  I don't think there's anything on the chip that could compute a checksum of the microcode ROM contents. It could be some kind of copyright message perhaps, though I don't know how it's encoded and it's only 42 bits long so there isn't much space for anything meaningful.
  - derefr 6y ago
    I would guess that it’s not a runtime-verified checksum, but rather a simple embedded “sum complement” value, used for ROM-mastering-time integrity verification. A sum-complement value is a value computed from some data, such that, when the data is checksummed with the sum-complement value now embedded into it, the data will sum to zero. This approach to checksumming is useful, as any potential verifier just has to throw the image-as-a-whole through the checksumming algorithm, and ensure that the output is zero. It doesn’t need one iota of knowledge about what it’s verifying. It doesn’t even need an extra machine-register to hold the expected checksum. These “blind” checksums allow ROM production hardware (programmers, copiers) to both pre-verify the integrity of the input image, and to post-verify that it has programmed the image onto a chip successfully. No special container format for the ROM image is required, nor is the ROM image required to be structured in any particular way (which is good, because ROMs are used for all sorts of things, not just code.) The ROM image can be any opaque blob, just as long as it sums to zero. In fact, you don’t even need a ROM “image” at all. It’s possible to integrity-verify a programmed ROM “against itself”; and thus, a hand-programmed ROM (e.g. an EEPROM you programmed in your office) can be sent to the duplication facility to serve as the reference from which mask-ROM masks will be generated. The data on the EEPROM can be trusted, because it sums to zero. And the mask ROMs themselves can be checked for flaws by seeing whether they sum to zero. For smaller-scale ROM distribution, ROM-to-PROM bulk copiers are used. These copiers can be made to both pre-verify the source, and to post-verify the programmed copies. Using this approach to checksumming, the copier can avoid having to verify the source “against” the destination, instead only needing to verify the source once, and then verify the destinations against themselves. This both speeds up verification; and allows for the use of simpler microcontrollers in these copiers, which reduces their design cost. (By quite a lot, back in the 1970s, when all this was most relevant.) You can see this approach to checksumming in practice in early-generation game cartridge ROMs, which almost always have these embedded sum-complement values (and so presumably were integrity-verified during mastering/duplication.) These sum-complement value fields get referred to by emulators as “the checksum” of the ROM image—but technically, they’re not; if you’re following along, you’ll realize that “the checksum” of such ROM images is zero! :)
mkup 6y ago
Does MUL/IMUL/IDIV result negation trick (via REP prefix) work on later 8086-compatible Intel CPUs (e.g. 80286, 80386 etc)?
- ajenner 6y ago
  I have just learned from dreNorteR on VCF that it no effect on a 286 but has a different, unexpected, and useful effect on a 186! http://www.vcfed.org/forum/showthread.php?76657-8088-8086-microcode-disassembly&p=635234#post635234 http://www.vcfed.org/forum/showthread.php?76657-8088-8086-mi...
dm319 6y ago
I wonder if you could do a version of this article for a lay person like me? I really enjoyed Ken's articles because it assumed very little knowledge.
userbinator 6y ago
Does the microcode give any hints on why the general PUSH and POP are in completely different places in the opcode map (push is FF/6, pop is in its own group in 8F/0 with 8F/1-7 invalid, while FF/7 is unused)? It almost looks like FF/7 was supposed to be the pop. I've always wondered what 8F/1-7 and FF/7 do on an 8086/8 too, but it's very hard to find that information.
Akababa 6y ago
If ROM space is so valuable, why is ASCII text (which I imagine is relatively large) stored on it?

Author here if anyone has any questions.

soufron 6y ago

Yup. Who did write the microcode at the time? And for how long?

ajenner 6y ago
According to https://en.wikipedia.org/wiki/Intel_8086 https://en.wikipedia.org/wiki/Intel_8086: "The architecture was defined by Stephen P. Morse with some help and assistance by Bruce Ravenel (the architect of the 8087) in refining the final revisions. Logic designer Jim McKevitt and John Bayliss were the lead engineers of the hardware-level development team and Bill Pohlman the manager for the project." I expect the microcode was developed in tandem with the rest of the chip, so probably took about 2 years.

schoen 6y ago

What's "random logic"? From context, it sounds like circuitry that explicitly implements the functionality of an opcode, as opposed to circuitry that can be used by the microcode, or something?

ajenner 6y ago
Yes, exactly - the logic that implements the simpler instructions directly as special-purpose gates rather than microcode.
- kens 6y ago
  To expand on that, "random logic" means that it looks random; it's not actually random. This is in contrast to circuits that have an underlying structure to them, like a PLA or ROM.

derefr 6y ago

> While most of the unused parts of the ROM (64 instructions) are filled with zeroes, there are a few parts which aren't. The following instructions appear right at the end of the ROM [...] Given that they're right at the end — and seemingly intentionally written there after the rest of the unused space before them was zeroed — might those bytes be a checksum of the ROM?

ajenner 6y ago
I don't think there's anything on the chip that could compute a checksum of the microcode ROM contents. It could be some kind of copyright message perhaps, though I don't know how it's encoded and it's only 42 bits long so there isn't much space for anything meaningful.
- derefr 6y ago
  I would guess that it’s not a runtime-verified checksum, but rather a simple embedded “sum complement” value, used for ROM-mastering-time integrity verification. A sum-complement value is a value computed from some data, such that, when the data is checksummed with the sum-complement value now embedded into it, the data will sum to zero. This approach to checksumming is useful, as any potential verifier just has to throw the image-as-a-whole through the checksumming algorithm, and ensure that the output is zero. It doesn’t need one iota of knowledge about what it’s verifying. It doesn’t even need an extra machine-register to hold the expected checksum. These “blind” checksums allow ROM production hardware (programmers, copiers) to both pre-verify the integrity of the input image, and to post-verify that it has programmed the image onto a chip successfully. No special container format for the ROM image is required, nor is the ROM image required to be structured in any particular way (which is good, because ROMs are used for all sorts of things, not just code.) The ROM image can be any opaque blob, just as long as it sums to zero. In fact, you don’t even need a ROM “image” at all. It’s possible to integrity-verify a programmed ROM “against itself”; and thus, a hand-programmed ROM (e.g. an EEPROM you programmed in your office) can be sent to the duplication facility to serve as the reference from which mask-ROM masks will be generated. The data on the EEPROM can be trusted, because it sums to zero. And the mask ROMs themselves can be checked for flaws by seeing whether they sum to zero. For smaller-scale ROM distribution, ROM-to-PROM bulk copiers are used. These copiers can be made to both pre-verify the source, and to post-verify the programmed copies. Using this approach to checksumming, the copier can avoid having to verify the source “against” the destination, instead only needing to verify the source once, and then verify the destinations against themselves. This both speeds up verification; and allows for the use of simpler microcontrollers in these copiers, which reduces their design cost. (By quite a lot, back in the 1970s, when all this was most relevant.) You can see this approach to checksumming in practice in early-generation game cartridge ROMs, which almost always have these embedded sum-complement values (and so presumably were integrity-verified during mastering/duplication.) These sum-complement value fields get referred to by emulators as “the checksum” of the ROM image—but technically, they’re not; if you’re following along, you’ll realize that “the checksum” of such ROM images is zero! :)

mkup 6y ago

Does MUL/IMUL/IDIV result negation trick (via REP prefix) work on later 8086-compatible Intel CPUs (e.g. 80286, 80386 etc)?

ajenner 6y ago
I have just learned from dreNorteR on VCF that it no effect on a 286 but has a different, unexpected, and useful effect on a 186! http://www.vcfed.org/forum/showthread.php?76657-8088-8086-microcode-disassembly&p=635234#post635234 http://www.vcfed.org/forum/showthread.php?76657-8088-8086-mi...

dm319 6y ago

I wonder if you could do a version of this article for a lay person like me? I really enjoyed Ken's articles because it assumed very little knowledge.

userbinator 6y ago

Does the microcode give any hints on why the general PUSH and POP are in completely different places in the opcode map (push is FF/6, pop is in its own group in 8F/0 with 8F/1-7 invalid, while FF/7 is unused)? It almost looks like FF/7 was supposed to be the pop. I've always wondered what 8F/1-7 and FF/7 do on an 8086/8 too, but it's very hard to find that information.

Akababa 6y ago

If ROM space is so valuable, why is ASCII text (which I imagine is relatively large) stored on it?