[HN Gopher] The Group Decode ROM: The 8086 processor's first ste...
       ___________________________________________________________________
        
       The Group Decode ROM: The 8086 processor's first step of
       instruction decoding
        
       Author : zdw
       Score  : 43 points
       Date   : 2023-05-14 16:32 UTC (6 hours ago)
        
 (HTM) web link (www.righto.com)
 (TXT) w3m dump (www.righto.com)
        
       | kens wrote:
       | Author here if anyone has 8086 questions...
        
         | agalunar wrote:
         | Why did the 8086 have the LOCK prefix? I think of it as being
         | mostly useful in parallel contexts, e.g. lock cmpxchg for an
         | atomic compare and swap. But the 8086 was a single core, single
         | thread processor, and I'd be surprised if it were used in
         | multiprocessor machines. Oh! did it have anything to do with
         | the 8087?
        
         | bonzini wrote:
         | > Out 11 indicates instructions where bit 7 is the byte/word
         | indicator
         | 
         | Wouldn't that be bit 0?
        
           | kens wrote:
           | Thanks! I've been doing too much IBM System/360 stuff and I
           | can't remember which way to count bits :-)
        
             | bonzini wrote:
             | I did want to put an IBM joke in there ;) though I'm more
             | familiar with PPC's big-endian bit counting than S/360.
        
         | ngneer wrote:
         | Any insight into how CALL/RET opcodes were decided or why they
         | are in different groups? Is it merely that these would have
         | been free opcodes?
         | 
         | Digging up some stack history:
         | https://en.wikichip.org/wiki/intel/mcs-4/4004 4004 - 4-level
         | stack using PCx registers, with JMS/BBL to transition to/from
         | subroutine, causing return address pushes/pops (deepest ones
         | lost); 4040 - 8-level stack using PCx registers; 8008 - 8-level
         | stack using AS call levels; 8080 - stack pointer register (SP)
         | ...
        
         | sanqui wrote:
         | This is tangential, but seeing the 8086 opcode table organized
         | in octal groups made me realize the same applies for the
         | instruction set of the Z80 (my home CPU). Your articles are
         | always very insightful, thank you!
        
           | stevekemp wrote:
           | Zilog and Intel have a lot of crossover in that regard, due
           | to engineers moving from one to the other.
           | 
           | There's a whole lot of documentation on decoding instructions
           | for the z80 which makes these octal relationships clear.
           | 
           | One good site is http://z80.info/, for example.
           | 
           | (I started coding on the Z80, and nowadays tinker with a
           | single-board machine running CP/M on one.)
        
             | bonzini wrote:
             | The 8080 has 7 registers and a single addressing mode for
             | accumulator-based instructions (which is most of them),
             | therefore base-8 organization is pretty natural. Likewise
             | for 8086 which has 8 registers and 8 ways to use registers
             | to form an addressing mode (with absolute addressing and
             | three different displacement modes, there would be
             | 8*3+1=25, but they sacrificed [BP] to fit everything in
             | MOD={00,01,10}). Of course one wonders if the choice of 8
             | registers and 8 addressing mode was due to some kind of
             | fixation with base 8, or vice versa.
             | 
             | Compared to the 6809, the 6502 or the 68000, the biggest
             | reminiscence of the Z80 is the difference between
             | AX/CX/DX/BX having 8-bit parts and SI/DI/SP/BP not having
             | them. Though the low/high parts of IX and IY were
             | accessible on the Z80 via undocumented opcodes (maybe even
             | SP? I don't remember).
        
       | rietta wrote:
       | @kens Off the wall question, i may have a working 8088 that has
       | been stored in an air conditioned basement at my parents. I
       | learned to program on this in the 90s. Is there a practical
       | benefit of getting it running again?
        
         | kens wrote:
         | I don't think there's any practical reason to do that unless
         | you want to get into the retrocomputing community.
        
         | metadat wrote:
         | Are processors themselves typically sensitive to storage
         | temperature? I know motherboards are (lol, ask me how 0...):,
         | but given the operating conditions, I'm struggling to see how
         | anything other than corrosion or +/-100c would damage a stored
         | processor.
        
       | userbinator wrote:
       | _This illustrates how a complex instruction format impacts
       | performance._
       | 
       | I'm not sure how much simpler it could be? The propagation delays
       | are intrinsic to the process.
       | 
       | Even 32-bit ARM isn't particularly easy to decode, and there are
       | _plenty_ of special cases there as well. 64-bit ARM is even more
       | complex, like they tried to cram as many operations as they could
       | in 32 bits of instruction.
       | 
       | Maybe MIPS is simpler to decode, but I remember seeing lots of
       | odd gaps in the opcode map, and it's not really an example of
       | high performance either.
        
       ___________________________________________________________________
       (page generated 2023-05-14 23:00 UTC)