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 [Transpiler]
Message-ID: <1991Mar12.102921.23420@maths.tcd.ie>
Date: 12 Mar 91 10:29:21 GMT
References: <5097@mindlink.UUCP>
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Lines: 69

In article <5097@mindlink.UUCP> Chris_Johnsen@mindlink.UUCP (Chris Johnsen)
writes:
>Eddy Carroll (ecarroll@maths.tcd.ie) points out problems with processor stack
>handling.  How did you resolve this with the transpiler you developed?  It
>occurs to me that every emulator whether it be a transpiler, or interpretive
>type must handle the stack properly.  To me, it would be more difficult to
>approach this problem if I were writting an emulator, as opposed to a
>transpiler, as less executable size constraints would inhibit producing an
>intelligent stack handler.  On the 68000 the stack would be handled as
>word/longword only.  Any bytewise stack functions within the  source executable
>would be transpiled into wordwise handling.  A problem, but surmountable.

Well, there were a number of things in my version I was hoping to implement
that I didn't have time to; one of these was the stack handling you mention
above. My solution would have been to constantly monitor stack usage while
a function is being traced (i.e. what is pushed on/popped off). Whenever
the current function called another function, a record was made for this
second function listing the state of the stack at that time (i.e., what sort
of parameters you might expect to find on it). This information could then be
used while transpiling the second function, to make sure the right items on
the stack were accessed. This still leaves a problem with functions like
printf() which can be called at different times with different parameters.

Another way of handling it would be to maintain a seperate stack for
pushing things onto. This would get around the problem of using the system
stack, but you would have to manually copy the PC to that stack everytime
you made a subroutine call. The end result would probably be more robust
though.

>        Take a basic transpiler, such as the one Eddy Carroll wrote, and add a
>toolkit.  The transpiler would do its best to translate and compile the source
>executable.  If this failed, an expert, not just the average user, would either
>run the transpiler in expert mode, or a debug tool from the toolkit, which
>would work through any problem areas.  The result of this would be an expert
>transpiler file.  The beauty of this approach is that any user could run the
>transpiler, given access to the expert file.  These expert files could be
>included with the release package and any new ones could be included in any
>updates or shared by conventional electronic means as PD.
>
>What do you think?

Interesting idea. On a smaller scale, I originally intended to include some
library recognition code so that, for example, a call to a Turbo C graphics
library function (assuming Turbo C has a graphics library) would be
recognised, and rather than translate the function an instruction at a
Time, the whole could be replaced by equivalent Amiga code (which might use
the blitter or whatever).

Elsewhere, you mentioned that it seemed more difficult to write an emulator
than a transpiler; I think you'll find you're mistaken. The difference is
roughly comparable to writing a language interpreter as opposed to a
compiler (except that the transpiler is even more difficult than a real
compiler because there are so few constraints on the input it has to deal
with).

In another message, you asked if I would be willing to share my efforts so
far with the rest of the world. Yes, certainly I would. I don't really
feel it's in a state ready for public consumption though, so I've no desire
to send it off to c.s.a. or Fred Fish. If anyone wants to play with it
though, I can mail out copies. It won't be much use to anyone not interested
in the source code though; as it stands, it gets bogged down too esaily to
transpile anything significant. (If anyone wants a quick'n'dirty 8086
disassembler on the other hand, it will do that quite well.)

Eddy
--
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