gnupic: Thread: Named cblocks?

Hello, all.

I was just not sleeping and decided to do a bit of coding--
yes, I know, not recommended.  But, on the good side, I got
to thinking.  I wanted to BANKSEL between cblocks of variables
and when I went to type in the 'name' of the cblock, it 
struck me that there isn't one.  I could use any of the 
variables in there, but the code would read better if the 
name indicated the whole *class* of variables I'm about to
play with.

Shall I just put in a set of equates to 'name' my cblocks
or is there some common method of doing this that has not
occured to my sleep deprived mind?

Cheers,
David

On Mon, 2004-03-15 at 03:43, David Willmore wrote:
> Hello, all.
> 
> I was just not sleeping and decided to do a bit of coding--
> yes, I know, not recommended.  But, on the good side, I got
> to thinking.  I wanted to BANKSEL between cblocks of variables
> and when I went to type in the 'name' of the cblock, it 
> struck me that there isn't one.  I could use any of the 
> variables in there, but the code would read better if the 
> name indicated the whole *class* of variables I'm about to
> play with.
> 
> Shall I just put in a set of equates to 'name' my cblocks
> or is there some common method of doing this that has not
> occured to my sleep deprived mind?
> 

You have to be careful with CBLOCK.  IIRC, it can cross a bank
boundary.  So your banksel wouldn't be guaranteed to be correct.

If you use relocatable code, data in one section is always in the same
bank, so putting in a dummy symbol for the bank switching works.

> Cheers,
> David
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

> > Shall I just put in a set of equates to 'name' my cblocks
> > or is there some common method of doing this that has not
> > occured to my sleep deprived mind?
> 
> You have to be careful with CBLOCK.  IIRC, it can cross a bank
> boundary.  So your banksel wouldn't be guaranteed to be correct.

I pretty much have one cblock per bank and I'm used to very low
level management of RAM, so I'm unlikely to get bitten by this,
but you're right, it's important that it be said.

> If you use relocatable code, data in one section is always in the same
> bank, so putting in a dummy symbol for the bank switching works.

I haven't tried that, yet, but it might be a good thing to play 
with before long.  Once I get out of the 2K word devices, I may
have actual need for it.  As it is, my code compiles faster than
PikDev can refresh the window, so there would be little benefit--
unless there is something special about relocatable code that
isn't obvious.

Thank you for the advice, Craig.

Cheers,
David

On Mon, 2004-03-15 at 22:53, David Willmore wrote:
> > If you use relocatable code, data in one section is always in the same
> > bank, so putting in a dummy symbol for the bank switching works.
> 
> I haven't tried that, yet, but it might be a good thing to play 
> with before long.  Once I get out of the 2K word devices, I may
> have actual need for it.  As it is, my code compiles faster than
> PikDev can refresh the window, so there would be little benefit--
> unless there is something special about relocatable code that
> isn't obvious.
> 

Opinions vary on the subject. Some people are dead set against it, 
others aren't.  It appears that the people with the most objections tend
to have more experience using absolute mode.  They are comfortable and
don't want to change.  That's OK.

Recently, there was a thread on this subject on jallist.  You can search
through their archive it you want.

In my opinion, here are the advantages (in rough priority):
1.  All symbols are local by default.  You pick what is global.

2.  The code is modular, so it is easier to reuse.

3.  The linker manages address(bank/page) assignments, so it should
decrease your workload.

4.  Assembling a large project can be faster, because you only assemble
what has changed.

5.  In theory, you should be able to link objects generated from
different languages.  Although, it hasn't happened yet.  There is an
opportunity with sdcc and gpal.  The advantage would be sharing a common
library.

Are there ways to get some of these advantages in absolute mode?  Yes.

Which method is better?  It depends.

> Thank you for the advice, Craig.
> 
> Cheers,
> David
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

> Opinions vary on the subject. Some people are dead set against it, 
> others aren't.  It appears that the people with the most objections tend
> to have more experience using absolute mode.  They are comfortable and
> don't want to change.  That's OK.

I'm open to these ideas.  Is there a good tutorial on coding this way
and using the linker to acheive these goals?

> Recently, there was a thread on this subject on jallist.  You can search
> through their archive it you want.

I will go take a look, though I have no use for Jal.

> In my opinion, here are the advantages (in rough priority):
> 1.  All symbols are local by default.  You pick what is global.
> 
> 2.  The code is modular, so it is easier to reuse.

I've heard that before. :)

> 3.  The linker manages address(bank/page) assignments, so it should
> decrease your workload.

I assume that there are some coding constrainst/standards that one
has to use to take advantage of these facilities?  I'm thinking
of doing it from assembly.  I assume that's possible.

> 4.  Assembling a large project can be faster, because you only assemble
> what has changed.

True.  Once I move on to the stuff I'm doing with my MegaPIC project,
I'll need that.  Short story: 18C801 with 2M FLASH, 258K SRAM.

> 5.  In theory, you should be able to link objects generated from
> different languages.  Although, it hasn't happened yet.  There is an
> opportunity with sdcc and gpal.  The advantage would be sharing a common
> library.

Hmm, regarding libraries, will it link only in referenced functions
or blindly link as if they were .o files?  I've been noticing that's
a problem the AVR gcc folks seem to have.

> Are there ways to get some of these advantages in absolute mode?  Yes.

Yeah, with clever tricks, probably.  I've yet to do anything that
large.

> Which method is better?  It depends.

Always does. :)  Thanks for the information and advice, Craig.

Cheers,
David