Re: duplicate ops (Re: updated assembler)


"wolfgang kern" <nowhere@xxxxxxxxxxx> wrote in message
news:f1d6hf$tfp$1@xxxxxxxxxxxxxxxxxxxxxxxx

"cr88192" wrote:

[HW-drivers][SMC][...]

theoretically MS could do it for their own OS and drivers,
but they don't even do this much.
I'm afraid M$-OS doesn't have the slightest clue of how and why...

they don't need to know how the driver works. that is what the kernel
stub would be for, ie, to allow it to interact at the level of the API
(WDM,NDIS, ...).

Yes, a 'simple' rewrite of the NTOS64kernel could manage all this. :)


yeah.



I think it works similar already, all exception and IRQ-handling
have to run in ring0, so there will occure a task-switch anyway.

was thinking all this would run in the same task as the main kernel, and
also ring-0. this option avoids needing a seperate task.

Right but application code is usually active and may be interrupted often,
and this causes all the back and forward CPL transitions.


well, I am saying that a full emulator or translator is kept within the
kernel.
potentially, it could be loaded as a driver (serving a purpose similar to
ndiswrapper in linux).



[code converters...]
this would be much faster, if albeit much more complicated than a
simpler interpreter-based emulator.

I have to think about this idea in more detail ...
at the moment I cannot imagine this to be faster.

well, though not exactly the same, I have had some level of experience
writing both interpreters and compilers.
though it may seem dubious (all these extra indirections and funky
operations), one needs to remember just how much slower an interpreter is
(where each individual opcode is decoded, dispatched, and simulated).

Perhaps we talk about several things at the same time ? :)


maybe.
whether a pure interpreter is implemented, or if compiled to native code (in
one of any number of possible forms) would be an implementation issue.


One step would be to convert existing drivers to become 64-bit code,
(for the fastest performing solution).
Then we could emulate an 32-bit OS while in long mode for IRQs and HW,
(here I got my doubts about timing needs and messaging).
Finally we could just patch the 64-bit OS to perform all HW-related
stuff as 32-bit tasks.
(not the fastest and again the messaging problem)


64-bit drivers: that is the problem we have now, the OEMs are simply not
bothering at this point...

I am not saying we need seperate 32-bit tasks, but that a translator, may be
able to avoid all this, at some cost to raw performance.

but, with a translator like I am imagining, the slowdown should be probably
< 5x, which should be fast enough:
even a fairly fast interpreter would have an overhead of at least 15x, or
more...

as for interrupts, this is a slight issue.
because a VM state is needed, likely the interrupt handlers would need to be
wrapped, and the state is set up again, prior to transferring back to the
simulated 32-bit state.

I will assume that setting up the interrupt handlers is done by a kernel
function, so a wrapper of this sort would be fairly easy.


[about SMC]
I think a converter should keep all funtionality including SMC.
An emulation of SMC will be possible (AFAIU as you desribed),
but may cost too much time for fast acting hardware.


maybe.

I figured more recently, that since we are only simulating a small piece of
(presumably relocatable) code, we only really need to allow such a table for
"executable" memory, and not a full 4GB address space. this leads to a much
smaller array.


[side talk..]
I think I need a newer motherboard.
my computer has generally poor stability when in long mode...
linux works, but it still freezes sometimes.

Sounds like a intermittance bug, have you tried to reassemble
(unplug/reconnect everything)? Sometimes just one never recogised
tiny hair may spoil all the game.


dunno, I have swapped out pretty much all my hardware in trying to resolve
these issues.

dunno, any one else have issues with the NForce3 150 or 250?...

I have tried running mem testers like memtest86 and the ms memory tester,
but they don't find anything. my comp has 2.5GB ram.

just, for whatever reason, it works just fine 32-bit mode, but long mode
goes completely bug-happy (and typically even after "soft resets" via the
reset button, it will freeze in the bios or during bootup).

there is no "cool down" period, ie, I can turn off the power and boot it up
immediately and it works fine.


but then, I would need all these newer parts (newer memory, a PCI-E video
card vs. the current AGP one, ...).

I still haven't got my desired 200MHz AGP board, perhaps next X-mas..? :)


yeah...

newer boards seem to demand PCI-E cards afaik.


__
wolfgang



.