Thx ~d,

this was the trick I was looking for :-). However your for loop is longer and
bigger as a counting down one.

#define OS_WAITUSMACRO(us) { uint i; for(i=0;i<us;i++) __asm__ __volatile__ ("; 
loop %0" : "+r" (i)); }
    17d0:       0f 43           clr     r15             ;
    17d2:       1f 53           inc     r15             ;
    17d4:       3f 90 07 00     cmp     #7,     r15     ;#0x0007
    17d8:       fc 2b           jnc     $-6             ;abs 0x17d2

#define OS_WAITUSMACRO(us) { uint i; for(i=us;i!=0;i--) __asm__ __volatile__ 
("; loop %0" : "+r" (i)); }
    17b0:       3f 40 07 00     mov     #7,     r15     ;#0x0007
    17b4:       3f 53           add     #-1,    r15     ;r3 As==11
    17b6:       fe 23           jnz     $-2             ;abs 0x17b4

However the result produced by this code may change with future
compilers (or with different compiler flags) and this is the wrong
part of that solution. A explizit loop coded in assembler is much better
reproduceable.

M.

On Thu, Jun 24, 2004 at 11:07:28AM +0400, Dima wrote:
> Fellows,
> I still do not understand what's wrong with the following:
> 
> For(i=0;i<N;i++)
>       __asm__ __volatile__ ("; loop %0" : "+r" (i));
> 
> And again -- 'volatile' cannot be used to 'shape' your code.
> This just tells to the compiler that the volatile var will might be
> changed unexpectedly.
> 
> ~d
> 
> 
> -----Original Message-----
> From: mspgcc-users-ad...@lists.sourceforge.net
> [mailto:mspgcc-users-ad...@lists.sourceforge.net] On Behalf Of Matthias
> Weingart
> Sent: Thursday, June 24, 2004 2:14 AM
> To: mspgcc-users@lists.sourceforge.net
> Subject: inline delay loop, was Re: [Mspgcc-users] volatile
> 
> 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
> 
> 
> -------------------------------------------------------
> 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
        Matthias

Reply via email to