Execution Profiling?

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using ICCAVR V7 and am wondering of anyone has come across a method of profiling code execution on an AVR.

Of course I could setup a high speed timer and sample the return address on the hardware stack and bin the adress range hits but this approach is invasive and has other setbacks.

Is there a profiling tool available for the JTAG ICEMKII?

Thanks,
DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The most accurate way that I've found is to toggle a port line and check responses with a scope. It could be somewhat time consuming if you wanted to profile "everything". But normally, I only check the critcal timing anyway.

Also, If you have a variable persistance scope, you can check timing variations due to longer code path lengths, interrupt response time jitter, etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats a good approach I've used in the past. I've got code from a consultant and am trying measure where the bloddy thing wasting so much time.

thank yoy GA!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danafraymond,

I have just finished a design that required me to pay attention to how much time was being spent on several events as well how often the main body of the program was repeating. I just connected a few LEDs to a spare port and toggled them on and off depending on what the unit was up to. This gave some indication of what was going on at multiple points of the program. When I need to know the exact amount of time spent I just hook up my bench counter/timer.

The other option is to use one of the timers/counters if you have a way to read it back. Or display the count.

A

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heres one I wrote

Attachment(s): 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Heres one I wrote

You RULE Bob Gardner!
Your Profiler is EXACTLY what I would have done.

Thank you very much. You should probably make this available as a project for others.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hate the project section mess. If someone does a search for profiler, hopefully, they will find that file right there 2 messages up.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner,

Can you provide any details about your programs use? It looks like you spent a bit of time on it. A new tool is always handy.

Thanks,

A

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bob,

Are you sure about that?

  if(profon){
    nxtl=*(unsigned char *)0x005d; //lo 57
    nxth=*(unsigned char *)0x005e; //hi 08
    nxt= (nxth << 8) | nxtl; //sp at 5d,5e... points to nxt avail  0x857
    pch= nxt+1; //+1=ret add from profile sub
    pcl= nxt+2;
    pc=(pch<<8) | pcl;
    b=pc/binsize;    //which bin pc is in  0-31
    bins[b]++;       //bump up this bin
    if(bins[b] >= BINMAX) profon=0;          
  }

surely the pc= should be picking up *pch and *pcl as it needs to access the two bytes of the return address on the stack, not store where on the stack they are located.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No pushing when the isr starts?

I could be wrong, but I think it reduces to-

pc=((SPL+1)<<8) | (SP+2);

and I'm not sure what use that will be. But before this is corrected, I think you need to figure out how much stack is used in the isr preamble as bytes pushed on the stack are of no use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I knew if I tossed that teaser out there a couple of guys a lot smarter than me would eyeball it. If either one of you has a bug fix or improvment, please post it. My dim old recollection was I sort of fiddled and fiddled with it and got it where it looked like it was spitting out something about right, then it sat.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bob,

As Curt says the problem here is knowing which other registers the compiler may have chosen to preserve on the stack on entry into the ISR. The chances are the return PC is not simply at *(SP+1). This kind of "profiling on a timer tick" is one of the few occasions where I think you'd almost have to write the ISR in assembler to be absolutely sure it remains invariant for all time and you are absolutely sure about the depth of the stack at the point you "sniff" it.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

trying to upload the lst file... renamed it to txt

Yo Dana... did it compile? Does it seem to be sort of working?

Cliff.... that nxt variable is the sp in ram... it points to the next instruction after the int handler returns.... thats the pch and l I'm sorting into bins....

Andrew... look at the next to the last function... thats the documentation... f a and z... hopefully self explanatory?

Attachment(s): 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Bob,

As Curt says the problem here is knowing which other registers the compiler may have chosen to preserve on the stack on entry into the ISR. The chances are the return PC is not simply at *(SP+1). This kind of "profiling on a timer tick" is one of the few occasions where I think you'd almost have to write the ISR in assembler to be absolutely sure it remains invariant for all time and you are absolutely sure about the depth of the stack at the point you "sniff" it.

Cliff

Perhaps I'm missing something here, but..
ICC uses seperater stacks for the returm address )hardware stack) and local storage(software stack). I thought the registers are preserved on the software stack ad not the hardware stack, making it easy to do this technique.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I looked at my 1991 M68000 profiler. Yes the ISR that logs the current PC into "bins" is written in assembly. It uses just D0.L and A0, so obviously has to read past these pushed values to get the PC.

I see no great problem with Bob's approach, but it would be safer to just put this ISR in assembly. Otherwise you have to do some serious compiler documentation reading.

Bob,

This looks seriously good fun. You should just be able to wrap this around a lot of regular AVR programs by just choosing the relevant AVR big brother. And in my experience of M68000 you do not really affect the run-time speed.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did a bunch of 68000 work (seems like decades ago.... yep, it was decades ago) and the darn 68000 didnt have the darn register file and the stack pointer sittin right there in ram making it easy to look at. Them Vikings are pretty smart I think.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
trying to upload the lst file... renamed it to txt

Yo Dana... did it compile? Does it seem to be sort of working?

Cliff.... that nxt variable is the sp in ram... it points to the next instruction after the int handler returns.... thats the pch and l I'm sorting into bins....

Andrew... look at the next to the last function... thats the documentation... f a and z... hopefully self explanatory?

Bob... I haven't passed it on to the programmer doing the research just yet. I'll report when I have more info.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
I did a bunch of 68000 work (seems like decades ago.... yep, it was decades ago) and the darn 68000 didnt have the darn register file and the stack pointer sittin right there in ram making it easy to look at. Them Vikings are pretty smart I think.

I will never understand the American language.

_newirq:
	move.l	d0,-(sp)
	addq.l	#1,_tottim
	move.l	6(sp),d0	; d0=0,sr=4,pc=6
	sub.l	exeads,d0
	bmi	donirq
	cmp.l	size,d0
	bgt	donirq
	move.l	a0,-(sp)
	addq.l	#1,_usrtim
	movea.l	imgbuf,a0
	adda.l	d0,a0
	addq.w	#1,(a0)
	movea.l	(sp)+,a0
donirq:	move.l	(sp)+,d0
	move.l	oldirq,-(sp)	; jmp (oldirq)
	rts

The ISR examines the PC for being within a user code window or in the operating system, and logs the required occurrence.

I do not follow any advantage / disadvantage of reading a CPU register via a direct memory map, or via the stack.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
ICC uses seperater stacks for the returm address )hardware stack) and local storage(software stack).

Ah an interesting fact I wasn't aware of - in that case Bob'd code WAS close - just required indirection through the stack pointer (+1) and it should be "job done" (even in C)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, seeing as how you have to compile the profiling part into one of your programs, Bob just has to worry about the ImageCraft model.

Profiling a foreign child via an operating system does not care how the child is composed. And the child does not know that anyone is spying on her anyway.

I still think that this is a project worth investigating. Especially if you can just "wrap" it around any source code for anyone's compiler.

David.