Searching \ for 'Wanted: Utility that detects dead PIC code segment' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Wanted: Utility that detects dead PIC code segment'.

Truncated match.
PICList Thread
'Wanted: Utility that detects dead PIC code segment'
1998\03\30@132356 by Dave Reinagel

picon face
Greetings,
       Well, I have managed to completely fill a PIC14000 and
am now looking through the listings trying to find dead code
segments -- like floating point subroutines that are never
called and can be commented out of the code to reclaim more
space.
       I can't believe I'm the only one who has hit this
limit, and am wondering if someone has a utility that can
scan either a PIC listing or the source code and identify
any code segment that is never executed?  If not, perhaps
I should try to write one.

Dave Reiangel
Auspex Systems, Inc
spam_OUTdaverTakeThisOuTspamcorp.auspex.com

1998\03\30@224747 by Chris Eddy

flavicon
face
Man, have I walked a mile in your shoes.  I packed a 14000 to the
rafters, and when I needed that little bit more (and more, and more) I
hand packed in any way I could.  Alas, I am no use to you as I did not
look for any cool tools.  But I can add a cool feature that fits in with
your idea like a glove.  A dead RAM register finder.  I regularly jam
the RAM full, and hunt for unused RAM, to find out later that there were
a few two or three that I wasn't using and didn't see.  Shaa.  The
problem with my idea is that many RAM variables are simply equates, and
not oficially allocated until used in a piece of code, and only then
after first being loaded as a movlw.  (sometimes, IE FSR operations).
So the use of the RAM can be hidden down in the code a few steps.

Long story short, keep looking, and if you find or write something,
shout it out.

Chris Eddy, PE
Pioneer Microsystems, Inc.

Dave Reinagel wrote:

{Quote hidden}

1998\03\31@000754 by Mike Keitz

picon face
On Mon, 30 Mar 1998 22:43:54 -0500 Chris Eddy <ceddyspamKILLspamNB.NET> writes:
>Man, have I walked a mile in your shoes.  I packed a 14000 to the
>rafters, and when I needed that little bit more (and more, and more) I
>hand packed in any way I could.  Alas, I am no use to you as I did not
>look for any cool tools.  But I can add a cool feature that fits in
>with
>your idea like a glove.  A dead RAM register finder.  I regularly jam
>the RAM full, and hunt for unused RAM, to find out later that there
>were
>a few two or three that I wasn't using and didn't see.  Shaa.

The cblock directive is useful for allocating RAM in contiguous order and
adding or removing locations later.  It would take quite a bit of work to
actually analyze which RAM locations could possibly be reused, and which
ones have to stay put.

I have a 16F84 project that is also completely full.  It would be nice to
have such a utility.  I'd like a feature where it would look for
subroutines that are only used once and in-line them.  That way some
rather clean, modular looking assembler code could be written but it
would pack down by several instructions before actually assembling.


_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\03\31@004403 by Scott Newell

flavicon
face
>        Well, I have managed to completely fill a PIC14000 and
>am now looking through the listings trying to find dead code
>segments -- like floating point subroutines that are never
>called and can be commented out of the code to reclaim more
>space.

Here's a thought--there are three ways for a routine to run.  You can call
it, goto it, or run into it.  For a quick and dirty utility, it shouldn't
be too hard to simply make a table of all the gotos and calls in the entire
program.  This table contains routines that are probably used.  Then run
through and look for instructions that are preceded by a goto or return
(without a leadig bit test), and check to see if they're in the first
table.  If not, the execution can't reach that point and it's dead code.

This will report tables and other computed goto targets incorrectly, of
course.

It'll also report routines as used, although the only reference to them may
be in other dead routines.


Maybe it would be better to start at 0x0000 (and 0x0004), building a tree
to keep track of the conditionals.  Then run down the branches, marking the
code as 'live', until you hit live code.  Once you've traversed the entire
tree, any code that isn't marked live is dead.  (Unless there are computed
gotos...)


later,
newell

1998\03\31@040727 by Chaipi Wijnbergen

flavicon
picon face
At 23:42 30/03/98 -0600, Scott Newell wrote:
>>        Well, I have managed to completely fill a PIC14000 and
>>am now looking through the listings trying to find dead code
>>segments -- like floating point subroutines that are never
>>called and can be commented out of the code to reclaim more
>>space.
>

Another idea, such utility should also look for temporary variables that
are used in routines and can share their ram location with other temporary
variables of other routines that (not in interrupts).

CCS C compiler does that by default.

Chaipi
                              \\\|///
                            \\  ~ ~  //
                             (  @ @  )
----------------------------oOOo-(_)-oOOo-----------------------------------
!                                                                          !
! Chaipi Wijnbergen                                                        !
! Electronics/Computer Eng. M.Sc. Tel  : +972-8-9343079                    !
! Optical Imaging Laboratory      Fax  : +972-8-9344129                    !
! Brain Research Center           Email: .....chaipiKILLspamspam.....tohu0.weizmann.ac.il       !
! Weizmann Institute of Science   WWW  : http://www.weizmann.ac.il/~chaipi !
! Rehovot 76100 ISRAEL                                                     !
!                                                                          !
------------------------------------Oooo.-----------------------------------
                         .oooO     (   )
                         (   )      ) /
                          \ (      (_/
                           \_)

1998\03\31@082945 by Norm Cramer

flavicon
face
>At 23:42 30/03/98 -0600, Scott Newell wrote:
>>>        Well, I have managed to completely fill a PIC14000 and
>>>am now looking through the listings trying to find dead code
>>>segments -- like floating point subroutines that are never
>>>called and can be commented out of the code to reclaim more
>>>space.
>>

What about running the program in MPLAB with a trace of all addresses.
When the run is done, sort the trace file in address order and look for
holes (no code executed there).  These will be unused code in your
particular test.

Norm

1998\03\31@100053 by

flavicon
face
Nice idea for a small program that runs top to bottom in one pass. In
practice, I think if you could find a way to exercise all the paths
through your code reliably, you could make a fortune marketing it as a
test tool!

I think code which fills a 14000 will have a number of possible paths -
especially as the original purpose of this thread is to find the unused
backwaters!

I'm sure someone out there with time on their hands will have started
work on the 'dead code detector' killer app!

Incidentally, I looked at writing a code analyser some time ago ,using
the .COD file as input, but gave up due to lack of documentation. Anyone
know where .COD format is documented?

Neil

----------
From:  Norm Cramer
Sent:  31 March 1998 14:21
To:  EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
Subject:  Re: Wanted: Utility that detects dead PIC code segments

>At 23:42 30/03/98 -0600, Scott Newell wrote:
>>>        Well, I have managed to completely fill a PIC14000 and
>>>am now looking through the listings trying to find dead code
>>>segments -- like floating point subroutines that are never
>>>called and can be commented out of the code to reclaim more
>>>space.
>>

What about running the program in MPLAB with a trace of all addresses.
When the run is done, sort the trace file in address order and look for
holes (no code executed there).  These will be unused code in your
particular test.

Norm

1998\03\31@130304 by Harold Hallikainen

picon face
On Mon, 30 Mar 1998 22:43:54 -0500 Chris Eddy <ceddyspamspam_OUTNB.NET> writes:
>  But I can add a cool feature that fits in
>with
>your idea like a glove.  A dead RAM register finder.  I regularly jam
>the RAM full, and hunt for unused RAM, to find out later that there
>were
>a few two or three that I wasn't using and didn't see.  Shaa.  The
>problem with my idea is that many RAM variables are simply equates,
>and
>not oficially allocated until used in a piece of code, and only then
>after first being loaded as a movlw.  (sometimes, IE FSR operations).
>So the use of the RAM can be hidden down in the code a few steps.


       I notice Microchip uses equ to allocate RAM, which seems very
inflexible to me.  I use cblocks and have them typically inside the
subroutine that uses them.  I can add stuff easily without having to
search through some list of addresses.  The assembler handles it for me.
As to unused RAM, it does seem that the assembler could catch any labels
(whether code or data) that are not referenced and flag them with
warnings.  It might also be kinda neat to put conditionals around data or
code to include them only if they are referenced somewhere.  Of course,
this would not catch code that is referenced but by a call or goto that
is impossible to get to...  Do we write code like that?  Finally, the
endless search for ram could be resolved to a large extent, I believe, by
keeping local (automatic, non-static) variables on a stack (if we had
access to one).


Harold




_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\03\31@130849 by Bob Shaver

flavicon
face
The B. Knudsen Data CC5x "C" compiler allows you to write code as
dense/efficient as assembly AND automatically removes any uncalled code
segment (i.e. subroutine).  It will also automatically remap RAM variables
to the same RAM location based on their usage.  For example, sub1 uses a
byte variable called Byte1, and sub2 uses a byte var called Byte2.  The
compiler analyzes the subroutine call structure, and if sub1 never calls
sub2 (even indirectly) and sub2 never calls sub1, then Byte1 and Byte2 will
use the same physical RAM location.

Disclaimer: I have not looked at the other compiler offerings in a while
and do not know if they offer similar capabilities. I have to assume any
"decent" PIC compiler would do these things.

Bob.

On Monday, March 30, 1998 1:18 PM, Dave Reinagel [SMTP:@spam@daverKILLspamspamAUSPEX.COM]
wrote:
{Quote hidden}

1998\03\31@234726 by Scott Newell
flavicon
face
>to the same RAM location based on their usage.  For example, sub1 uses a
>byte variable called Byte1, and sub2 uses a byte var called Byte2.  The
>compiler analyzes the subroutine call structure, and if sub1 never calls
>sub2 (even indirectly) and sub2 never calls sub1, then Byte1 and Byte2 will
>use the same physical RAM location.

That's great, as long as they're both auto variables.  If one is static,
you've got trouble.


I hacked together a simple dead code finder today.  It seems to work, as
long as you don't use computed gotos, pclath, or more than 2k of program.
I'm kinda stuck on the pclath--I couldn't think of any easy way to
determine it's value without simulating most of the program.

I certainly wouldn't just let it loose on a hex file, but it's kinda cool
to look through the list files and see what it picks out as unreachable.


newell

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...