On Mon, May 10, 2010 at 02:49:33PM -0400, David Sarrazin wrote:
> Yes, I kinda flunked kindergarten 101 with that comment.  So then the
> question becomes "how can an application determine how many times
> ClockCycles() has wrapped?"

You can't, but

	diff = ClockCyles() - start_cycles;

will produce the right answer as long as you haven't exceeded a
cycle count of 0xffffffffffffffffULL. Making that work is why we scale
up the value when the hardware doesn't provide a full 64 bit counter.

-- 
Brian Stecher (bstecher@qnx.com)        QNX Software Systems
phone: +1 (613) 591-0931 (voice)        175 Terence Matthews Cr.
       +1 (613) 591-3579 (fax)          Kanata, Ontario, Canada K2M 1W8

> -----Original Message-----
> From: David Sarrazin [mailto:community-noreply@qnx.com]
> Sent: Monday, May 10, 2010 2:50 PM
> To: ostech-core_os
> Subject: RE: ClockCycles() wrapping
> 
> 
> 
> 
> > -----Original Message-----
> > From: Neil Schellenberger [mailto:community-noreply@qnx.com]
> > Sent: May 10, 2010 2:44 PM
> > To: ostech-core_os
> > Subject: RE: ClockCycles() wrapping
> >
> > On Mon, 2010-05-10 at 14:00 -0400, David Sarrazin wrote:
> > > > But it cannot be negative (because it is unsigned), so I
> > need to do
> > > > some tricks to make this expression correct. I am not
> > that good a C
> > > > if somebody knows easy way to do it let me know.
> > >
> > > How do you determine timeZero?  Is it an earlier call to
> > ClockCycles()?
> > > Ignoring the SMP case, ClockCycles() will always return a >= number
> > > than a previous call to ClockCycles().
> >
> > Well, at least until it wraps around ;-)
> 
> 
> Yes, I kinda flunked kindergarten 101 with that comment.  So then the
> question becomes "how can an application determine how many times
> ClockCycles() has wrapped?"

Given a 4G clock, the low 32 bit will wrapped after 1 seconds, that means the 32 upper bit are the number of seconds the
 value can represent and it`s a VERY long time ;-)  Something like 120 years.  

> 
> 
> >
> > > > a) Can I ask for ClockCycles() from the same cpu always, not the
> > > > current one?
> > > > b) Can I sync them programmatically?
> > > > c) Can I sync them on startup on target some how?
> > >
> > > Other than binding the instrumented code to a fixed CPU?  I
> > don't' know.
> >
> > There is no generic way to sync between processors.  (They
> > may not even be running at the same rate....)
> >
> > > > 2) On some CPU's ClockCycles is inline function, and when
> > I compile
> > > > app with --instrument-functions it instruments it! I have
> > re-entry
> > > > prevention but it still sucks because it is a lot of overhead. I
> > > > tried to add another declaration of ClockCycles with
> > __attribute__
> > > > ((no_instrument_function)) but it does not help - it has to be in
> > > > original declaration I guess.
> > > > Any other suggestion (besides fixing the header)?
> > >
> > > Is it enough to change
> > services/system/public/<cpu>/neutrino.h and add
> > > the __attribute__ (no_instrument_function)?  For at least ARM, the
> > > function body is actually in an asm file in
> > > lib/c/kercover/arm/ClockCycles.S
> >
> > Instrumentation would only apply to inline C code, so pure
> > assembly wouldn't be a problem, C declaration
> > notwithstanding.  The attribute should have done the trick,
> > provided it appeared before the definition was encountered by
> > the compiler.  (The simplest way to arrange for this is, of
> > course, to change the header -- which is almost certainly
> > what ought to be done.)
> >
> >
> >
> >
> > _______________________________________________
> >
> > OSTech
> > http://community.qnx.com/sf/go/post54096
> >
> >
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post54098
>