Scott Lurndal  wrote:   
   > antispam@math.uni.wroc.pl writes:   
   > >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_necV20   
   30U_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?   
   >   
   > MIPS has plenty of mode bits in CP0 registers.  It doesn't   
   > track the traditional conditional flags (NZCV, Q) in a register because   
   > it folds a COMPARE and a CONDITIONAL BRANCH into a single   
   > instruction.   
      
   Yes.  My point was that normal progrem run on PC fiddles with   
   mode-like bits.  IIUC on MIPS you can set modes once (say in   
   OS) and than run program without touching anything like modes.   
      
   Of course, when Paul learns that that there are mode bit on   
   MIPS he will want to run programs compiled for different   
   modes without changing mode bits, so you are right, the   
   problem would come back...   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)