muta...@gmail.com wrote:
> On Friday, July 16, 2021 at 1:11:09 AM UTC+10, anti...@math.uni.wroc.pl
wrote:
>
> > Depends very much what "works" mean. Running unmodified
> > 86 binaries: AFAICS no.
>
> Do you mean running ALL unmodified 8086 binaries?
Yes.
> If so, you are correct.
>
> 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.
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.
Even for single mode binares there are problems (see
below).
> So. It depends. Some 8086 binaries will work, some
> won't.
>
> 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.
> > 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. You need to recompile
specifically for your VM.
> > 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.
> > Hmm. On 86 multiply and divide take time comparable to tens
> > of simpler instructions. You also have problem of finding
> > place to keep your divisor. If you keep divisor in register,
> > that alone will blow up your 10% budget (losing a register on
> > 86 is closer to 20% drop in performace) and introduce seroius
> > incompatiblity with traditional 86 code. If you keep divisor in
> > memory there will be extra segment manipulations to fetch
> > divisor.
>
> I'm not worried at all about performance of huge memory
> model programs, which are the only ones that need to do
> the divide and multiply.
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.
> 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.
> 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.
> > 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. If you have small transitor budget, then
you naturally end up with something like 6502 (which
was not 16-bit, but you can naturally make 16-bit
variation) or Texas processor. 8086 is claimed to
have 27000 transitors, first RISC processors to
have 40000. So if you want high speed to computations
on medium transistor budget makes sense to switch to RISC
(you may have 16-bit RISC if you want). If you have disc,
then virtual memory makes a lot of sense, especially on
machines which have meg of few megs of memory.
Once you routinely have more than 64k program you need
32-bit pointers and it makes sense to switch to 32-bits.
> Ideally I can have EFFECTIVE 16-bit segment shifts
> and address an entire 4 GiB, but they didn't provide
> enough selectors for that, and I can only get 512
> MiB, so the equivalent of an 8086 with a 13-bit
> segment shift instead of a 4-bit segment shift.
That is your choice. You want single LDT. Note that
each program can have its own LDT and with per-program
LDT you can address much more memory. OTOH 286
segmentaion makes sense if you have a lot of programs,
each of them relatively small. By insisting on single
address space you throw out main intended use cases
for 286.
> > Note that fancy "binary translation" schemes claim
> > speed comparable to native speed. Even less fancy
> > schemes should be not much worse than 3 times slower
> > compared to native. Your scheme for huge model
> > programs is likely to lead to much more significant
> > slowdown.
>
> Huge memory model is rare - I'm not worried about that.
> Even if it is 3 times slower (the whole application). It
> would be good if other memory models ran at full speed
> though, but I don't know how many of the instructions
> disappear in PM32.
Even if huge model is rare on original 86 (I think that
huge pointers are used in may programs and saying "rare"
underestimates their use), it would be dominant mode on
machines having more memory. Why have more memory if you
can not have large array?
--
Waldek Hebisch
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
