Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!spool.mu.edu!uunet!munnari.oz.au!metro!macuni!sunb!ifarqhar
From: ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar)
Newsgroups: comp.sys.amiga.emulations
Subject: Re: Emulator Mechanics (sorry long post)
Message-ID: <1304@macuni.mqcc.mq.oz>
Date: 6 Mar 91 13:52:25 GMT
References: <4992@mindlink.UUCP> <1991Mar6.010141.5905@mintaka.lcs.mit.edu> <1303@macuni.mqcc.mq.oz>
Sender: news@macuni.mqcc.mq.oz
Organization: Macquarie University, Sydney, Australia.
Lines: 42

An idea about code compilation, rather than interpretation.

If you assume that a program does not employ self-modifying code, this
may not be nearly as had as it first appears (I am not saying that it is
trivial, just not too bad.)  This assumption can be made if the program
runs out of ROM, and also in 99% of non-ROM cases.

The problems of compiling code for one CPU into that for another are
fairly easy, but a major problem occurs when table-driven code is
employed (common.)

What I am suggesting is this.  It is reasonably elegant, and quite
simple to perform:

Store the loaded memory image of the original program as well as the
compiled code.  For every instruction in this image, a pointer to the
compiled code is generated indicating where the corresponding code
actually is.  As the program executes, the working store is this memory
image, and if a piece of data is read, it can be dealt with normally.
However, if a program attempt to jump, branch or call a location using
data loaded (as would happen with a table), then the corresponding
location can be determined and the correct code called.

This has a high memory overhead (3-5 times original image size *plus*
compiled code).

I am sure that there is a more memory-effective way of doing this by
identifying such tables during the compile, but it seems a difficult
problem.  Has anyone got any better solutions?

BTW, an idea for semi-compiled code.  Have two branches for every location,
and simulate the machine that way.  Reading an opcode calls the
appropriate opcode handler, writing it calls a reevaluation routine that
changes the pointers for the two locations.  System and special
locations are handled similarly.  This may actually be a quite
reasonable solution, as inelegant as it first sounds.

--
Ian Farquhar                      Phone : + 61 2 805-9400
Office of Computing Services      Fax   : + 61 2 805-7433
Macquarie University  NSW  2109   Also  : + 61 2 805-7420
Australia                         EMail : ifarqhar@suna.mqcc.mq.oz.au