Re: [Tuxnes-devel] more help w/ asm

[Jim U. <ji...@3e...>]

At 07:50pm on 2001 April 11, Mike Melanson did write:
> On Wed, 11 Apr 2001, Jim Ursetto wrote:
 
> Actually, it's not really porting. The primary issue
> involved is writing a new opcode translation table as well as a new
> ASM linkage file (such as x86.S).

Hmmm... if translating assembly language between architectures is 
not porting, then I don't know what is ;)
 
> 	But people really, really like the dyn-rec approach
> 	because, as you noted, it's cool. It's difficult,
> 	sure, but if someone wants to go for it, great.

More power to Rigel and I hope he succeeds.  While he's
in there, it'd be great if he could look at some
issues I noticed with dynrec:

1) Arbitrary writes/reads to IO ports don't work, only
   special cases.  I'm sure the common cases are
   covered, but the occasional ROM may do something
   unexpected.  Probably difficult or impossible to get
   100% right without sacrificing speed.
2) In the same vein, some opcodes (ASL, ROL) don't use
   the mapper.
3) Some opcodes consider the range $2000-$5FFF as I/O
   space, others use a different range.  This may be an
   issue with the area around $3F00 as well.
   Unfortunately, I can't point to any examples of this
   offhand :(
4) Some x86 instruction use/comments inconsistent, such as
   addl/leal used interchangeably.  Probably just a
   function of being written over a long period, also a
   very minor point.

The main point is that these issues confused me when I
was trying to understand the dynrec code.  There could
be compatibility implications as well, probably
extremely uncommon.  Maybe we should consider
contributing any interesting tidbits about the dynrec
code to HACKING, or comment the code in especially
difficult places.

All in all, the dynrec is incredibly cool, and it must
have taken a huge effort to get it working and find all
those special translation cases...  and it's very fast,
nearly 10 times faster than the Nofrendo core, using
the none renderer.
 
> 	After the next release, I want to take TuxNES in a direction that
> utilizes the dyn-rec approach, if available, and can fall back on a
> portable core.

I implemented it this way in my copy of the tree,
except dynrec/interpreted mode was a compile-time
option.  It should be possible to do it on the fly,
though.


-- 
"... [WM97/Melissa-V] triggers immediately and attempts to delete data 
on your M:, N:, O:, P:, Q:, S:, F:, I:, X:, Z:, H:, and L: network drives."
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F  5ED1 6DB3 FBB9 4334 0710