gnupic: Re: [gnupic] gpsim --"invalid file register" error
Subject:
Re: [gnupic] gpsim --"invalid file register" error
From:
Scott Dattalo ####@####.####
Date:
1 Feb 2007 17:06:43 +0000
Message-Id: <45C21DDF.5080802@dattalo.com>
Ralph Corderoy wrote:
> I've heard a common source of PIC programming bugs is not having the
> right bank switched in at the right time. I was thinking that if
> address 0xf00 is either the read-only register VERSION in bank 0 or the
> read-write register PORTB in bank 1 then couldn't the assembler/compiler
> make available a set of constants.
>
> REG_FOO
> REG_FOO_VERSION
> REG_FOO_PORTB
>
<snip>
Hi Ralph
Your idea of utilizing the simulator to automatically verify banking is
a good one. I believe a variation of this idea has been suggested before.
It might make better sense to place the logic in the assembler/linker.
There are a couple of reasons for this. First, the linker has full
access to all of the symbol names and their values. Most symbols are not
available to the simulator unless they're explicitly declared global.
And even if a register is declared global, there's no information
provided to the simulator to cross reference the instructions. Second,
the linker can (more intelligently) work with the BANKSEL macro. Once
the linker determines that a particular combination of the register bits
are required, then it can instrument the code with a simulator
assertion. Furthermore, the linker can also issue warnings about
potentially erroneous bank settings. Well it does this already, but in a
pretty useless way; *all* non-bank 0 accesses are flagged with a
warning. That's a false positive. And conversely, the linker fails to
recognize if the bank bits are not pointing to bank 0 while a register
in bank 0 is being accessed.
OTOH, if you can think of a way to export enough symbolic information so
that the simulator can do the checking all by itself, then I'd be
willing to implement that solution.
Scott
