From: muta...@gmail.com   
      
   On Friday, July 16, 2021 at 7:58:15 AM UTC+10, anti...@math.uni.wroc.pl wrote:   
      
   > > But all C-generated code, other than huge memory   
   > > model, doesn't manipulate the segment registers   
   > > as far as hardcoding a 4-bit shift.   
      
   > Well, it depends on details which you did not provide.   
   > If you reserve a register, then all programs, regardless   
   > of mode will be affected, basically in such case you   
   > need recompile with compiler respecting your convention.   
      
   No registers need to be reserved. The only thing that   
   an 8086 program needs to do is not assume that the   
   shift is 4 bits, and instead make an OS query to find   
   out a right-shift value (or divide) and a left-shift value   
   (or multiply) if they wish to *modify* a segment   
   register with a value that was not set at load time.   
      
   And the only reason they would need to do this is   
   if they are exceeding 64k of memory with a single   
   pointer and thus need to normalize the pointer.   
      
   Well, there are other reasons (like setting the   
   segment to x'b800'), but that is non-C90   
   code. At the moment I am trying to support C90   
   code.   
      
   > Above you claim that that only huge mode will be   
   > affected. First, AFAICS most existing binaries are   
   > mixed mode, that is use mixture of near and far pointers.   
      
   Far pointers are not a problem. Only huge pointers   
   are a problem.   
      
   > > I can ensure that all of my C90-compliant programs   
   > > work, since even in huge memory model I have control   
   > > of the C library with PDPCLIB.   
      
   > Well, you need cooperation of compiler and linker too.   
      
   The compilers are all generating correct code already,   
   other than the failure to emit x'66' to prepare themselves   
   for the 80386.   
      
   The linker does indeed need to ensure that no individual   
   function is split over a 64k boundary.   
      
   > > > You are creating a virtual machine   
   > >   
   > > Why are you calling it a virtual machine??? By what   
   > > definition? Because it doesn't use the full capability   
   > > of the 80386?   
      
   > Because valid binaries will be broken.   
      
   That's a strange definition of a VM. Windows 10 has   
   broken all of my 8086 binaries. It's not a VM.   
      
   > You need to recompile specifically for your VM.   
      
   I compile for an 8086. The 8086 is not a VM.   
   My executables are pure 8086 code unless you   
   count the x'66' no-op. Huge memory model will   
   use an INT 21H that wasn't provided by MSDOS,   
   to get a right-shift and left-shift, but that doesn't   
   create a VM either.   
      
   And if you insist on counting the x'66' as "aha,   
   VM", maybe I can simply make the C compiler not   
   generate the instructions that need an x'66' to   
   work in PM32. At this stage I don't know what   
   happens if those instructions are eliminated. Will   
   I still have a Turing machine?   
      
   > > > which with little care (and assuming divisor 16) will run the   
   > > > same binary on 86 and 386.   
   > >   
   > > Why am I assuming a divisor of 16?   
      
   > Let us see. What will be machine code for skeleton program   
   > below:   
   >   
   > int f1(void) {   
   > return 1;   
   > }   
   >   
   > /* Other, possibly long code */   
   >   
   > int f2(void) {   
   > return 2;   
   > }   
   >   
   > /* More other code */   
   >   
   > int f3(void) {   
   > return (f1() + f2());   
   > }   
   >   
   > Of course, most interesting is code for 'f3', in particular how   
   > you represent addresses of functions and what sequence you use   
   > for calls. "possibly long code" means that you should be   
   > prepared to handle programs with more than 1 segment of code.   
      
   You're talking about medium and large memory model programs.   
      
   Those have far code pointers.   
      
   When f3() calls f1(), which may be in a different segment, it   
   does it by doing a far call. The segment that is used in that   
   call is indeed set by the linker, and indeed, is based on   
   segments being 4-bit shifts. But that segment gets altered   
   by the OS when it is loaded (relocated). The algorithm on   
   MSDOS is very simple - just add the load point's segment.   
      
   My proposal is that when the binary is loaded by PDOS/86   
   running in PM32, that the segments will be radically   
   different. They will in fact all be selectors. So if you have   
   an 8086 binary that has say f1 at 3000:0000 and f2 at   
   3005:0000 then in PM32 with 512 MiB (or more, but   
   not accessible) memory so we use 16-bit shifts, the   
   segment/selector of both f1 and f2 will be adjusted to   
   the same, because they both fit within a common   
   64k base (x'30000'). f2 will then need the *offset*   
   adjusted to x'0050'. On the 8086 the offset is never   
   adjusted, but on 80386 I will need the offset adjusted.   
      
   And yes, this may mean another linker change/format   
   to support offsets being adjusted. I'm not sure if there   
   is sufficient information already in current MSDOS   
   executables to guess where the offset is.   
      
   > Well, it is for you to justify that your apprach will work   
   > in other modes. Note that to run program as PM16 normally   
   > you will at least relink it.   
      
   I accept that a relink may be required.   
      
   > > That's the price you pay when you exceed 64k in a single   
   > > data structure on a machine that was only designed to   
   > > run 16-bit programs. There comes a point when you're   
   > > supposed to be recompiling as 32-bit. If you insist on   
   > > maintaining 8086 compatibility, then you will take a   
   > > performance hit.   
      
   > Sure, I would recompile instead to inventing strange schemmas.   
      
   Sure. If you're happy to move from 16-bit programming   
   to 32-bit programming, then none of this is relevant.   
      
   But what would you have done in 1985?   
      
   Also, this is a generic problem. Coding 32-bit programs   
   accessing more than 4 GiB of memory have the same   
   problem.   
      
   And from the application's point of view, there is nothing   
   strange about this. It's absolutely stock-standard 8086   
   code unless you count the dead x'66' and the fact that   
   the 8086 OS vendor insists that you stop hardcoding   
   the number "4" in your huge pointers and instead call   
   the OS at startup time to get the 2 values you need.   
      
   And the linker format that includes offset adjustments   
   when those numbers seemingly never get modified,   
   which in fact, is true for PDOS/86 running on an 8086.   
      
   > > All other memory models will run full speed, other than   
   > > any x'66' that are being skipped.   
      
   > ATM you say this. But you did not say how, in particular   
   > if you use "segment shift" different than 4.   
      
   I have laid out my proposal. If there is a specific thing   
   that I have missed, I can address that if you tell me   
   what it is.   
      
   > > > Well, if you have C source, then there is obvious way   
   > > > to get good speed: recompile for newer machine.   
   > >   
   > > Sure. But I'm trying to construct the best 16-bit   
   > > machine at the moment, using existing tools.   
      
   > You are setting strange constraints and getting strange   
   > results.   
      
   The 8086 set the constraints. I'm just working within   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)