Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!dog.ee.lbl.gov!lbl.gov!jnmoyne
From: jnmoyne@lbl.gov (Jean-Noel MOYNE)
Newsgroups: comp.sys.amiga.emulations
Subject: Re: Emulator Mechanics [Transpiler]
Message-ID: <10882@dog.ee.lbl.gov>
Date: 13 Mar 91 01:17:45 GMT
References: <5097@mindlink.UUCP>
Organization: Lawrence Berkeley Laboratory
Lines: 33
X-Local-Date: Tue, 12 Mar 91 17:17:46 PST


             Good resume of the current situation !! 

As for a name, Transpiler sounds fine to me (and has a "Transp..er" flavor 
too (-:).

I also think this "brain file" system is the best way. I think the 
Video-RAM access is one of the tricky points. Since the position of this 
RAM is the same on all the PC Clones, it is true that even very clean 
programs do direct access to this RAM for speed, and that you're not in an 
Emulator that will trap these moves. Of course, the use of a MMU may be a 
solution, but when you're running a transpilled (is that the right 
spelling, sorry I'm still learning English (-:), you shouldn't rely on 
catching memory exceptions like that, especially on the Amiga.

          As for the stack problems, I also think that since you look at 
the source code, and control the translated generation, you can easily map 
any sort of move.b (a7)[+-] in a couple of 68K instructions. As you say, 
it's not easy but feasable to control the stack yourself (I don't think 
doing something like a fake stack, and relying on 68020/030 possibility of 
acessing even addresses is a good solution, like the use of a MMU, it'd be 
much better if the generated code could run on a simple 68000).

         Jump table problems are also tricky, but I think that could be 
handled in the first pass of the transpiler. Overlays is a problem nobody 
offered a solution for yet. I don't know about overlays on the PC, do they 
use the OS a lot ? (in case you can try to trap them in the bios.lib or 
something like that).

          JNM (just agreeing (-:).

--
These are my own ideas (not LBL's)