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
