Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!zaphod.mps.ohio-state.edu!van-bc!rsoft!mindlink!a547
From: Chris_Johnsen@mindlink.UUCP (Chris Johnsen)
Newsgroups: comp.sys.amiga.emulations
Subject: Emulator Mechanics [Transpiler]
Message-ID: <5097@mindlink.UUCP>
Date: 10 Mar 91 17:54:43 GMT
Organization: MIND LINK! - British Columbia, Canada
Lines: 150


        Thank you all for the valued input into this discussion to date,  both
pro and con.  I must say I find it very stimulating.

        When discussing this form platform porting translator/compiler  with
anyone, I find the need for a short word to use.  In a humble attempt  to coin
a descriptive phrase, may I suggest transpiler?
Charlie Gibbs (Charlie_Gibbs@mindlink.UUCP) Jean-Noel Moyne (jnmoyne@lbl.gov)
Dave Clemans (dclemans@mentorg.com) Dwight Hubbard (uunet.uu.net!easy!lron)
Pete Ashdown (pashdown@javelin.es.com) Jyrki Kuoppala (jkp@cs.HUT.FI) confirm
that, indeed some research and even program development has been done in this
direction.

Eddy Carroll (ecarroll@maths.tcd.ie) has written such a transpiler, as a last
year project, with some success, some reservations.

Chris Gray (cg@ami-cg.UUCP) suggests that the most practicable route to
desinging a viable transpiler would be to make it interactive.  BTW Chris, I
very much enjoyed your compiler articles in the Amiga Transactor.

Ray Cromwell (rjc@pogo.ai.mit.edu) suggested an interesting thought, a sort of
Usenetware combined effort for development, he also thinks reasonable execution
speed can be achieved.

        Those are what I percieve to be the ideas supporting the transpiler
concept.  The statements of contrary considerations are more voluminous. These
appear to fall into a number of categories.
          o  Self-modifying code
          o  Separating code from data
          o  Determining video access
          o  Stack handling
          o  Jump table problems
          o  Handling overlay segments
Ian Farquhar (ifarqhar@sunb.mqcc.mq.oz.au) suggested that a compiled module  be
run concurrent with an emulator type section so that in some parallel  way, any
references within the source executable, which would also be loaded during
runtime of the emulation, could be validated.  It could be argued that this
should be placed on the pro side of the ledger, but the incurred overhead
during execution would be large.  This function, I had imagined initially,
would be carried out during the transpiler phase and not attached to, or
burdening, the runtime execution.

Brad Pepers (pepers@enme1.ucalgary.ca) Jyrki Kuoppala (jkp@cs.HUT.FI)  Jonathan
David Abbey (jonabbey@cs.utexas.edu) were somewhat concerned with
self-modifying code.  There were a significant number of voices that dismissed
this concern.  Personally, I wouldn't worry about it.  If a particular program
used this technique, for whatever reason, I would accept the fact that not all
programs can be transpiled.

Ian Farquhar (ifarqhar@sunb.mqcc.mq.oz.au) Dave Clemans (dclemans@mentorg.com)
Sullivan (Radagast@cup.portal.com) Jean-Noel Moyne (jnmoyne@lbl.gov)  Chris
Gray (cg@ami-cg.UUCP) raised concerns about determining code from bytes of the
data persuation.  This is what I had thought would be the biggest stumbling
block. I hadn't thought there would be so many others. :-)  It's great to hear
how how long the road is before you begin the journey.

Udi Finkel (finkel@TAURUS.BITNET) Eddy Carroll (ecarroll@maths.tcd.ie) are
concerned about determining when the access to memory is video ram.  This, I
believe, can be solved, if it is dealt with in the same manner as the code/data
resolution.  Please read on.

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.

Chris Gray (cg@ami-cg.UUCP) Eddy Carroll (ecarroll@maths.tcd.ie) raised the
problem of coping with jump or branch tables properly.  Weighty point. This I
would describe as a grey area between code and data where it may be actual jump
instructions, or a table of label locations, the code to be  emulated
calculating an offset into it.  This must be handled in a similar fashion to
the code/data recognition problem.

Dave Clemans (dclemans@mentorg.com) Kurt Tappe (JKT100@psuvm.psu.edu) Jonathan
David Abbey (jonabbey@cs.utexas.edu) were concerned with the  handling of
overlay segments.  This bothers me too.  With the Amiga, it  would be possible
to either use overlays, in the case of very large programs,  or convert to
all-in-one programs by consolidating the overlay hunks.  The  main problem is
determining that overlays are employed, loading them and  transpiling.  This is
closely related to the code/data determination problem.

Dwight Hubbard (uunet.uu.net!easy!lron) suggest that this would work, kind of
like DSM.  I have DSM and must say it was a model for me when contemplating
this idea.  Chris Gray (cg@ami-cg.UUCP) believes that an  interactive compiler
holds some promise.  In one of my initial messages to  Charlie Gibbs I
entertained the reality of having to fall back on human  intervention, at the
transpiler output source code level.  This would be  determined at runtime,
when the emulated program failed to operate correctly  or at all.  A programmer
would be required to fix the problem.

        What I interpert the huge human parallel processor the net represents,
to be saying, is that human intervention must be employed.  My only reservation
in this regard is that there are interperative emulators that run a wide
variety of software on-the-fly.  To me, this feat is more difficult than a
transpiler, which can ruminate over the executable for as long as say a
raytracer.

        To incorporate the above concepts, and arrive at a workable resolution,
what is required is an expert system, probably requiring a resident expert (not
software, though brain matter is soft), to resolve the code/data, video access,
jump/branch table and overlay problems.  I don't suppose that the average
emulator user is prepared to deal with or even understand the problems we have
been discussing.  I don't think it would be worthwhile writing a transpiler
unless it could be made to work in some standalone fashion.  Feed it the
source executable and out pops the Amiga version.

        Mind shifting stage left...

        I have a suggestion, since it is not considered practicable to write a
transpiler that will work unassisted, that may resolve the percieved problems
using some of the concepts from this message thread.

        First, an off-the-wall analogy.  Here he goes again. :-)

        Consider a desirable program, running on another platform, useful to
an Amiga user, but with a very large dongle attached.  This useful program must
be run on the dongle in fact.  This is inconvient.  What do I do if I loose my
dongle?  I propose you think of this as a form of copy protection  for a
moment, obstructiing the Amiga owner, who also owns a program that runs  on
another platform.  Follow me so far?  The legitimate program for the  other
platform cannot be used on the favoured, Amiga machine, so it needs  to be
decopy-protected.  What do you use if you wish to backup and/or deprotect
software?  A copier program.  Most copiers can be employed by users who have
little knowledge of copy protection, yet they succeed in making the copy.  The
more difficult protection schemes require "brain files" which are written by
experts to achieve this end.  End of transpiler/copy-protection analogy.

        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?

csj

 No really officer, I wasn't speeding, just keeping a safe distance in front of
the car behind me!

Usenet: a542@mindlink.UUCP Phone: (604)853-5426 FAX: (604)854-8104