From: muta...@gmail.com   
      
   On Tuesday, September 20, 2022 at 7:47:10 AM UTC+8, muta...@gmail.com wrote:   
   > On Tuesday, September 20, 2022 at 4:47:15 AM UTC+8, anti...@math.uni.wroc.pl   
   wrote:    
   > > 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_n   
   cV20V30U_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.    
   > > >    
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)