Re: Emulator Project Question

[pausch@saaf.se (Paul Schlyter)]

In article <EjUP7.441$n%2.201954@news.uswest.net>,
Steve Mentzer <steve@crackershack.com> wrote:
 
> If you could clearly define which bytes were "code" and which were "Data",
> performing assembly conversion at runtime wouldn't be so difficult.
> 
> The problem is that you cannot "translate as you go",
 
Why not?  Some Java interpreters do precisely that: they translate
the J-code into native machine instructions as they go (it's called
JIT compilation where JIT means "Just In Time").  With linear code
this will of course yield no gain in execution speed at all, but if
you enter a loop there'll be a tremendeous gain: the loop is
translated once, and then the loop is executed in native code.
 
So why can't this technique be applied to 6502 machine code as well?
BTW it would probably be the only secure way to distinguish code
from data: what's executed is, by definition, code.
 
> and you have no guaranteed method of identifying which is code
> and which is data.
 
Yes you have - by "following the code" so to say.  But it'll be tricky
if some bytes are used for code *and* data, particularly if the "data"
is changed, i.e. self-modifying code.
 
> The fastest method so far has been a simple jump table. Define an
> array of function pointers that is 255 bytes long.
 
I think you mean 256, not 255: remember that the 1-byte opcode of the
6502 has 256 possible values.
 
Also, I think you mean 256 entries rather than 256 bytes: a function
pointer is certainly longer than 1 byte.
 
> Each element points to a function that handles that particular opcode.
> Simply do a array[opcodenumber]; and you can call the emulated CPU.
> It is slower than native code, but it is far more reliable.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se
WWW:     http://home.tiscali.se/~pausch/