A METHOD FOR PIC ASSEMBLY CODE INTEGRATION AND REUSE - Part 7


Names for variables
-------------------

If you automatize the task of allocating registers you'll very probably
have more variables than if you don't. That's because you'll be able to
create more variables and also because this scheme is intended to
facilitate code reuse and for that you shouldn't share variables.

So variable naming becomes and issue. You've already automatized the
allocation of registers and facilitated reuse, now you don't want to be
dealing with the names of variables, checking to see that they don't
repeat. And the same thing happens with routines' names.

The solution I'm using is giving every component a three capital letter
keycode. For example, "KEY" for a keyboard interface, "MDI" for a
multiplexed-display driver, etc. I document this keycode at the beginning
of the source file, and when I do a new one I care that it is unique.

Every label belonging to a source code uses its keycode as a prefix. For
example "MDIdigit", "KEYauxi", "KEYReadKey", etc.

For the rest of the names I use a common convention: start with a capital
letter if it's a routine or with a small letter if it's a variable. To
join several words into a label, instead of using an ugly underscore,
start the new word with a capital letter.

I use this rule only because of a personal preference. What I do want to
recommend is the use of the keycode to deal with the fact that all
variables have a global scope. If you can think of another way please let
me know.

I think this solution is pretty neat, and it has another advantage. If you
are browsing through a symbol list looking for the values given to a
component's labels you just have to search for the keycode and there
you'll have all that component's symbols together.


Dealing with RAM paging
-----------------------

Ups, I haven't got much to say about this. The macros, as I'm using them
now, give more-than-7-bit addresses. What I mean is that a variable
allocated on page 1 could have, for example, address A7 (not 27). So, if
you compile something like "MOVF thatVariable,W" you will get a message.

Surely the macros could be modified to give 7-bit-addresses, but I don't
like it because symbol lists would give less information and I have the
idea that source code could get rather confusing...  I really didn't think
much about it.

What I do is write "MOVF thatVariable & H'7F',W" to avoid the messages for
those lines where I had taken care of ram paging. Typing those "& H'7F'"
looks like a lot of nonsense work but with a reasonable editor you can do
text subsitutions or macros and save much of it. And on the other hand,
on the source code you can distinguish between page 0 and page 1 variables
and you still have messages alerting you of those cases to which you
didn't pay attention.

But I think there could be something better, perhaps using "#define"s.
By the way, I have never used four-ram-page processors, and this would not
be very neat with them I guess...


Dealing with ROM paging
-----------------------

The ROM pages where components are placed can be documented on a
client-server structure diagram like the one I sketched on my first
posting.

As the reasonable thing is, given a client-server relationship, to try to
place both components on the same page so as to save changes to PCLATH,
the whole structure would have only a few clusters of components belonging
to the same page. So with a quick look you can tell where you need to
change PCLATH and where each component is placed.

I'm not using any automated scheme to change PCLATH, mostly because many
times I do several sequential long calls and changing PCLATH for every
call there would be a waste of ROM, a resource I always run short of.

Problems could arise when you want to reuse code and you find that if you
mantain the original page assignments the code won't fit, or if you want
to use a piece of code made for page 1 of a two-page processor in a
one-page chip.

For those cases I guess that I would do second versions of those
components that need to be changed. For example, if I did a display driver
for page 1 and I want to change it for page 0 I'd copy that source and its
clients and servers naming them differently (changing the key-code would
not be necessary) and take out and add the PCLATH assignments that would
be needed. Then, if I have a third project needing this driver, I'd have
two versions from where to choose.

This message might have more questions than answers but I already told you
that was my objective. I have been refining my ideas as I used them and I
would like this process to continue here with yours!

On my next posting I'll list a macro I use to allocate flags. If you have
any questions or ideas about the variable-allocation scheme please write.

Regards!
                                                          Andres
                                                  adjordj@aleph.fi.uba.ar