Dave Tweed wrote:


> Alan B. Pearce wrote:
> > > I've written a ton of PIC assembler and am getting tired
> > > of getting the btfsx sense wrong or being in the wrong bank.
> >
> > This is why I use Olins macros. The conditional macros seem to make more
> > sense, and the banking macros produce code only if they need to (although
> > there are still occasions where you can get caught out).
>
> 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.

The XCASM assembler tracks bank useage and inserts bank select instructions
automatically for you (if you let it). With this assembler there is no need to
declare special banked symbols, all RAM accesses are tracked.

>
> 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 workaround for that is to explicitly put a dbankif
> *ahead* of the skip to insure that the macro inserted by my script won't
> generate any code.

The XCASM assembler knows how to deal with bank switching through skip
instructions and inserts the instructions in the right place. It tracks multiple
execution paths through each instruction (including subroutine calls) and only
inserts bank select instructions which are absolutely necessary. If you manually
insert bank select instructions elsewhere (maybe further up in the execution
path) it will compensate and not insert the now redundent bank select
instructions.

>
> At some point, it just becomes simpler to write a compiler.

The bank and page management of the XCASM assembler works great, there really is
no need for a compiler to do all the hard work.

The XCSB compiler uses XCASM as the backend assembler so programmers get the
full benefit when embedding inline assembler (there is no need to hack about in
assembler trying to maintain consistancy between the programmer supplied inline
assembler and the compiler generated assembler).

> Currently, I'm
> running two different Perl scripts over the code (hence the reference to
> "2nd pass" below), then Olin's "prepic" preprocessor, then all of the
> macros get expanded before the actual assembly happens. Fortunately, this
> is all managed by a Makefile, so my workflow is actually fairly simple.

A further advantage of doing this in the assembler is that XCASM can generate a
profile of the executable which shows all the execution paths through an
instruction. With this you can easily work backwards and identify paths through
an instruction that you had not anticipated or simple forgotten about. This
greatly helps locate an execution path where a variable (or SFR) is undefined.
This is the kind of error you normally use a simulator and trace buffer to find,
but with this kind of debugging you might need to spend hours homing in on the
problem path.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use






-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist