Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!easy!lron
From: easy!lron@uunet.uu.net (Dwight Hubbard)
Newsgroups: comp.sys.amiga.emulations
Subject: Re: Emulator Mechanics (sorry long post)
Message-ID: <18c8b64f.ARN0eba@easy.hiam.com>
Date: 6 Mar 91 12:57:35 GMT
References: <4992@mindlink.UUCP>
Reply-To: easy!lron@uunet.uu.net
Followup-To: comp.sys.amiga.emulations
Organization: You must be talking about someone else.
Lines: 141

In article <4992@mindlink.UUCP>, Chris Johnsen writes:

>      Another approach I've heard of is to "compile" the code to be emulated
> into native machine code.  This would involve a front-end program which would
> read the target machine's program and analyze the instructions.  For instance,
> if the "compiler" detects an instruction that does a move between two of the
> emulated machine's registers, it would simply generate a move instruction in
> the emulating machine's code.  It could generate either a translated assembly
> language source file or a machine-language file ready to load into the
> emulating machine.  This would require the "compilation" process to be run once
> on the program to be emulated, and you'd then run the output of this
> "compiler."  There are special tricks to consider here, such as resolving
> addresses - you couldn't just copy the memory addresses across because the
> emulated routines would likely be a different size.  It might be easier to
> generate a label (e.g. Axxxx where xxxx is the hex address in question) in an
> assembly source file and let the emulating machine's assembler sort it all out.

I think I read about a company that had something like this for Unix about a
year ago but I don't remeber all that much.  Handling interupts looks like
it would be harder with this approach.

> Your second message hit the nail on the head!  I got bogged down at about the
> level you describe in your first message.  Lots of details to be sought and
> worked out.  Gee, I'm really not even available to code another program just
> yet anyway.  I was giving the whole concept a rest when, what I  thought of,
> kind of sideways (lazy minds tend to look for an easier way  around an
> obstacle, sometimes unconsciously, even though this can lead to  harder, though
> more elegant solutions to problems), was to read the opcodes from the "source
> executable" of the emulated machine, producing an assembly listing of the
> program.  This I imagine would be a two pass process, sort of like a C
> compiler, followed by an assembler's two passes, and finished off with a
> linker.

Basic concept sounds good, kinda sounds like the DSM program except it would
convert another machines machine code to 68000 assembly...

> I thought that, if the compiler was "intelligent" enough, the output, though
> likely larger, would be much faster than the common "interpreter type
> emulator".  I had never heard of such an idea and since there are none out
> there, wanted to discuss this with you.  I have developed the idea no further
> than this in essence.

It sounds like it would be faster.

> I did think of a few other considerations however.  If one could, indeed,
> compile an executable image of say Lotus 123 from the IBM into a program which,
> on a base Amiga, could run at half speed, or on a A2500 or A3000 at twice the
> speed, it would be a viable alternative, besides being a neat toy.  However,
> the standalone program generated would likely infringe on the copyright of
> Lotus because the Amiga executable would actually be Lotus 123.  Take
> WordPerfect for instance.  The latest version available is 4.1 or just a
> micro-point higher, no problem, get hold of the IBM version 5.1, I believe it
> is, and compile it and you have something some other people are wailing for. Of
> course the rebuttal (I can hear you thinking?) is that, if a person owns
> WordPerfect he has an inalienable right to run it. Run it on an IBM.  Run it on
> a clone.  Run it through an Amiga compiler.  You know, if it's for personal
> use, etc.

Well, the output of the program would most likely fall under the copyright of
the original as a derivitave work, however the program to convert wouldn't be
illegal as it modifies the original program much like many disk copiers will
modify a program to remove manual protection and such.

> The compiler could generate C statements so that you could take advantage  of
> the advancements in technology in the compiler, assembler and linker,  without
> having to deal, directly, with those parts of the system.  I know  this would
> make the compiler operation more unwieldy.  More operations,  therefore it
> would take longer, but theoretically the source is bugless,  so you would
> expect the output of this "emulation compiler" to either  succeed or fail.
> You'd run the emulator on the program only once.  The  beauty of producing
> assembler (C would be better here), is that if it  didn't work first time, a
> programmer type could patch it up in source and get it running.  I'm really
> intrigued by this idea.  Where did you hear about it, do you remember?

I like the idea as well, although I think 'C' is pretty much out.

> My knee-jerk reaction initially was to file the idea, but then I got to
> wondering why no one had done it.  There were many emulators out there for
> various source machines.  Why were none of them compilers?  Another idea I had
> was to contact the dude in Oz (or is he a Kiwi?) that wrote IBeM.  He already
> has the emulation working except for the parallel and serial ports. It would
> appear that he reads the IBM object code, deciphers it and runs a routine, or
> simply does a MOVE using an opcode lookup table, as you suggest; an
> interpreter.  If he instead simply wrote out an instruction in ASCII to do the
> call or move instead, using a shared library of his emulation routines, he'd
> basically have it.  The end user would also have to have an assembler or C
> compiler, however.  This type of approach has got to produce faster emulation,
> if it is possible.  I believe it to be.

Hmm, I think it might take a little more work at least initially but imagine
what could be done if the software were to recognize standard Windows 3.0
calls as well as the normal bios calls and map them to Intuition calls
instead...  Gee, maybe we could get Ami Professional or Word to run.

>      I can't remember where I first heard of the idea.  The converted code
> won't necessarily be smaller than the original, depending on the relative sizes
> of corresponding machine instructions on both machines.  However, if you could
> make the compiler really smart it might be able to recognize certain sequences
> of instructions and replace them by sequences designed to accomplish the same
> thing more efficiently.  For instance, since the 8080 doesn't have a multiply
> instruction it needs to fake it with a bunch of adds and shifts.  A smart
> compiler, if it could recognize such a routine, could replace it with a single
> 68000 multiply instruction and see huge savings.

Hmm, I'm sure there are many more optimizations that can be had as well.  The
big thing is to generate inline code to keep speed up instead of using
subroutines.

>      I'd stay away from calling subroutines; the overhead could kill you.

Looks like I was one comment to high.

>      The copyright issue could be a sticky one, although I can't see any
> problems if you run the converter on your own copy of the emulated software and
> don't try to sell the result.  It would no doubt be classified as a "derivative
> work".
>
>      Perhaps it might be interesting to throw this discussion out to Usenet. It
> won't be a trivial job, which is probably why we haven't seen it done
> elsewhere.  Remember that a straight machine-code emulation duplicates all the
> register fiddling that is required by the target machine's architecture (and
> the 80x86 family needs a LOT of register fiddling).  This code is replaced by
> the 680x0's own internal fiddling if you're re-compiling source code.  One way
> of looking at it is to decompile the original machine code, then recompile it
> for the new machine.

The big problem is going to be emulating the hardware, like using the
Graphics.library text routine to print a character if someone goes and changes
b000 0000(mono) b800 0000 (color) when the system is in text mode, not to
mention recoginzing when to display text and when to display graphics.
Emulating the chips other than the CPU is going to be the problem unless
all you want to run is stuff that just makes bios calls (the mac would
probably be easier, but then I don't know that much about the Mac so I
could be wrong)

All and all it sounds like a good idea, if I wasn't so busy I would even be
interested in getting things started.  Maybe in a month or so.
----------------------------------------------------------------------
-Dwight Hubbard             USENET  : easy!lron@uunet.uu.net         -
-Kaneohe, Hawaii            CFR     : 31:910/101 (Dwight Hubbard)    -
----------------------------------------------------------------------