Re: [Tuxnes-devel] Use of mmap () (fwd)

[Mike M. <mel...@pc...>]

Hi,
	It looks like Quor meant this for the entire list...

-- 
	-Mike Melanson

---------- Forwarded message ----------
Date: Thu, 6 Jun 2002 23:20:55 -0400 (EDT)
From: Quor <qu...@no...>
To: tux...@li...
Cc: mel...@pc...
Subject: Re: [Tuxnes-devel] Use of mmap ()

Mike Melanson wrote:

> On Tue, 14 May 2002, W. Michael Petullo wrote:
> 
> > The comment makes me wonder why malloc was not used.  I am not familiar
> > with the MAP_ANON option.
> > 
> > Also, in mapper.h things like _RAM point to hard-coded addresses, in
> > this case 0x10000000.  Again, why is this done?  GNU as will assume that
> > undefined variables are, to use C's syntax, extern, so _RAM could just
> > be defined as a char * in mapper.c.
> 
>       The best answer for all of your questions is: "Because that's the
> way quor originally wrote Nestra." It's the kind of thing that worked and
> no one ever really understood it or had a reason to try to change it, even
> though they had an inkling that it may not have been the most rational
> thing to do.

You're half right. :-)  The mmaps have been there since I originally
wrote the code over 4 years ago, but that particular line hasn't.

Originally, it mapped the rom file.  Then someone decided to add gzip
support, and changed the mmap to MAP_ANON, then uncompressed the rom
into this memory.  Of course this could be done with malloc, but then
you'd have to change all references to _RAM to follow a pointer instead.
extern char * and extern char [] are not the same thing!  _RAM is
treated like the latter.

The reason for the fixed addresses is to make it easier to link with
the dynrec core.  You can use different addresses.  Also these regions
are (deliberately) not contiguous; an out-of-bounds access will cause
SIGSEGV.  That was important for me to aid debugging; others may not care.

The references to ROM_BASE - 0x8000 in mapper.c are due to the rom being
mapped at 0x8000 in the 6502 address space.  So accessing address 0x8000
under such a mapping is redirected to ROM_BASE-0x8000+0x8000, which is
actually an offset of zero.  ROM_BASE - 0x8000 is unmapped; it should be
impossible to actually get such a negative offset, but if it somehow
happened, the process would immediately die with a segfault.

CODE_BASE is where the dynamic recompiler will write the translated code
that it generates.  INT_MAP is the translation address map for the 6502
in integer mode.  Since the NES CPU doesn't have a decimal mode, there
is no DEC_MAP.