Re: duplicate ops (Re: updated assembler)


"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 any
newer HW works, so it will need complete decoded structures and
event messages in the M$-format created by the HW-drivers.
A HW-driver contains two main sections:
the IRQ-handler
(should respond to HW as of immediate and just message to the kernel)
the event handler
(react to or ignore the message, and may also reconfigure the HW)


this is only assuming that there were some major problem trying to set up
a > proxy-kernel in a specialized task (now, we would have a driver sharing
a
stub proxy, but otherwise communicating directly with the main kernel...).

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



of course, note that my idea is that it would be recompiled into a
synthetic address space, for 64 bit, likely having:

a 4GB simulated address space.
a 16GB or 32GB sparse array, potentially serving for jump handling (a
simple, but direct approach, of containing a pointer for every possible
address byte). more memory-efficient would be to use a hash, tree, or some
other structure (slower), but a 64-bit OS should have no problem with
mmaps of this size (the reason being that a huge array can be accessed
faster than a tree or hash).

where is this 32 GB block, virtual RAM on the HD ?

this would have a greater value for allowing SMC, since the backing
structure (aka: converted code) would tend to change, and so direct jumps
within the converted code would be a problem.

another condition would be to trap and handle unconverted code.
the state needed for all this would likely be kept in the extended GPRs.

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.

however, on x86-64 this shouldn't be needed. more likely this would be
needed if going over, ie, to something like PPC.

I think apple used vaguely similar for running PPC software on x86.

Ok.

[vista on AMD64] I'm happy for not gone for it.

__
wolfgang



.