Alan B. Pearce wrote:
> lbank    equ     1      ; register bank for the local state of this
> module ;
> ;   Derived constants.
> ;
> lbankadr equ     bankadr(lbank) ; address within local state register
> bank ;
> ;***********************************************************************
> ;
> ;   Global state.  All this state is assumed to be in the GBANK register
> ;   bank by other modules.
> ;
> .bank#v(gbank) udata
>
> ; variables to go in global bank defined here
>
> ;
> ;***********************************************************************
> ;
> ;   Local state.
> ;
>   if lbank != gbank
> .bank#v(lbank) udata
>     endif

Hi, Alan.  I've cleaned this up a bit since you've grabbed a snapshot
apparently.  I never really liked the kludge above where it had to check
to make sure LBANK was different from GBANK before issuing a UDATA
directive.  The assembler won't allow the same section name to be used
twice in the same module, even if they are consecutive.

To get around this ugliness and simplify defining variables in the right
linker section all around, I created the DEFRAM macro.  It especially
comes in handy when trying to port code between 16 and 18 families.  It
knows to use the access bank on the 18 family and global ram on the 16
family when appropriate.  Otherwise the code would contain differences
between these two families.

You can see the "new" way of doing what you quoted above at
http://www.embedinc.com/pic/qqq_xxxx.aspic.htm.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body