gnupic: Re: [gnupic] gpsim --"invalid file register" error
Subject:
Re: [gnupic] gpsim --"invalid file register" error
From:
Robert Pearce ####@####.####
Date:
4 Feb 2007 21:09:04 +0000
Message-Id: <+qIBkvPsnkxFFwDi@daniel.huneausware.local>
On Sun, 4 Feb 2007, Ralph Corderoy ####@####.#### wrote :
>
>
>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.
Right, so you want it to do this on code that has been loaded without
source, meaning it has to work from only the information in the HEX
file. Or perhaps more relevantly, you want it to work on code compiled
from something like:
bsf STATUS,RP1
loop:
movf indf,w
But the assembler would have to identify the state of the RP bits at
'loop:' which, since it's a label, requires it to identify every
possible way to reach that label, and if one of those routes has a label
without any RP settings before it jumps to "loop" then it needs to
back-track through all that and if one of those.....
Code path static analysis is a phenomenally difficult, complex and
expensive task. But it's what you're effectively asking for here.
>
>By binary do you mean the hex file for downloading to the PIC?
Yes, because that may be all GPSim has available.
> 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?
>
The COD file contains that information, which allows GPSim to
cross-reference the source code and mark the current line. Well, most of
the time it can - I have a coding style that breaks it rather often due
to a bug in gplink, but that's beside the point.
>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.
Only if that information can be unequivocally determined at build time.
It is generally accepted that this is not universally possible without
manual instrumentation of the code.
>
>> 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.
>
But I'm afraid it's the only one available that doesn't require the
coder to annotate the source.
All that could be done is for GPSim to analyse the current state of the
RP bits during simulation and report the operation actually being
performed, but that's only any good while single stepping.
--
Rob Pearce http://www.bdt-home.demon.co.uk
The contents of this | Windows NT crashed.
message are purely | I am the Blue Screen of Death.
my opinion. Don't | No one hears your screams.
believe a word. |
