[net.sources.mac] Profile program for M68000 instruction statistics Part 1 of 3

davet@oakhill.UUCP (Dave Trissel) (11/20/85)

Posting 1 of 3.

------Instructions for using the Profile trace program------

Motorola is requesting M68000 instruction execution statistics for use in
deciding optimizations in future M68000 family processors.  To that end this
Macintosh application has been written which when executed installs a trace
handler and 192k instruction frequency table.  The program's name is Profile.

Once the menu is chosen to install the table the next program launched by the
Finder will be automatically traced until it terminates.  After this the
Profile program when re-executed will allow the table to be stored on disk and
optionally reused or taken back out.  Profile will only work on a 512k (or
bigger) Mac and will not run with Switcher or Macsbug.  The program does not
support either the Lisa or Maxintosh XL under Macworks.

When storing the statistics table on disk Profile compresses it from its 192k
size to only about 10k.  At this point you can Binhex it and mail it back
to Motorola and we will use the results in our studies to decide which
instructions whould be optimized in future M68000 family processors.

There are several points to keep in mind when running an application which
is being traced for statistics:

  1) Always be prepared to immediately indicate the next action for the
     application to do.  This avoids having the loop in the application which
     waits for user commands taking up an inordinate amount of instruction
     counts and thus biasing the results.  After all, we aren't interested
     in making 'wait for something to do' loops run faster but instead the
     code where something useful is being done.

     To this end, some good things to execute would be compilers and such
     where the application runs completely by itself (or almost so.)  If
     you run applications like MacPaint or MacDraw the results will not be
     good unless you very quickly perform all actions necessary.  For these
     type programs it is good to rehearse what you are going to do so that as
     little time is spent in the program's 'wait for user' loop as possible.

  2) Some programs exhibit very strange anamolies such as double-clicks not
     working when chosing a file from the Open dialog box.  In these cases
     you will just have to use the appropriate buttons instead.  It is good
     to do a run-through of your application under trace and then reset the
     table and do a final run for better results.

  3) Some programs act so strange that they may not be traceable.  For example
     I tried MacWrite and it jumped out of trace mode shortly after starting.
     Another program I tried did not exit to the finder properly and so the
     Finder ran under trace mode itself  (which is fine but then you have to
     run yet another application so that when it quits tracing gets turned
     off.)

The bottom line is to try out an application first and see if it is traceable.

Once you have the table stored, Binhex it to me with a short summary of what
it was you executed.  If a compiler then mention which one and about how many
lines long the program's source.  If a spreadsheet mention which one.  We will
combine all the data and use it for extensive analysis to determine just
which instructions get executed most frequently.  That will help us build
even more optimized chips in the future.

I am posting the source code (MDS Assembly) in a following message and
the Binhexed version in a third.  Software houses may want to perform or use
the trace routine to do their own analysis and the source code has comments
indicating the format of the compressed stored table.

Oh, and the program is just fun to run.  Watching Quickdraw in slow-motion
is a treat.

Many thanks,

  -- Dave Trissel    Motorola Semiconductor Inc.,  Austin, Texas
		     {ihnp4,seismo}!ut-sally!oakhill!davet
		     (512) 440-2137