[HN Gopher] Reverse-engineering the conditional jump circuitry i...
___________________________________________________________________
Reverse-engineering the conditional jump circuitry in the 8086
processor
Author : picture
Score : 63 points
Date : 2023-01-23 20:05 UTC (2 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| WebDevAndML wrote:
| This is some hackker shipp ...
| mrlonglong wrote:
| I'm absolutely interested in this mysterious 108 micro op!
| Hopefully you'll find it.
| kens wrote:
| Yes, another look inside the 8086. Any suggestions on what part
| of the 8086 I should write about next?
| pwg wrote:
| Have you posted anything explaining how the chip senses, and
| responds to, the external interrupt pins? I.e., the circuitry
| that handles detecting a level change plus how the microcode
| reacts when an interrupt signal occurs.
| fortran77 wrote:
| The 8087!
| kens wrote:
| I've written a few articles about the 8087:
| https://www.righto.com/search?q=8087
| monocasa wrote:
| hlt handling would be neat to know. IIRC from your earlier
| posts (and Andrew Jenner's) that was random logic when I kind
| of expected that to be handled by ucode (but I guess makes
| sense that it's probably one off logic anyway and doesn't
| really make sense to abstract out into ucode for that one
| instruction). Do parts of the core get clock gated?
| Particularly the dynamic pieces that one would expect to drain
| out. What does recovery from halted state look like internal to
| the core and is there any other cleanup that needs to occur
| when starting back up?
| kens wrote:
| What do you mean "hit handling"? Edit: I guess I need a
| bigger font :-)
|
| There's no clock gating; everything gets the clock. There's
| not a lot to say about HALT. It stops memory operations and
| the prefetch queue, so the processor stops processing until
| it gets an interrupt.
| monocasa wrote:
| > What do you mean "hit handling"?
|
| Not hit, hlt instruction.
|
| > There's no clock gating; everything gets the clock.
| There's not a lot to say about HALT. It stops memory
| operations and the prefetch queue, so the processor stops
| processing until it gets an interrupt.
|
| Oh, ok. So ucode is just sitting in that state waiting for
| Q to fill in for an extra long time is all? Is the prefetch
| queue flushed or are the next bytes sitting in Q
| prefetched, simply not presented to ucode?
| ajross wrote:
| Unless you did it already and I missed it, my vote would be for
| the external bus sequencing. The 8086's multiplexed A/D bus and
| its 4-clock (!) cycle have always seemed needlessly complicated
| to me, especially when compared to the 68k's async bus or the
| 6502's "?!$!@ it, just expose the internal latches" designs.
| Clearly Intel was thinking it was getting value here somehow
| (well, something more than pure pin count optimization), but it
| really just seems like they were adding behavior they didn't
| need.
| kens wrote:
| Yes, the bus sequencing is very complex. Memory accesses turn
| out to have a 6-clock cycle, but two cycles are overlapped
| with the end of the previous access, so it's even more of a
| mess than you'd think.
|
| I think a large part of it was pin count optimization; Intel
| had weird beliefs about keeping the pin count down. (E.g.
| Intel was really resistant about using even 18 pins for the
| 8008, which was way too few.) Another issues was the 8086
| supported two different bus protocols: "minimum" and
| "maximum" mode, where "minimum" was straightforward and easy
| to use, while "maximum" provided much more information but
| needed another chip to decode the signals. (I don't know if
| anyone used "minimum" mode.) Finally, the 8087 needed a lot
| of information about what was going on inside the 8086's
| prefetch queue, so that needed more bus signals.
| rasz wrote:
| speaking of interfacing 8087 fresh post from today:
| http://www.os2museum.com/wp/learn-something-old-every-day-
| pa...
| pwg wrote:
| > Intel had weird beliefs about keeping the pin count down.
|
| They might seem weird by today's standards, but by late
| 1970's standards, a '40 pin' package was significantly
| cheaper for others to incorporate into their designs than
| another size. There were a lot fewer "standard socket
| sizes" available back then, and anything that wasn't
| already available entailed a lot of expense to manufacture,
| resulting in a very high initial cost (comparatively) to
| recover the capital expenditure to bring the new size to
| production.
| kens wrote:
| Intel's beliefs about pin count were weird even for the
| time. See Federico Faggin's oral history (p55-56) for a
| discussion about how making everything 16 pins was like a
| religion at Intel, damaging functionality, at a time when
| other companies had 40 or 48 pin packages. The Motorola
| 68000 had 64 pins.
|
| http://archive.computerhistory.org/resources/text/Oral_Hi
| sto...
| shadowofneptune wrote:
| Have address calculations been covered yet? Those are pretty
| complex on the '86.
|
| Alternatively, the 'rep' prefix would be interesting.
| kens wrote:
| Those are good suggestions. I'll see if I can figure out how
| to explain them :-)
| peterfirefly wrote:
| I vaguely remember that it had trouble remembering more than
| one prefix past an interrupt -- so if you wanted to combine
| REP with a segment override prefix you should put the REP
| first, then the segment override prefix, then the string
| instruction... and then some conditional jump stuff that
| jumped back to the REP if CX != 0.
|
| So basically: repeat: rep
| cs: scasb jcxz done
| jmp short repeat done:
| shadowofneptune wrote:
| Micheal Abrash's book covers this. May just be better to
| swap out the segment registers at that point though.
___________________________________________________________________
(page generated 2023-01-23 23:00 UTC)