[HN Gopher] Silicon reverse-engineering: the Intel 8086 processo...
___________________________________________________________________
Silicon reverse-engineering: the Intel 8086 processor's flag
circuitry
Author : zdw
Score : 51 points
Date : 2023-02-11 17:54 UTC (5 hours ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| kens wrote:
| More 8086 reverse-engineering for your enjoyment. Let me know if
| you have any questions.
| controversial97 wrote:
| As I understand it, the 8086 has a separate address space for
| io.
|
| As in, memory address $3f8 is just a RAM location and not the
| same thing as the base register of the COM1 serial port.
|
| This is unlike 1980's home computers that use a 6502, where
| things like the keyboard interface appear to be just another
| memory location from software.
|
| Is there anything interesting related to how that is handled in
| hardware?
| ajross wrote:
| To the 8086 hardware, the "IO Space" is a single line[1] on
| the bus, essentially a 21st address bit. When that is set,
| the "memory-like" devices know to ignore the transaction and
| "io" devices know to decode the address.
|
| At the software level, it's accessed by different
| instructions. Instead of MOV with a memory location, you use
| IN or OUT. And notably those instructions take only a 16 bit
| address and no segment selector, so IO space is limited to
| 64kb.
|
| Also note that to the _IBM PC_ , IO space was routinely
| truncated to just 10 bits. I honestly don't know if that was
| ever standardized or not, but that's the way production
| devices and chipsets have always worked. The extra address
| lines never worked, and generally aliased with devices in the
| bottom of the space that were ignoring the top bits.
|
| [1] Actually it's multiplexed in a group of 8 bus states
| addressed by three lines, because Intel was stingy about
| pins. But logically it's an extra address line. [This is the
| spot where I repeat my request to Ken to please do a blog
| post on the insane bus management on this device, which I'd
| dearly love to see.]
| kens wrote:
| The 8086 inherited the separate I/O space from the Datapoint
| 2200, a "programmable terminal". Since the Datapoint 2200 had
| a custom TTL processor, it was convenient to build in
| instructions to manipulate its I/O hardware directly. It
| doesn't make as much sense for a general-purpose
| microprocessor, which is why the 6502 etc didn't follow that
| approach. (Separate I/O instructions make sense in something
| like the IBM System/360 mainframes, where they were executed
| by a separate channel controller and gave you more
| performance.)
|
| As far as the implementation of I/O in the 8086 chip, I
| haven't come across anything particularly interesting yet.
| It's essentially the same bus state machine as memory, except
| it signals an I/O access rather than a memory access.
| controversial97 wrote:
| Is there an output from the instruction decoder that
| indicates an instruction is doing io? or maybe one for read
| and one for write?
| monocasa wrote:
| Interestingly, the two oddball ALU flags (PF and AF) live on in
| at least one modern arch. Apple Silicon has an undocumented
| extension to calculate those and store them in unused ARM flag
| bits. Having Rosetta manually calculate those on each of the ALU
| ops (or at least the ones the compiler can't remove the flag
| calculation of) would massively cut into it's speed. And
| apparently Apple either had traces of them being used or enough
| fear that someone important was still using them in order to
| include hardware support.
|
| https://bytecellar.com/2022/11/16/a-secret-apple-silicon-ext...
| userbinator wrote:
| I've seen compression algorithm inner loops (handwritten Asm)
| use those flags.
| ant6n wrote:
| I'm a little bit surprised these flags are used in a way that a
| simple backflow analysis wouldn't reveal. If those flags are
| used within one function (that is, flags only need to be
| preserved across local branches), then an analysis should find
| the uses and corresponding instructions that set those. If
| those flags are used across function boundaries (e.g. after a
| return or passed as an argument), then it would be harder to
| detect, so a conservative emulator would have to correctly
| emulate the flags across all calls and returns.
|
| But do those uses actually exist? What are those use cases for
| the flags that isn't just some straight line code or maybe
| using some simple branches? Is there code that relies on even
| weirder cases like creating a fault, with the fault handler
| depending on correctly set A/P flags? Or did Apple just not
| want to deal with having flow analyses in their JIT emulator
| and decided going the hardware route was easier?
| derefr wrote:
| My guess is that there's an x86-ISA JIT or emulator or
| threaded-code VM, that _itself_ reuses these flag bits (when
| it can guarantee a stretch of non-ALU code) to smuggle
| information between HLL ops. So Apple is in effect
| transparently transporting the smuggled data.
___________________________________________________________________
(page generated 2023-02-11 23:00 UTC)