in the example you provided you *should* use volatiles.
otherwise the prg flow hangs.
You should not declare all vars as volatile.
There are some other ways to avoind unnecessary volatiles reads/writes.
~d
On Wednesday 23 October 2002 12:16, David Brown wrote:
> The answer is very simple - you *should* be pernickety about variables that
> you don't want optomised out. The term "volatile" tells the compiler that
> a variable's value may change without it knowing about it, or have other
> side effects - thus the compiler must read or write it exactly as often as
> specified in the source code. This is particularly important for variables
> that are changed (or read - it works both ways) within interrupt routines.
> It also applies to hardware registers, which are all effectively volatile
> in the header files.
>
> However, making all variables "volatile" by default would be using a cannon
> to swat a fly. The resulting code would be poor, full of unnecessary reads
> and writes to memory and with the compiler unable to perform all its neat
> optomisation tricks. Declare variables as volatile when necessary, but not
> otherwise.
>
> > I'm having a lot of trouble with the way GCC treats various objects. In
> > particular, if I want to pass falgs about in my program, unless I'm very
> > pernickety it optimeses them out, assuming they aren't wanted. For
> > example: (ticks is incremented by an interrupt)
> >
> > void wait_ticks( unsigned int nticks)
> > {
> > unsigned int t;
> >
> > t = ticks;
> >
> > while( (ticks-t) < nticks)
> > ;
> > }
> >
> > If I don't declare ticks as volatile, I get this:
> >
> > 000047d4 <wait_ticks>:
> > 47d4: 0e 43 clr r14 ;
> > 47d6: 0e 9f cmp r15, r14 ;
> > 47d8: fe 2b jnc $-2 ;abs dst addr 0x47d6
> > 47da: 30 41 ret
> >
> > which just hangs.
> >
> > Is there any way of forcing the compiler to assume everything is
> > volatile? Why does it do this anyway?
> >
> > Paul Burke
> >
> >
> > -------------------------------------------------------
> > This sf.net emial is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
>
> http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote
>
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
> -------------------------------------------------------
> This sf.net emial is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
/********************************************************************
("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
`6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
(_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
_..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
(il),-'' (li),' ((!.-' +7 (812) 3468202, 5585314
********************************************************************/
