Fellows,
I came with the following idea:

1. Background.
===========
Currently, profiling is not implemented in mspgcc and only the way to check 
time/cycles requirements is to count execution cycles in a simulator. 
However, sometimes, I have to count cycles, cause some of my operations are 
life critical and require high optimization.
The possible optimization in gcc is not suitable for cross-compiling and 
'small' targets. However, we got gdb's buit in simulator where we can do 
whatever we want.

2. Idea
======
On _every_ function entry record currect cycle counter. On every function exit 
record cycle counter. Record them along with a function baf_vma address.
For example:
We got the following code which utilizes two functions:
        void a() {}
        void b()        { ... a(); ...}
At very first instr of b() record 'b' address. Assume it is 0xbebe.
At very first instr of a() record 'a' address. Assume it is 0xbaba.
The same at exit.
The we'll get following 'trace' information (saved to the file in, say, binary 
format):
        0xbebe enter [cycle couter]
        0xbaba enter [cycle couter]
        0xbaba exit [cycle couter]
        0xbebe exit [cycle couter]
Also, this file can (should contain symbols information)

The some external program will analyze this trace and represent call flow.

3. Implementation:
==============
To achieve this capability, I propose new assembler pseudo operations:
        .profile_enter
        .profile_exit
Which first one will be placed at the beginning of the function prologue, 
another one -- before 'ret' (reti) instruction in assembly code.
So, function will look like:

.global f
        .type f, @object
f:
        .profile_enter
        push r10
        ...
        pop r10
        .profile_exit
.Lfe1:
        ...........

GNU assembler will substitute some invalid code to the binary file, when hits 
these two pseudo. User can pass these codes to the assembler via command line 
options:
-mpge 0x0001, -mpgx 0x002 (-e, -x as short options)
for .profile_enter and .profile_exit respectively.

Then, when this binary runs in a simulator, instead of generation an error 
message, profiling info will be saved.

4. Current Status:
==============
Assembly part is implemented.
GCC's part will be done next week.
Simulator has not been touched.
GUI for profile information browsing already exists. I wrote it when developed 
a profiler for native gcc profiling (under bsd). This is written with QT 
(www.trolltech.org) and I'll port it to our needs next week. QT is a portable 
stuff and can be ported to M$ windoze with minimum changes.

+++++++++++++++++++++++++++++++++++++

What do you think guys???

Cheers,
~d


























Reply via email to