muta...@gmail.com  wrote:   
   > 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.   
      
   OS call to get segment shift?  That is horribly inefficient   
   if you do this for every memory access.  And if not then   
   question where you store segment shift is back.   
      
   AFAICS it would be cheaper to offer Basic-like PEEK and POKE   
   system calls...   
      
   > 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.   
      
   I am not sure if compilers supported this, but single function   
   bigger that 64k is valid once you allow more than 64k code.   
   Compiler can use any mixture of near and far jumps inside.   
      
   > > > > 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.   
      
   It is _one_ of conditions to distinguish VM.  Note that   
   in 64-bit mode real mode programs are no longer supported   
   (you can run them using a VM).  Windows 10 probaly broken   
   them by not providing VM.  More to the point: Windows   
   (or Linux) provide a VM in a sense that some operations   
   cause OS to do something special.  But as long as you   
   stay with normal (unpriviledged) instructions behaviour   
   is as defined by hardware.  You effectively create new   
   instruction set, different of hardware instruction set.   
   Some instruction sequences which are valid on real   
   hardware will fail, OTOH some instruction sequences   
   will get new meaning.  Those two properties means you   
   have new instruction set which is distinguishing feature   
   of VM.  Your VM has a lot of similarity to 8086 and   
   your implementation will be simpler than many other VM.   
   But it is still a VM.   
      
   BTW: In the spirit you idea has some similarity to   
   NACL project at Google.  Google idea was to forbid   
   some 386 instruction sequences.  When forbidden   
   instruction sequences were absent then (according   
   to Google folks) there was no way to execute something   
   which was not code or say overwite return address on   
   the stack.  Idea was that Web browser could check   
   that rules are followed and then safely execute   
   downloaded code in the same address space as brower,   
   without risk of malicious behaviour from downloaded   
   code.  This approch was consider to be a VM, build   
   using 386 instructions, but one had to compile   
   programs in special way (otherwise rules would be   
   broken) and one get new properties (safety warranty).   
      
   > > 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?   
      
   In PM16 you do not need prefixes, so this is smallest   
   issue.  Other are mor significant.   
      
   > > > > 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.   
      
   So you assume "typical" MSDOS executable.  Some MSDOS compiler   
   generated self-relocating executables (relocation was done   
   by compiler generated stub).  And when you speak about 8086   
   executables, than absolute executable is valid.  Such executable   
   could work on PC without an OS.  Or under MSDOS as long as   
   required memory area was free.   
      
   > 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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)