VxWorks gcc --volatile flag

[jonathan.back]

Thanks for the excellent reply.
Unfortunately you've misunderstood what I was asking...
I didn't mean :
main()
{
	volatile int x=10;
}
I mean the GCC command line option called -fvolative -fnovolatile.
%> gcc -fvolative crazycode.cc -o crazypaving

This option seems to generate really whacko code that does a copy of an
object onto the stack when it is deleted.  What on earth is it doing
that for? It blows my stack every time!!!
-Thanks


In article < 37e1b219.3035073@news >,
  A-Du-ReaNOGI@EsperNOGO.Com (Art Du Rea: NoGargbageIn:NoGarbageOut)
wrote:
> On Thu, 16 Sep 1999 18:25:02 GMT, jonathan.back@siara.com wrote:
> >Does anyone know what the --volatile flag actually does and the
reason
> >for it?
> >Looking at the assembly - it seems to copy the entire object onto the
> >stack when a delete is called. Isn't this a bit crazy!
> >(We are having MEM_PART_FREE errors when using the --volatile flag,
> >maybe because of stack corruption due to copying of large object onto
a
> >small stack)
>
> Jonathan ...
>
> The "volatile" declaration is a warning to the compiler, usually to
the optimizer:
> Compiler, BEWARE!  The value of the following variable can NOT be
predicted by
> initialization or code execution alone.  Consider the situation of a
hardware time-of-day
> clock register or a disk DMA read buffer.  There is no way the
compiler can know what is in
> the clock register regardless of what the code does to the register
... it is strictly a
> hardware function.  If you loop on the clock register continuously
reading it and waiting
> for the seconds value to change, if you didn't mark the register as
volatile, the optimizer
> would probably only generate code to read the register one time (if at
all) and consider "if
> I read this thing once I KNOW what is in it ... why bother reading it
more than once?".
> Obviously, your code would hang and never get past the wait loop.
Setting the variable
> "volatile" tells the compiler it MUST read the variable EVERY TIME it
is called for
> regardless of what code execution says it should be.  The disk DMA
read buffer is a similar
> situation.  Initialize the buffer to zero, go off and to some munging
with the hardware
> registers, and then read the buffer.  The compiler already knows that
the buffer contains
> zeros because is was zeroed when it was created and it has never been
written to.  AHA!!!
> The hardware actually has snuck a sector of data into the buffer, and
the compiler has NO
> way of knowing that ... UNLESS you mark the variable as volatile.  Now
the compiler isn't so
> opinionated because it has been told not to rely on it's instincts or
opinions about what is
> in the volatile variable.  The only thing the compiler can do is
complain ... why do these
> dumb programmers make me read the same thing over and over again even
though I know what I
> just wrote there!
>
> That should make sense ... Hope it helps.
>
> All the best, and ENJOY!
>
> Art Du Rea
> Knoxville, Tennessee, USA
>
> (Remove NOGI:NOGO for direct e-mail)
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.