Related articles |
---|
Static analysis of code for "flop counting"? fouts@orville (1987-04-17) |
Re: Static analysis of code for "flop counting"? allegra!utzoo!henry (1987-04-22) |
Re: Static analysis of code for "flop counting"? think!ames!ucbcad!ucbvax!decwrl!mips!sjc (1987-04-23) |
Re: Static analysis of code for "flop counting"? harvard!seismo!watmath!orchid!atbowler (Alan T. Bowler [SDG]) (1987-04-26) |
Re: Static analysis of code for "flop counting"? eugene@ames-pioneer.arpa (Eugene Miya N.) (1987-05-06) |
Re: Static analysis of code for "flop counting"? eugene@ames-pioneer.arpa (Eugene Miya N.) (1987-05-06) |
Re: Static analysis of code for "flop counting"? allegra!utzoo!henry (1987-05-13) |
Date: | Wed, 22 Apr 87 03:03:43 EDT |
From: | allegra!utzoo!henry |
References: | <1299@ames.UUCP> |
> ... Another approach that
> I have seen is to run the source program through a preprocessor which adds
> tracing code into the source, then compile the resulting program with the
> regular compiler.
Yet another approach, used (although not for this purpose, I suspect) by
the MIPSCo people, is to run the object program through a postprocessor
that inserts tracing code. For example, before every "add float"
instruction, insert an instruction that bumps an "add float" counter.
(I suggest "before" rather than "after" because then the condition codes
don't get messed up, or at least not as badly -- beware optimizing
compilers rearranging code!)
If you did it at the assembler level rather than the binary level, this
might not be too hard. That might be awkward if libraries are involved,
though.
This gets you fast, accurate counts without compiler cooperation.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.