Re: duplicate ops (Re: updated assembler)


"Wolfgang Kern" <nowhere@xxxxxxxxxxx> wrote in message
news:f17d9g$s4r$2@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 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)


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, ...).



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.


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.




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 ?


no, probably just mmaped (or equivalent).

it will be sparse, so likely only a few small portions of it will actually
be used (those actually containing executable code).

if the OS can do it, copy-on-right implicitly zeroed memory would be useful.


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.


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 simiulated).

at least on this, the inflation would be lesser (mostly, for example,
handling jumps via an array index, and likely handling code translation/SMC
via page-faults or similar).


however, in the past my compilers have typically worked more as translators
than emulators though (the way translation and caching was handled was a bit
different than I was imagining here...).


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.


maybe.

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

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


__
wolfgang





.

Relevant Pages

  • Re: Error handling
    ... Error handling code has got to be part of the normal flow control of the ... When the program runs out of resources like memory, disk space, printers ... to report them themselves. ... In some environments it is good to hide errors, for instance in a video game ...
    (comp.lang.c)
  • Re: C is too old? opinions?
    ... scheduling mechanism, memory handling methods, different memory ... asynchronous event handling, and high-resolution time handling. ...
    (comp.lang.c)
  • Re: Exception Handling in the kernel
    ... Just to be clear - there are some cases where you HAVE to use exception ... handling. ... For instance if you are directly accessing memory via a usermode ...
    (microsoft.public.development.device.drivers)
  • Re: Kernel: /dev/ram1 (rd.c) not releasing unused memory automatically any more?
    ... > ramdisk drivers request handling function and you will see! ... memory chunks of 1 MByte size does create "memory pressure", ... because this is a destructive measurement. ...
    (comp.os.linux.misc)
  • Re: Tips for speeding up parsing using libexpat
    ... If you're handling huge files, try using SAX-based processing when possible. ... If you need random access (which XSLT does, in general, though streaming XSLT remains something of a holy grail), make sure you're on a machine that is set up for efficient handling of large files -- lots of memory and efficient swapping -- and you may want to try different implementations ...
    (comp.text.xml)