Kelly,

Yes, this is what I want to do - a inline delay loop. I also had (or still
have) a function call (same as yours) for the delay, but it takes 8+(n*3)
cycles and need more space (load r15 with n and call subroutine).
The inline function call (simply inserted by a macro) needs only 2+n*3
cycles. Code is only the mov r15 with n and the jnz

#define MCLK (5e6)  //5MHz
#define NOTZERO(us) ( (us>0) ? us : 1 )
#define OS_WAIT_USMACRO(a) { \
  uint n; n=a; \
  __asm__ __volatile__("dec %0\n jnz $-2\n" :: "r" (n));  \ 
  }
#define OS_WAIT_US(us) { \
  OS_WAIT_USMACRO( (unsigned int)(NOTZERO((MCLK/1e6*us-2)/3 )) ); \
  }

But it dont work. mspgcc tie the multiple n's together, when I use this
macro multiple times in the same subroutine - I think this is a bug. 
(the macro is only useful as long as you use constants)

 Another question: how can I define a local jump label? I had to use the
$-2, because multiple _asm_ in the same function call knows the labels of the
other asm sections.

Any ideas how I can implement this are welcome.

And Dimitry - I do not have a problem with volatile - probably I choosed
the wrong subject. With volatile the code is logically correct, but big
and clumsy. 

M.

On Wed, Jun 23, 2004 at 10:34:39AM -0700, Kelly Murray wrote:
> while not specifically answering your question,
> i've used a busy loop also, and have now changed my code to
> use a subroutine instead of inline busy loops.  It takes up less space.
> But I discovered a bug in this, the "naked" caused the stack setup to
> be eliminated on entry, but it still saved the first arg value
> to the stack, which clobbered the first arg of the CALLER.
> I changed it to no declare an arg, and use r15 directly, and this
> now works and does not cause unexplained bugs..
> and is only the 3 instructions.
> 
> -Kelly Murray
> 
> 
> //__attribute__ ((naked)) void delayloop(unsigned int n) {
> __attribute__ ((naked)) void delayloop() {
>      //first arg comes in register R15
>      //the loop uses 3 cycles per round
>      //the eight cycles come from the call overhead and ret
>      //
>      //delay_time = (1/MCLK)*(8+(3*n))
>    // asm("spinloop: dec %0\n  jnz spinloop" :: "r" (n));  return;
>    asm("spinloop: dec r15\n  jnz spinloop\n ret");
> 
> }
> 
> ...  delayloop(init);
>    // i = init; asm("wloop1: dec %0\n  jnz wloop1\n" :: "r" (i));
> 
> 
> 
> 
> Matthias Weingart wrote:
> > Hi,
> > 
> > again a problem with volatile - or too much optimizing of the compiler. With
> > "volatile uint n;" my code will work as expected, but it uses space on the
> > stack and it wastes cycles. I want registers for my purpose. 
> > 
> > This is the code (Stripped down to something useless :-)
> > 
> > #define VALUE 8
> > 
> > void foo(void)
> > {
> >   {
> >     uint n;
> >     n=VALUE;
> >     __asm__ __volatile__("dec %0\n  jnz $-2\n" :: "r" (n));
> >   }
> >   //do someth.
> >   {
> >     uint n;
> >     n=VALUE;
> >     __asm__ __volatile__("dec %0\n  jnz $-2\n" :: "r" (n));
> >   }
> >   //do someth.
> > }
> > 
> > The compiler is setting N=2*VALUE before the first loop:
> > 
> >     mov     #16,    r15
> >     dec     r15
> >     jnz     $-2
> > 
> >     ... ;do smth.
> >     
> >     dec     r15
> >     jnz     $-2
> >     
> >     ... ;do smth.
> >     ret
> > 
> > but I want it to look like this:
> >     mov     #8,     r15
> >     dec     r15
> >     jnz     $-2
> > 
> >     ... ;do smth.
> >     
> >     mov     #8,     r15
> >     dec     r15
> >     jnz     $-2
> >     
> >     ... ;do smth.
> >     ret
> > 
> > any ideas?
> > 
> > thx
> > 
> > M.
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> > digital self defense, top technical experts, no vendor pitches, 
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> > 
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to