gnupic: Re: [gnupic] gpsim --"invalid file register" error


Previous by date: 5 Feb 2007 03:26:57 +0000 Re: [gnupic] in-circuit debugger, Maxim Wexler
Next by date: 5 Feb 2007 03:26:57 +0000 Re: [gnupic] in-circuit debugger, Robert Pearce
Previous in thread: 5 Feb 2007 03:26:57 +0000 Re: [gnupic] gpsim --"invalid file register" error, Robert Pearce
Next in thread: 5 Feb 2007 03:26:57 +0000 Re: [gnupic] gpsim --"invalid file register" error, Ralph Corderoy

Subject: Re: [gnupic] gpsim --"invalid file register" error
From: "Scott Dattalo" ####@####.####
Date: 5 Feb 2007 03:26:57 +0000
Message-Id: <61648.71.139.21.208.1170645966.squirrel@ruckus.brouhaha.com>

On Sun, 2007-02-04 at 13:52 +0000, Ralph Corderoy wrote:
> Hi Scott and Robert,
>
> Scott wrote:
> > It might make better sense to place the logic in the assembler/linker.
> > [snip]
> > 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.
>
> What's a "simulator assertion"?

A simulator assertion is an assertion you place in your source code that
doesn't affect the .hex file, but tells the simulator something about the
code. For example, if you expect W to be 0x33 at some particular point in
your code, you can write

  .assert  "W==0x33, \"FAILED Analog Stimulus Test\""
        decfsz  LoopCounter,F
         bra    Loop1

(this was copied from regression/analog_stim/p18f452.asm)

Just before executing the decfsz instruction, gpsim will verify that W
contains 0x33. If it doesn't, the simulation is halted and the message
printed.

Check out the code in the regression directory for numerous examples.


I'd want the simulator to perform the check regardless of where the
> executable came from, so perhaps there wouldn't be a BANKSEL macro?  And
> I normally think of instrumenting code as meaning the code is modified.
>
Yes, your usage of the term 'instrumenting code' is accurate. Perhaps I
should have written 'non-intrusive instrumenting'.

And to supplement Robert's informative comments, I agree that a full-blown
flow optimizer is challenging. I attempted it with SDCC and was only
partially successful. However, I think it is possible that the linker can
be taught in most circumstances to both insert the proper bank select bits
and to supply the simulator assertions that validate the selection. I
don't think it's wise to put this automatic checking into the simulator.
However, it might be possible to write macros that allow one to
automatically check the bank selection.

For example, it'd be cool if there was a macro:

    mCheck_Bank MyVariable

When placed in the assembly source, this would add simulator assertions
that validated the bank bits match those for the bank in which MyVariable
resides.

Scott

Previous by date: 5 Feb 2007 03:26:57 +0000 Re: [gnupic] in-circuit debugger, Maxim Wexler
Next by date: 5 Feb 2007 03:26:57 +0000 Re: [gnupic] in-circuit debugger, Robert Pearce
Previous in thread: 5 Feb 2007 03:26:57 +0000 Re: [gnupic] gpsim --"invalid file register" error, Robert Pearce
Next in thread: 5 Feb 2007 03:26:57 +0000 Re: [gnupic] gpsim --"invalid file register" error, Ralph Corderoy


Powered by ezmlm-browse 0.20.