muta...@gmail.com  wrote:   
   > On Monday, September 19, 2022 at 11:59:42 PM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
   > > 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_necV2   
   V30U_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?   
   >   
   > I want a tiny memory model program to run on   
   > an 8086 at let's say the 64k location, which would   
   > mean the segment registers are all loaded with   
   > 0x1000   
   >   
   > The processor is not aware of the contents of   
   > that tiny memory model program so doesn't know   
   > it needs to switch mode.   
   >   
   > Even if it did switch mode, the segment registers still   
   > need to work, otherwise memory at location 0   
   > would be accessed instead of memory at   
   > location 64k.   
   >   
   > Perhaps you could have logic in the os that   
   > got it to switch mode before calling the   
   > com file. But then you couldn't have a com file   
   > with 8086 instructions, only 8080.   
   > And then you need a way of calling os services,   
   > at which point you need to switch mode back   
   > to 8086. Can it be done? Maybe.   
   >   
   > But it's a lot more complexity to add to   
   > both the NEC chip and msdos.   
      
   IIUC NEC chip uses segementation in 8080, namely when   
   switching modes you give it segement and start address   
   to use and it runs in specified segment.  I did not read   
   the whole description, but at first glance it works   
   quite nicely: interrupts switch it 8086 mode and   
   retrun from interrupt restores mode.   
      
   > When I was being chided for even wanting   
   > to add a single instruction to the 8086.   
      
   Well, real problem is gain for the effort.  NEC obtained   
   something of clear value: ability to run both 8080 and   
   8086 programs.  Of course, one can discuss how valuable   
   it was.  Around 1992 our department had bunch of PC-s   
   equipped with V20 (or maybe V30).  They were used as   
   ordinary PC-s, I am not aware of anybody using 8080 mode.   
   But when V20 was introduced it probably was more attractive...   
      
   > I haven't really thought through the 8086,   
   > but there is another environment   
   > that interests me - zarch.   
   >   
   > I wish to run 32 bit s390 programs,   
   > unmodified, at the 4 GB location.   
      
   But you really did no say why?  Why do you care   
   at which address program is loaded?  Normally   
   people care that program works correctly.  And   
   paging hardware was introduced to allow loading   
   program in arbitrary area of memory (so that you   
   have no trouble when two program want to use   
   "the same address" in conflictiong ways).   
      
   > To do that the os does need to be aware   
   > that it is a 32 bit not 64 bit program,   
   > but I don't have a problem with that, because   
   > 32 and 64 are very distinct needing   
   > different fixups.   
   >   
   > The os then needs to load certain registers with   
   > 1 in the high 32 bits, indicating the 4 GB   
   > location. Other registers will be loaded with   
   > 0 in the high 32 bits. These are data registers.   
   > The former were address registers.   
   >   
   > Actually I'm not sure if everything can be   
   > loaded with 1. I think it can. I discussed this   
   > 3 years ago or something but I've   
   > forgotten some details.   
   >   
   > Programs and os need to be changed,   
   > but that's fine, that's what pdos-generic is for.   
   > You can't do an svc, I can't remember why.   
   >   
   > I don't care if the compiler needs to be   
   > changed and I don't care that programs   
   > need to be recompiled.   
   >   
   > We can discuss s390 if you want, but it was already   
   > discussed to my satisfaction.   
   >   
   > My goal at the moment is to make   
   > a modified 8080 to x64 as good as   
   > the unmodified s390 to zarch.   
      
   Hmm, if you are satified with recompilation, then modify   
   your favorite C compiler to generate x86_64 instructions, but   
   operate on 16bit, 32bit or 64-bit data as appropriate.   
   To emulate segmentation dedicate one (or few) registers   
   as base registers (my impression was that the compiler left   
   a lot of registers with no use so you can easily find   
   free registers).   
      
   OTOH, when I compile a program I want to compile it for right   
   architecture, so for running on x86_64 I use 64-bit mode.   
   On Arm ATM I mostly use 32-bit mode because most of my Arm   
   machines are 32-bit.   
      
   I think I already mentioned project which wanted to use   
   64-bit instruction encoding but limit data to 32-bits.   
   Motivation for this was that 64-bit instructions are   
   more efficient than 32-bit ones (mostly due to extra   
   registers) but 64-bit data requires more work than   
   32-bit data.  IIUC there was (is??) (at least preliminary)   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)