home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 6 / AACD06.ISO / AACD / Programming / ProfilePPC / ProfilePPC.readme < prev    next >
Text File  |  2000-01-09  |  5KB  |  141 lines
  1. Short: Profiler for PowerUp ppc.library progs
  2. Author: Peter McGavin  (p.mcgavin@irl.cri.nz)
  3. Type: dev/misc
  4. Uploader: Peter McGavin  (p.mcgavin@irl.cri.nz)
  5. Version: 0.0
  6.  
  7.  
  8.  
  9.                             ProfilePPC 0.0                   9 Jan 2000
  10.                             --------------
  11.  
  12.  
  13. This archive contains a simple profiler I wrote for PowerUp ELF object
  14. programs.  Both source code and binary of ProfilePPC are included.
  15.  
  16. WARNING: IN ITS CURRENT STATE, PROFILEPPC WILL LIKELY HANG OR CRASH
  17. YOUR AMIGA EVENTUALLY.  If anyone knows how to fix the problems,
  18. described in the technical notes below, please let me know.
  19.  
  20. A profiler gathers statistics for how long the program spends in each
  21. subroutine.  You can find out which subroutines need speeding up the
  22. most.
  23.  
  24. This profiler works by sampling the PPC PC (program counter) at
  25. regular intervals while the program runs, like SAS/C's lprof/lstat.
  26. That is different to some other profilers which insert code in the
  27. prologue and epilogue of every subroutine.
  28.  
  29.  
  30.  
  31. REQUIREMENTS:
  32. -------------
  33.  
  34. You need an Amiga with a PPC, a recent version of ppc.library from
  35. Phase5 (I use version 46.28) and an ELF object program linked with
  36. ppc-amigaos-ld to profile.  Sorry, ProfilePPC doesn't seem to work
  37. under WarpOS with Frank Wille's emulation library.
  38.  
  39.  
  40.  
  41. USAGE:
  42. ------
  43.  
  44.     ProfilePPC <program> <program-arguments...>
  45.  
  46. ProfilePPC runs the ELF program with the given arguments.  While the
  47. program is running, it samples the PPC PC every 400ms.  After the
  48. program exits, ProfilePPC writes a table of statistics to stdout,
  49. including the name of each subroutine and the number of counts in that
  50. subroutine.  Only subroutines with at least 1 count are displayed.
  51.  
  52.  
  53.  
  54. SOME MINOR GLITCHES:
  55. --------------------
  56.  
  57. Only global symbols known by PowerUp are used.  Subroutines declared
  58. static may not show up.  Extra debugging information in the object
  59. file isn't used.  ProfilePPC invents names for the spaces between
  60. subroutines it knows about, so you might be able to work out where the
  61. PC is from the output, if you know the order your subroutines are
  62. linked.
  63.  
  64. The sampling interval is large, 400ms, because otherwise the
  65. probability of a crash or hang is too great.  That means counts
  66. are low unless your program runs for a long time.
  67.  
  68. The PPC program under test runs slower and less smoothly than usual
  69. because it is being stopped and restarted frequently.
  70.  
  71. Only plain ELF object programs linked with ppc-amigaos-ld work.  And
  72. then only if they run as a single task.
  73.  
  74.  
  75.  
  76. TECHNICAL NOTES:
  77. ----------------
  78.  
  79. When I started, I thought this would be a straightforward project.
  80. After all, PowerUp provides ppc.library calls to load an ELF object,
  81. read the symbol table, start the program asynchronously and sample the
  82. task's PC while it runs.
  83.  
  84. However, sampling the task's PC turns out to be a major headache.  The
  85. obvious approach of:
  86.  
  87.         PPCGetTaskAttrsTags (ppctask, PPCTASKINFOTAG_PC, &pc, TAG_END)
  88.  
  89. doesn't work.  It always returns the same PC for a given task,
  90. something like 0xfff02058.
  91.  
  92. My next approach was to try sampling the link register, LR, instead,
  93. with:
  94.  
  95.         PPCGetTaskAttrsTags (ppctask, PPCTASKINFOTAG_LR, &pc, TAG_END)
  96.  
  97. Since the PPC always stores the return address in the LR, I thought
  98. this might just work.  At first it seemed to.  But then I noticed it
  99. never returned an address in a CPU-intensive routine.  It seemed to
  100. return the address where the PPC task was last in a WAIT state.  The
  101. results aren't very useful.
  102.  
  103. OK, ppc.library provides PPCStopTask() and PPCStartTask() to
  104. temporarily pause and restart a PPC task.  Furthermore, PPCStopTask()
  105. causes an exception.  The PC can be extracted from the exception
  106. message passed to a custom exception handler.
  107.  
  108. So, that was my next attempt.  The 68k task calls PPCStopTask(), my
  109. exception handler extracts the PC and Signal()s the 68K task.  The
  110. 68k task Wait()s for the signal, then calls PPCStartTask() with
  111. PPCTASKSTARTTAG_RUN.
  112.  
  113. Oops, this crashed or hung immediately.  On the other hand, stepping
  114. through slowly in the CPR debugger, it seemed to work.  Run it fast
  115. and it hung again.
  116.  
  117. After lots of experimentation, I found it seems to depend on the PPC
  118. task's state whether it works or not.  If the PPC task is doing
  119. something CPU-intensive, i.e, in RUN state, it seems to work just
  120. fine.  If it's doing I/O, i.e, in WAIT state, PPCStopTask() stops the
  121. task all right, but no exception occurs and the task can't be
  122. restarted.
  123.  
  124. So, the way it works now is: 
  125. 1) Get the PPC task's state;
  126. 2) If it's in RUN state, get the PC with PPCStopTask()/PPCStartTask()
  127.    and exception handler;
  128. 3) If it's in WAIT state, get the LR with PPCGetTaskAttrsTags()
  129.  
  130. Although this seems to work most of the time, there is still a major
  131. problem.  If the PPC task's state changes from RUN to WAIT between
  132. getting the state and calling PPCStopTask(), the program hangs.
  133.  
  134. Similarly, if the PPC task finishes between testing for whether it's
  135. finished and getting the state, PPCGetTaskAttrsTags() crashes.
  136.  
  137. If you know how to get around these problems, please let me know.
  138.  
  139.  
  140. Peter McGavin.   (p.mcgavin@irl.cri.nz)
  141.