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: [email protected]
> [mailto:[email protected]] On Behalf Of Matthias
> Weingart
> Sent: Thursday, June 24, 2004 2:14 AM
> To: [email protected]
> 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
> > > [email protected]
> > > 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
> > [email protected]
> > 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
> [email protected]
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Matthias
