your mail

[mikebw at colossus.bilow.com (Mike Bilow)]

There is no point to profiling assembly instructions.  The whole point of
profiling is to measure time, and there is no obvious correspondence
between raw instructions and execution time.  In fact, on modern CPUs
which make aggressive use of pipelining and superscaling, there is no way
to predict with any reasonable degree of confidence how long a non-trivial
code path will take to execute, especially on a platform such as Linux
which uses pre-emptive multitasking.  In other words, if you write an
optimization which depends upon some core feature of the instruction
sequencer, such as unrolling loops, then your pipelining will be ruined if
the machine comes under heavy load and your task is given only short time
slices on the scheduler.  Something like this might be useful on a Z-80,
but not on anything that can run Linux.

I cannot imagine why you want to do it, but use the '-g' switch to gcc
when compiling to assembly and then use the '-a' switch to as when
assembling, and you should get an intermixed source listing.  See 'man as'
for more details or 'info as' if you have the info browser installed.

-- Mike


On 2000-05-29 at 18:12 +0530, Gopal.J wrote:

> 	Iam trying to profile my code and find how many assembly instructions my 
> code took before finishing the work. Normal profilers like gprof, tcov, 
> gcov doesnt give profiling out put in assembly counts. Can any one suggest 
> any tools for doing it.
> 
> I have one more request, when I generate assembly code using "gcc -S" 
> option, only assembly code is generated. I would like the c lines to be 
> avilable in comments before the respective assembly code of the c line. 
> What option I should use with gcc.


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).