muta...@gmail.com  wrote:   
   > On Thursday, July 15, 2021 at 6:03:56 AM UTC+10, wolfgang kern wrote:   
   >   
   > > you sure can map many 64KB physical consecutive blocks to also   
   > > consecutive segment descriptors i.e.:   
   > >   
   > > 0008 base 0000_0000 code limit ffff   
   > > 0010 base 0000_0000 data   
   > > 0018 base 0001_0000   
   > > 0020 base 0001_0000   
   > >   
   > > but the selector must be calculated, simple shift wont help here.   
   > > so your idea to make it an easy solution fell flat :)   
   >   
   > I have told you at least twice that my calculation will be   
   > a division and a multiplication. Not a shift.   
   >   
   > And the calculation doesn't start from a random value,   
   > it starts from an existing segment/selector.   
   >   
   > If I currently have a data (ie not cs) seg:off of 3000:0000,   
   > which on the 80386 with effective 16-bit shifts would be   
   > x'3000' / 64k = 3 * x'10' (distance between data selectors)   
   > + x'10' (starting point of data selectors, not code selectors)   
   > = x'40', and then the program adds 64k to this pointer, and   
   > so the new target is 4000:0000 there will be a non-hardcoded   
   > divide and multiply, in our case because we're doing 16-bit   
   > effective shifts the divisor is 64k, and because we're using   
   > an 80386 not some theoretical 99986 processor (with a   
   > distance of say 5 bytes), the distance between data selectors   
   > is x'10' so the multiplier is x'10' then you have:   
   >   
   > x'40' + 1 * x'10' = x'50'   
   >   
   > which will correctly get you to the next selector.   
   >   
   > On an 8086 the divisor (provided by the OS to the application   
   > at startup time, exactly the same way when running on an   
   > 80386) will always be 16 and the multiplier will always   
   > be 1, so to jump 64k starting at 3000:0000 you will have   
   >   
   > 64k / 16 = 4096 * 1 = 4096 = x'1000' added to x'3000' and   
   > you have x'4000' so you end up at 4000:0000.   
   >   
   > Which bit won't work?   
   >   
   > I'm sure plenty of people won't like the design, but will it   
   > work or not?   
      
   Depends very much what "works" mean.  Running unmodified   
   86 binaries: AFAICS no.  You are creating a virtual machine   
   which with little care (and assuming divisor 16) will run the   
   same binary on 86 and 386.   
      
   > If it works then the next question is - does the 8086 ignore   
   > x'66' and advance to the next byte? Or can x'66' be trapped   
   > and ignored? Or if it is an alias, what effect does it have,   
   > and can memory be structures to keep that x'66' from   
   > harming anything important?   
      
   There were several 86 processors: original 86, 88 (in original PC)   
   "compatible" processors by AMD and Harris, NEC variant (which   
   had Z80 mode so certainly used different mask).  Some machines   
   used 186 (which at lowest level was incompatible, but some   
   manufactutes pushed "PC-s" based on them), there is 286.   There   
   were various steppings and speed grades.  Steppings fixed bugs   
   and were supposed to make no change to documented instructions,   
   but it is hard to tell what could happend to undocumented stuff.   
      
   > If the answer to the above is "ok it will work, but the trapping   
   > will make it 5% slower", that is within my 10% flexibility, so   
   > the next question is:   
      
   Hmm.  On 86 multiply and divide take time comparable to tens   
   of simpler instructions.  You also have problem of finding   
   place to keep your divisor.  If you keep divisor in register,   
   that alone will blow up your 10% budget (losing a register on   
   86 is closer to 20% drop in performace) and introduce seroius   
   incompatiblity with traditional 86 code.  If you keep divisor in   
   memory there will be extra segment manipulations to fetch   
   divisor.   
      
   > What 16-bit instructions are available on the 80386 if I code   
   > x'66' or x'67' wherever necessary?   
   >   
   > And finally, with the above instructions, can a Turing   
   > machine be constructed on the 8086 and if so, how   
   > much slower would a C program be compared to if   
   > I had access to the full range of 8086 instructions?   
   >   
   > Since this is my own C applications we are talking   
   > about, I probably don't care (even if the year is 1988)   
   > if my program runs 3 times slower than the machine   
   > code generated by the same C compiler if it has   
   > access to the full range of 8086 instructions rather   
   > than just the subset that work on 80386. I'm more   
   > interested in producing a future-proofed 16-bit   
   > executable than being "first and best" in 1988.   
      
   Well, if you have C source, then there is obvious way   
   to get good speed: recompile for newer machine.   
   Note that fancy "binary translation" schemes claim   
   speed comparable to native speed.  Even less fancy   
   schemes should be not much worse than 3 times slower   
   compared to native.  Your scheme for huge model   
   programs is likely to lead to much more significant   
   slowdown.   
      
   BTW: Forth threaded code scheme leads to speed loss   
   2-4 times compared to machine code, is quite easy to   
   implement and "interpreter" is tiny.   
      
   OTOH politicians and religous leaders understand quite   
   well that ideological purity is more important than real   
   world performance...   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)