Re: profiling on sh

[<kewarken at qnx dot com>]

Stephen Clarke <Stephen.Clarke@st.com> said:

> kewarken@qnx.com wrote:
> > 
> > Given the delay slot, could one also do this?
> > 
> >      jsr @r0
> >      mov.l lab,r0
> >      .align 4
> >      .long .LP0
> >  lab:
> >      .long _mcount
> 
> Unfortunately not - the reason for having the delay slot is to allow
> the processor time to go get the instructions at the target address,
> so it needs to know the target address when it starts executing the jsr.

That was one of those dumb emails that I wished I could retract - obviously 
that delay slot optimization only makes sense if you're loading a register 
that won't be used until you hit the target of the branch.  DUH! ;-)
> 
> > I'm also wondering about the label 'lab'.  Does that need to be done every
> > time and does the label need to be unique?  This profiling code is 
inserted
> > with every function call so I'm wondering if there's some way to globally
> > insert this.
> 
> The problem here is that the mov.l lab,r0 instruction is actually a
> pc-relative load:
> 
>   mov.l @(lab-($+4), pc), r0
> 
> and the value of lab-($+4) has to be in the range [0,512).  
> So you need to make sure that lab is close enough to this mov.l instruction.
> 
> The simplest and most _inefficient_ thing to do, it to have a unique copy of
> the label and _mcount literal for  each call.  This will bulk the code out,
> but you're already doing that with all the calls to _mcount.  If you're 
really
> concerned about code size, then the original trapa scheme is much more
> space efficient.

That was part of my original question.  What exactly is the trapa supposed to 
be doing?  I don't see a handler for that anywhere or know of how to set it 
up.  I'd love to just be able to set trapa #33 to call mcount but I don't 
know where that would be done...OS level or code level.

> 
> > Both the arm and thumb just do a 'bl mcount' but that didn't look to me 
like
> > the way functions were called on sh
> 
> Sorry - you're right.  I'd forgotten that thumb does not need to
> embed an address literal in the code in order to make a function call.
> 
> Steve.
> -- 
> Stephen Clarke, Principal Engineer, SuperH Inc.
> Phone:1-408-922-4062, Fax:1-408-954-8507, mailto:Stephen.Clarke@st.com
> Mail:  SuperH Inc., 3801 Zanker Rd., San Jose, CA 95134, USA.
> 



--