Fellows,
Implementation idea bad.
The new one is:
We define new section ".profiler" which holds all profiling information.
We define new pseudo operation .profiler which will instruct assembler to
add new profile entry to the object file.
Pseudo-op format:
.profiler flags,.Lprofile_address,symbol_to_profile, cycle_corrector
where 'flags' is a combination of the following chars:
s - function entry
x - function exit
i - function is in init section
f - function is in fini section
l - library call
c - libc standard call
d - stack value demand
I - interrupt service routine
P - prologue start
p - prologue end
E - epilogue start
e - epilogue end
'""' optional: "sil" == sil
.Lprofile_address - an address at which profiling information should be
saved
symbol_to_profile - function address
cycle_corrector - a value which should be added to the cycle counter
For example:
------------------------------
.global fxx
.type fxx,@function
xxx:
.profiler "scdP", fxx, fxx, 0 ; function entry.
; we demand stack value to be saved
push r11
push r10
push r9
push r8
.Lpstack_check1:
.profiler "dpc",.Lpstack_check1,fxx,0 ; demand stack value at this
point (prologue end)
mov r15,r8
....
.Lprof_exit1:
.profiler xcde,.Lprof_exit1,fxx,3 ; exit + add 3 to the cycle counter
ret ; cause 'ret' insn takes 3 cycles
-------------------------------
The ".profiler" pseudo can be evaluated as:
.pushsection
.section .profiler, "ax",@progbits
.word flags
.word .Lprofile_address
.word symbol_to_profile
.word cycle_corrector
.word spare ; currently zero.
.popsection
This profiling approach does not produce any overhead and absolutely
harmless.
So, even profiled code can be uploaded to the MCU.
I'll do some more tests then commit changes.
Cheers,
~d
P.S. Steve, can you add this to the current docs? Thanks.
This approach will require some modification on simulator, which I'll do
shortly. (I do not have 'real' OS installed in my office, and m$ does it
deadly slow. So, I got just a few minutes per day which I can do something
usefull :)
On Friday 06 August 2004 23:00, Dmitry wrote:
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
