>     Hey, by the way... Speaking of little mistakes that take a long
>     time to find, what does W contain at the "done" label?
>
>             list p=16c54
>             #include p16c5x.inc
>
>             list r = hex
>
>             org     0
>
>             movlw   0    ;3 * 0 = 0x00
>             addlw   3    ;3 * 1 = 0x03
>             addlw   6    ;3 * 2 = 0x06
>             addlw   9    ;3 * 3 = 0x09
>             addlw   C    ;3 * 4 = 0x0C
>             addlw   F    ;3 * 5 = 0x0F
>
>       done: goto    done
>
>             org     1FF
>             goto    0
>
>             end

OK, I'll bite.  It sure looks like 3 * 15, or 45.  If there's some hidden
trick here, I guess I'm missing it.

>     I couldn't disagree more.  As long as Microchip's RP0 definition
>     remains in the include file, the assembler will still allow you
>     to do the wrong thing by using RP0 with registers other than
>     STATUS.
>
>     What we want to do is constrain the assembler so that it ONLY
>     accepts CORRECT usage of RP0... And the only way to do that is
>     to remove Microchip's error-prone definition when we add the new
>     error-proof definition.

Then what do you do in those cases where you want to access a named bit
other than thru bit manipulation instructions, or to a shadow register.
These cases are relatively rare, so I wouldn't mind a little extra syntax
to disable the checking, but your method seems to proclude them
altogether.  For example:

    movlw    (1 << abit) | (1 << anotherbit) ;make mask of combined bits
    movwf    somereg    ;set the new state

or:

    bsf      shadowreg, abit ;update shadow register of SOMEREG

Also, while it would be nice to have some sort of type checking on bit
number symbols, let's no loose sight of the fact that these kinds of
errors are quite rare.  I've written tens of thousands of lines of PIC
assembler of dozens of projects, and I have no recollection of ever using
a named bit with the wrong special function register.

Hmm.  Maybe I should log all PIC coding errors for a while and see what
kind of mistakes I do make.  That might be useful to decide what kind of
tool upgrades would be appropriate.  Just from memory, the most common
error I make is forgetting to add the ", w" after a file register
instruction when I intended the result to go into W.  Fortunately these
are quick to find in debugging.

The only error (in my coding) in the last month or two that took
significant time to find was when I accidentally used the wrong temporary
variable in the low priority interrupt routine of an 18F.  This was the
first time I used multiple interrupt priorities on a PIC.  Until then, I
would define IREGs, which were temporary scratch registers for exclusive
use during interrupts.  when I implemented low and high priority
interrupts it just didn't occur to me that I would need separate IREGs for
the two interrupts (yes, I know, duh!).  One of the IREGs used in the low
priority interrupt routine would get trashed when a high priority
interrupt happened.  This produced a symptom that took a whole morning of
back tracking to find.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads