From: muta...@gmail.com   
      
   On Thursday, July 15, 2021 at 6:03:56 AM UTC+10, wolfgang kern wrote:   
      
   > my English is good enough to understand what you try to achieve.   
      
   It's not a question of good English skills. Native English   
   speakers often don't understand what I am proposing   
   either.   
      
   > but it seems you haven't got how segment descriptors are built   
   > and how segment selectors interact with the GDT.   
      
   Note that I have written an 80386 operating system, so   
   at some point I do get things, at least partially, but then   
   I forget them again (perhaps some mental deficiency),   
   which is why you had to make multiple corrections.   
      
   > 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?   
      
   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?   
      
   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:   
      
   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.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)