----- Original Message -----
From: "John Pote" <johnp...@blueyonder.co.uk>
To: "GCC for MSP430 - http://mspgcc.sf.net";
<mspgcc-users@lists.sourceforge.net>
Sent: Monday, July 03, 2006 1:11 PM
Subject: Re: [Mspgcc-users] Code generation question
> Hi everone,
>
> My thought on the following snippet from the prev mail:-
>
> >> > By the way, I think it's also better to change your initial example:
> >> >
> >> > unsigned two;
> >> > void foo(void)
> >> > {
> >> > two = P6IN + P6IN;
> >> > }
> >> >
> >> > into:
> >> >
> >> > unsigned two;
> >> >
> >> > void foo(void)
> >> > unsigned int tmp;
> >> > {
> >> > tmp = P6IN + P6IN; // <----- tmp = 2 * P6IN; // <----- tmp =
> >> > P6IN; tmp+= P6IN;
> >> > two = tmp;
> >> > }
> >> >
> >>
> >> You may think that, but no one will agree with you. There is no
benifit
> >> in
> >> introducing an extra temporary variable here - it simply makes the code
> >> more
> >> verbose and thus less readable. You are writing in C, using a
compiler -
> >> you are not writing everything out explicitly in assembler. It is up
to
> >> the
> >> compiler to figure out what extra temporary variables it needs - in
fact,
> >> the compiler will probably internally use exactly the code you have
> >> written
> >> out explicitly. And unless you are specifically compiling with no
> >> optimisation, the code generated is identical with or without the "tmp"
> >> variable.
> >>
> >
>
> If an interrupt routine was to access var 'two' a side effect may occur in
> very rare and extremely difficult to find circumstances using the first
> version of 'foo'. Suppose the interrupt occurs inbetween the first P6IN
read
> and the second read. Also suppose the compiler decides to use 'two' as a
> temp rather than allocate another temp (I know the 430 has plenty of
> registers but can you guarantee one is spare for a temp?) Now for this
short
> moment of time the interrupt routine sees the value of 'two' before it is
> complete (ie as though foo had been writen 'two = P6IN'). In general this
is
> probably not what the coder wants.
>
> I came across a similar problem writing for another processor architecture
> (er OK I admit it a PIC). The line
>
> P2 = a+b+c;
>
In this case, either P2 was declared incorrectly (i.e., it was not declared
as a volatile), or the compiler generated incorrect code.
In general, yes, the compiler is free to use "two" to store half the
calculation. In practice, of course, it will not - as you say, it will use
a register (on the PIC, it makes sense to use the global as a temporary
storage, since it has no real registers). But the only way to make
absolutely sure that "two" is not written in two steps is to make "two" a
volatile as well.
mvh.,
David
> was optimised by the compiler to use the port P2 as a temp. However, P2
was
> a set of control signals to various parts of the system. Having some of
them
> toggle as a result of P2 being part of the summation process was
definitely
> not what I wanted. In hardware edges can be as significant as steady
values.
> A deliberately introduced temp solved the problem.
>
> My conclusion is that to program defenceively always use statements that
> refer to a port only once.
>
> That's it, hope it helps the discussion,
>
> John Pote
>
