muta...@gmail.com  wrote:   
   > On Monday, September 19, 2022 at 8:05:05 PM UTC+8, Joe Monk wrote:   
   > > > But while we're here, would it have been possible to   
   > > > create an 8080 that wasn't so different from the 8086   
   > > > that there would be an expectation of binary   
   > > > compatibility?   
   > > >   
   > > > What do you recommend?   
   > >   
   > > A chip by NEC called the V20/V30. It could run both 8080A and 8086 code...   
   (V20 = 8 bit bus, model uPD70108, V30 = 16 bit bus, model uPD70116) It was   
   binary compatible with both the 8080A and the 8086.   
   > >   
   > > "The uPD70108/70116 has two CPU operating modes: native and 8080   
   emulation. In native mode, the uPD70108/70116 executes all the instructions   
   given in Section 12, with the exception of the RETEM and CALLN instructions.   
   In 8080 mode, the microprocessor    
   executes the instruction set for the uPD8080AF and the RETEM and CALLN   
   instructions. These modes are selected by special instructions or by using an   
   interrupt. The most significant bit of the PSW is a mode (MO) flag that   
   controls mode selection."   
   > >   
   > > https://ia903205.us.archive.org/28/items/bitsavers_necV20V30   
   _11351331/V20_V30_Users_Manual_Oct86.pdf   
   > >   
   > > Joe   
   >   
   > I don't think this is what I'm looking for.   
   >   
   > I don't want either 8080 or 8086.   
   >   
   > I'm after a subset of 8086 to replace the 8080.   
   >   
   > In the same way that zarch can run s/390   
   > instructions.   
   >   
   > No mode change required.   
      
   I do not understand why you do not want mode bits?  In 8086 prefix   
   changes meaning of the following instruction.  Similarly, mode   
   change affects meaning of following instructions.  You may   
   object that prefix affects only single instruction, but it   
   is really artificial distinction.  In 387 there is rounding   
   mode which affect all instructions after mode change.   
   Similarly direction flag affects following instruction.   
   Logically, one can treat processor flags as mode bits that   
   that change meaning of following instructions.  For example   
   in "no-carry" mode JNC is just a NOP, in "carry" mode JNC   
   acts as plain jump.   
      
   So are you going to forbid 387 and direction flag?  I suspect   
   that you are not going to forbid conditional jumps, as that   
   would make 8086 essentially useless (one could still implement   
   control using modification of targets of indirect jumps, but   
   that would be extremally awkward).  Note that thare are   
   processors without flag bits, IIUC MIPS is an example of   
   such processor.  So if you trurly dislike mode bits maybe   
   you should use MIPS?   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)