From: muta...@gmail.com   
      
   On Friday, July 16, 2021 at 12:36:20 PM UTC+10, anti...@math.uni.wroc.pl wrote:   
      
   > > 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.   
      
   The executable needs to do this once at startup. Any   
   executable that uses huge pointers. ie mainly huge   
   memory model programs, which are rare. So rare in   
   fact that Turbo C++ doesn't even generate the   
   required assembler code. Watcom does though.   
      
   The result of the OS call can then be saved in global   
   variables for use by a C runtime library provided that   
   works with a suitable compiler like Watcom.   
      
   > And if not then   
   > question where you store segment shift is back.   
      
   I don't understand that question.   
      
   > AFAICS it would be cheaper to offer Basic-like PEEK and POKE   
   > system calls...   
      
   No, it is a minor change to existing huge pointer   
   manipulation. You just access a couple of global   
   variables whenever you normalize the pointer   
   instead of hardcoding the number "4".   
      
   > > 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.   
      
   Ok, if you are mixing near and far code pointers,   
   in a single function that exceeds 64k, you will   
   indeed exceed the ability of the OS to load that   
   on a non-16-byte boundary.   
      
   So that won't be supported.   
      
   > > > > > 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.   
      
   Not by the above definition. First of all, I'm not providing   
   a VM at all. I'm providing an operating system and   
   applications. Both of which are pretty simple. You can't   
   make them very much simpler. There is no virtual hardware,   
   no instruction interpretation. No new instructions. All   
   applications will comprise of a set of instructions that   
   are common to both 8086 and 80386. Like mov ax, bx   
      
   There's nothing virtual about that. And there's nothing   
   machine about that. I won't even bother to activate   
   virtual memory via CR3, nevermind an entire virtual machine.   
      
   > 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 can call a cat a dog if you want, but it's still a cat.   
      
   That's not a VM. Using a subset of available CPU   
   instructions is not a VM. It's neither virtual, nor a   
   machine. It's a SUBSET. When you compile a C   
   program with perhaps a -mach=486 option when you are   
   using a Pentium, it will restrict itself to 486 instructions   
   to be generated too. That's not a VM. It's a simple   
   application that runs on the 80486 and above.   
      
   > > > 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.   
      
   Ok. But I'm more interested in PM32. Why not take it   
   to the max?   
      
   > > 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.   
      
   Those things will not be supported. I'm not trying to solve   
   the entire world's problems in one hit. I'm trying to create   
   a set of rules for anyone who wants to future-proof their   
   16-bit 8086 applications.   
      
   If your particular application can't live within the rules, then   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)