Searching \ for '[PIC] Banking issues, was CC5X errors - help' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=bank
Search entire site for: 'Banking issues, was CC5X errors - help'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Banking issues, was CC5X errors - help'
2005\05\16@095155 by Alan B. Pearce

face picon face
>Yes. To prevent that, I went one step further and wrote a simple
>preprocessor (a Perl script, see below) that allows me to "declare"
>the banked symbols. Whenever an instruction makes a reference to
>such a symbol, this preprocessor inserts Olin's macro call ahead of it.
>
>Even this isn't foolproof -- for example, if you reference one of
>those symbols immediately after a skip instruction and the macro
>inserts something there.

The problem that I have had is as follows: -

       ; unknown banked state
       dbankif bank_x_register
       ; operations using bank_x_registers

label:
       dbankif bank_x_register
       ; more operations using bank_x_registers
       dbankif bank_y_register
       ; operations using bank_y_registers
       bne    label
       ; more operations

The problem arises because the dbankif immediately after the label generates
no code because bank_x is already selected using the macro before the label.
the next dbankif then changes the bank selected, some operations happen,
then branch back to the label. The easiest fix I found was to change the
dbankif after the label to a dbank so the macro inserted code irrespective
of the previous bank.

2005\05\16@103714 by Dave Tweed

face
flavicon
face
Alan B. Pearce <spam_OUTA.B.PearceTakeThisOuTspamrl.ac.uk> wrote:
{Quote hidden}

That's precisely what Olin's "unbank" macro is for. You should put one
after every label, unless you know for sure that every path to this label
has the bank controls in a known state -- in which case, you can state
this explicitly with the "dbankis <bank>" macro.

You *have* read the documentation (all those comments in std.ins.aspic),
haven't you? :-)

-- Dave Tweed

2005\05\16@104817 by Jan-Erik Soderholm

face picon face
Dave Tweed wrote :

> You *have* read the documentation (all those comments in
> std.ins.aspic),  haven't you? :-)

Or the PDF file available here :
http://www.jescab.se/embedinc.htm

:-)

Note, I havn't included the very latest updates (inkl the
dsPIC stuff) but that's on my wish list...

Still, easier to read then the raw file comments, imho...

Regards,
Jan-Erik.



2005\05\16@110322 by Alan B. Pearce

face picon face
>That's precisely what Olin's "unbank" macro is for. You should put one
>after every label, unless you know for sure that every path to this label
>has the bank controls in a known state -- in which case, you can state
>this explicitly with the "dbankis <bank>" macro.

I guess it is a moot point wether it is before or after.

>You *have* read the documentation (all those comments in std.ins.aspic),
>haven't you? :-)

Yeah, I think this was one where a change got made, or label shifted or some
such.

2005\05\16@124401 by Dave Tweed

face
flavicon
face
Alan B. Pearce <.....A.B.PearceKILLspamspam@spam@rl.ac.uk> wrote:
> Yeah, I think this was one where a change got made, or label shifted
> or some such.

Ah. Well, I solved that problem in my "1st pass" preprocessor, which
autogenerates nearly all of my gotos, labels and "unbank" calls from
more abstract conditional and looping constructs. I've posted it here
on the list before, but there was never any interest in it, so I never
pursued publishing it.

-- Dave Tweed

2005\05\16@173951 by olin_piclist

face picon face
Alan B. Pearce wrote:
> The problem arises because the dbankif immediately after the label
> generates no code because bank_x is already selected using the macro
> before the label. the next dbankif then changes the bank selected,
> some operations happen, then branch back to the label. The easiest
> fix I found was to change the dbankif after the label to a dbank so
> the macro inserted code irrespective of the previous bank.

My mail server was down for most of the day, so now I'm getting incomplete
threads in random order.  I see that Dave already pointed out the UNBANK
macro which is specifically to address this case.

I don't know what original question prompted this discussion, but has
everything been "sorted out" as you folks accross the pond like to say?


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

2005\05\17@040837 by Alan B. Pearce

face picon face
>> The problem arises because the dbankif immediately after the label
>> generates no code because bank_x is already selected using the macro
>
>My mail server was down for most of the day, so now I'm getting incomplete
>threads in random order.  I see that Dave already pointed out the UNBANK
>macro which is specifically to address this case.
>
>I don't know what original question prompted this discussion, but has
>everything been "sorted out" as you folks accross the pond like to say?

Yeah, no problem, it was just a passing remark on what Dave had been saying
about his perl script pre-processor, and I chimed in with a problem I had
observed during debug.

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...