muta...@gmail.com wrote:
> 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.
Fortunately you answered this question above: you store
segment shift in memory. Still, it would be intersting
to see machine code that you want for
p++;
where p is huge pointer (say of type char *). Note:
actual instructions, not some handwaving.
> > > > > > 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.
Well, one guy creater and "assember" that took S370 assembly
and emited 386 instructions. For this to work he need
"well behaved" programs and IIUC he did not handle endiannes
issue. I would not call his approch "natively executing
S370 binaries in 386". It was clearly a VM created by
instruction translation. For huge mode your apprach is
clearly to related.
Note that modern VM typically work by intruction translation
(Bochs and hercules are _not_ modern, QEMU is).
There is "no interpetation", only execution of translated
instructions.
> > 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 somewhat did not get that "virtual" means that there
are no real machine. Real 486 exist. The set of restructions
and capabilities you want for huge model did not exist on
any real machine.
> > > > 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?
You mean why not solve more non-problems? Using PM16 may
by too easy, but is was designed for compatibility with
real mode, in particular you get 16-bit address size and
16-bit operand size.
> > > > 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.
>
> > What about casts betwen data and function pointers? Formally
> > this is undefined in C90,
>
> Yes, for exactly this reason. Works fine today on the
> 8086. Breaks when you move to the 80386 in PM32.
Works fine in PM32 as long as you use "tiny" model, that is
no explicit segments, and all segment registers pointing to
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
