gnupic: Re: [gnupic] gpsim --"invalid file register" error
Subject:
Re: [gnupic] gpsim --"invalid file register" error
From:
Ralph Corderoy ####@####.####
Date:
5 Feb 2007 15:06:11 +0000
Message-Id: <20070205150538.545941475FC@blake.inputplus.co.uk>
Hi Scot,,
> > If it did this on every MyVariable access then that would be handy,
> > otherwise it's just a macro short-hand that I need to sprinkle
> > throughout the source, cluttering it up.
>
> The only problem with having the simulator insert automatic bank
> checking assertions on every register is that you'll need a mechanism
> to inhibit it. For example, a few PIC families have registers that are
> aliased in multiple banks. Interrupt routines or utility functions
> often use this area for their variables so that the banking can be
> ignored. Or in some cases, programmers will intentionally declare
> variables in multiple banks such that they're effectively aliased.
Understood. That's why when I suggested different REG_FOO symbols, I
said "All have the numeric value 0xf00. The first is if the coder wants
the code to be considered correct regardless of the current bank. The
other two are used when the coder knows a specific bank is intended and,
as well as telling the reader this, want checks performed that the
correct bank is switched in."
> For these cases it will be necessary to either put more logic into the
> automatic bank checking code.
I'd suggest that it all be based on data that the coder, or the device
include files, can optionally specify once near the symbol's definition.
> Another argument is efficiency. I know this is a weak argument, but
> the assertion checking stuff takes simulation time. gpsim is really
> efficient right now in accessing registers from the simulated ram.
> Introducing assertions will easily make the access an order of
> magnitude slower. Depending on code being simulated, the overall
> simulation time could be affected by as much as a factor of 2!
Fair enough. Having it as a extra debugging option that comes with a
speed cost would be fine.
> I'm sure we could debate the relative merits of implicit versus
> explicit bank checking. I tend to prefer explicit because it
> emphasizes intent. However, if implicit bank checking is not too
> obtrusive, or at least can be easily inhibited, then I'd accept that.
OK.
Cheers,
Ralph.
