can't say exactly...
but, before I wrote an interpreter for x86 (basically, like an emulator, but
it doesn't bother with faking the entire system).
but, in this case, I had basically used some logic from an assembler of mine
to essentially "disassemble" the machine code into a higher-level virtual
ISA (basically, it works like an assembler and compiler lower-end, but in
reverse). this allowed a slightly simpler model on which to base the
interpreter logic, rather than having do deal with all the issues of exact
opcode encodings and various instruction forms at the level of the
interpreter.
in a few cases, certain groups of opcodes are handled as single larger units
as well, ...
(I guess it is more common to use big nested-switch statements to write such
an interpreter, but I figured that this would be a painful experience, and
so I didn't do so).
actually, in the process I also noted that using linked-lists and
function-pointers for opcode dispatch was cheaper than using a switch
statement, and so this is how this interpreter is structured.
likely the harder part in writing a full system emulator would be simulating
all of the various pieces of hardware, ... which may be attached (as well as
re-implementing probably certain pieces of firmware/... which may be present
in the original machine), for which documentation may be sparse or absent,
...
or such...
----- Original Message -----
From: "Casey Ransberger" <[email protected]>
To: "Fundamentals of New Computing" <[email protected]>
Sent: Sunday, June 20, 2010 11:45 AM
Subject: [fonc] Reverse OMeta and Emulation
First, I'd like to apologize for my last message to this list. I had
intended to send it directly as a reply to Jecel's comments, but replied to
the whole list by accident. I wouldn't ordinarily waste bandwidth on idle
griping like that: mea culpa.
On to the topic of the subject line...
I've been thinking about learning computing history by doing.
Emulation is expensive (in human terms.) Emulators are very complex,
precision beasts. So many emulators are started and not finished, in part
because commercial applications can be limited (leaving developers
money-starved for their time,) and in part because the scope of the work is
fairly large.
An idea occurred to me: I was thinking about an example I'd seen from the
FONC literature about using OMeta to transform representations of various
"heights" ultimately into machine code, and I wondered: would it be possible
to use the limited reversibility aspect of OMeta to reduce the complexity of
an emulator by (to some extent?) translating machine code for one
architecture to another?
As I think it's fair to say that an emulator is a sort of virtual machine,
is there something to be learned about VM complexity or portability here
too?
Just a thought! :)
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
