Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!tcdcs!maths.tcd.ie!ecarroll
From: ecarroll@maths.tcd.ie (Eddy Carroll)
Newsgroups: comp.sys.amiga.emulations
Subject: Re: Emulator Mechanics (sorry long post)
Message-ID: <1991Mar9.225807.26560@maths.tcd.ie>
Date: 9 Mar 91 22:58:07 GMT
References: <4992@mindlink.UUCP>
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Lines: 64

In article <4992@mindlink.UUCP> Chris_Johnsen@mindlink.UUCP (Chris Johnsen)
writes:
>
> [ Interesting discussion about a new sort of PC emulator ]

My final year project for college last year tackled exactly this problem, i.e.
given a PC executable file, produce an Amiga executable file which will
perform the same function. The end result worked, in a limited sort of way;
it was fairly easy for it to be misled by any program of reasonable size.

There are a few tricky problems that must be handled if you want to achieve
a good degree of success:

  o  Given the instruction MOV reg,VAL do you treat VAL as a constant value
     or as an offset to an address in one of the PC's segments? The 8086
     uses the same opcode for both cases, and it is far from easy to work out
     which meaning to use. It's important to get it right because in the
     translated program, all the constant values should remain the same
     but address offsets will be different.

  o  How do you handle jump tables? Most compilers implement switch/case
     statements with jump tables, but it is not always clear what the bounds
     of such tables are.

  o  On the PC, byte values can be pushed onto the stack as byte values. On
     the 68000, you can only push word values. You can see why this might be
     a problem if you consider a function accessing a parameter at an offset
     of 8 from the stack pointer. If the preceding parameters were four words,
     then this is okay. If they were two words and four bytes however, then
     the offset on the 68000 needs to be 12 to access the same data.

  o  Given that most major PC programs access the PC's video RAM directly
     for speed reasons, such accesses must be mapped to act equivalently
     on the Amiga. The problem is that the usual method for doing this is to
     set a segment register to point to the video RAM and then to access the
     RAM through this. The same register is likely used for for all sorts of
     other data access elsewhere in the program.

Of course, there are other problems too. The main thing I discovered during
the course of the project was that it's a lot harder to do translation than
it might first seem.

My program performs the translation in two passes. The first pass traces out
all possible paths through the PC code, building up a symbol table and
separating code from data as it goes. The second pass then walks sequentially
through the code, producing 68K assembly source code for each line. Certain
instructions generate macros instead of opcodes, which are later expanded
to calls to library functions. The resulting source is fed into Charlie's A68K
and then linked with a library that sets up a PC-like environment (custom
screen, ibm.font etc.) and handles the INT calls. The result is a standalone
executable file.

If anyone else has a shot at it, I'd be interested in seeing how it turns out.
Perhaps a more practical route to take is to produce a translator that can
take reasonably well written PC source code (say, C or assembly) and
automatically convert it to Amiga source code. If such a tool existed and
worked well, it might encourage more companies to port their products to the
Amiga.

In the meantime, back to IBem.
--
Eddy Carroll           ----* Genuine MUD Wizard  | "You haven't lived until
ADSPnet:  cbmuk!cbmuka!quartz!ecarroll           |    you've died in MUD!"
Internet: ecarroll@maths.tcd.ie                  |   -- Richard Bartle