Olin Lathrop wrote:


> Sergio Masci wrote:
> > A further advantage of doing this in the assembler is that XCASM can
> > generate a profile of the executable which shows all the execution
> > paths through an instruction. With this you can easily work backwards
> > and identify paths through an instruction that you had not anticipated
> > or simple forgotten about.
>
> How does it deal with data-dependent modification of the PC?

It depends on the data. It knows about XCSB longcalls so if it encounters a
sequence of instructions that corresponds to a longcall it associates the RAM
locations with a return address. If the PC is modified from such a return
address the execution path remains valid and is tracked, (loading a constant
into the PC via PCLATH and PCL will also result in a valid tracked path). If the
PC is modified using undefined data (e.g. from an untracked RAM location) then
the execution thread for the undefined PC ends and the PC is undefined at that
point.

You could argue that this will be invalid because there is no way of tracking
all possible execution paths. However since the purpose of the program is to
execute a well defined sequence of instructions it is possible to ignore
undefined jumps and assume that they will be valid if they are based on valid
data. Most of the time (almost always), a computed jump will start from an
otherwise unreachable instruction. Such start points allow the assembler to
identify execution paths where the bank and page may be undefined.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist