gnupic: Re: [gnupic] gpsim --"invalid file register" error
Subject:
Re: [gnupic] gpsim --"invalid file register" error
From:
Ralph Corderoy ####@####.####
Date:
4 Feb 2007 13:53:21 +0000
Message-Id: <20070204135249.564A0147EFC@blake.inputplus.co.uk>
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"?
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.
It may be that the PIC target doesn't have the room for the extra
instructions, or I don't want to test the instrumented code and deliver
a different executable.
> 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.
I think this ties in with Robert's comment...
Robert wrote:
> On Thu, 01 Feb 2007 15:59:27 +0000 you wrote:
> > Has anyone considered this kind of thing before? Am I missing
> > something that makes it impractical? It seems an ideal way where a
> > simulator like gpsim can win over the real hardware.
>
> But the headers already _do_ define a load of symbols for each bank's
> version. There really isn't a problem going from readable source code
> to object. The trouble is that the _disassembler_ can't re-create the
> source code from the binary, as the binary is identical for each case.
By binary do you mean the hex file for downloading to the PIC? I meant
an executable file format that can contain debug information. From what
little I've read, it seems I mean the COD file for gpsim, e.g. a.cod.
That has symbol information, and source references for an opcode's
address. Can't a convention be cooked up that allows these to be used
to describe the desired bank at a particular address?
I'm thinking of "fake" symbols that the coder didn't create. Given an
instruction's address, the source file and line number can be found,
they can be used to concoct a symbol name, and if that exists then it
can contain information lost in translation, e.g. desired selected bank.
All these look-ups can occur as a one-off pass during gpsim loading the
executable, not during simulation.
> The only way for a disassembler to know the coder's intent is to
> figure out the state of the RP bits. But that depends on the path the
> code has followed to get to that point, so it can't be done reliably.
I agree that's not an option.
Cheers,
Ralph.
