Thank you Anders !
So it is undefined in the sense that the standard does not say exactly what 
to do with it.
And therefore people cannot be sure of what will happen in different 
implementations.
The Renesas compiler seems to do what I expected ... but I shall not rely 
on it for future implementations etc...
I got the idea!
Thanks for helping me increase my knowledge
Antonio

> > NOW:
> >        a[i]=i++ ;
> > to me means : make a[i]=i and (once this has been made) increment i.
>
>The tricky point is that standard only specifies that it should be
>updated at the end of the statement (or sequence point, to be
>technical).  It is undefined if it is updated when the code writes to
>"a[i]".

On Friday 25 February 2005 01:41 am, rolf.freitag@rolf... wrote:
>  Hi,
>
>  all compilers do have pros and cons.
>  The IAR compiler seems to produce the smallest code
>  when you use much floats/doubles but is far from C99 and
>  does not produce warnings at often occurring errors like
>  a==b; (statement without effect, should surely be a=b;).
>  or
>  a[i] = i++; (undefined operation)

Not to change the subject mid swing, but why is this undefined? Wouldn't it

use the current value of i, then increment it? Is 

a[i] = i;
i++;

undefined? 

Just curious, thanks,
-Micah 

Thanks Anders, seems I should read more email before asking questions. :) 



On Friday 25 February 2005 08:00 am, Ing. Morra Antonio
wrote:
>  Thank you Anders !
>  So it is undefined in the sense that the standard does not say exactly
> what to do with it.
>  And therefore people cannot be sure of what will happen in different
>  implementations.
>  The Renesas compiler seems to do what I expected ... but I shall not rely
>  on it for future implementations etc...
>  I got the idea!
>  Thanks for helping me increase my knowledge
>  Antonio
>
>  > > NOW:
>  > > a[i]=i++ ;
>  > > to me means : make a[i]=i and (once this has been made)
increment i.
>  >
>  >The tricky point is that standard only specifies that it should be
>  >updated at the end of the statement (or sequence point, to be
>  >technical). It is undefined if it is updated when the code writes to
>  >"a[i]".
>
>  .
>
>
>
>
>
>
> 
>
>
>
>
>
>
>
>  .

Hi,

> Or, as our guest expert -- the IAR Compiler --
would formulate it:
> 
>     a[i] = i++;
>     ^
> "E:\src\cr16\test\und.c",6  Warning[Pa081]: undefined behavior:
the order of
>           read and modification of parameter "i" (or a value
reached by some
>           form of indirection through it) is undefined in this statement

that looks good but i tested some time ago with gcc 3.3.1, ICC430 1.26A,
ICC430 2.20A (latest version at that time) and MS-Visual C++ 5.0 but only 
gcc (mspgcc) produced a warning while all other compilers accepted every tested
undefined operation and undefined function call without a warning or error!
That's the reason why i diversified the sourcecode so that i can compile it
with mspgcc
AND IAR.
If i would have more time i would use lint because gcc does not complain about
things
like not thread safe code.

Regards,

Rolf

Hello;

Have you any idea how to write  c program in c-language under salvo operating
system  so that SP430 can be connected to another using ad-hoc connection and
with others by RF transceiver for multi-hop connections.

thank you


		
---------------------------------
Do you Yahoo!?
 Yahoo! Mail - Helps protect you from nasty viruses.

Hi, 

> Have you any idea how to write  c program in
c-language under 
> salvo operating system  so that SP430 can be connected to 
> another using ad-hoc connection and with others by RF 
> transceiver for multi-hop connections.

Again, no, but when you find out and implement it could you send me the
source code?  You know, I could really do with that.  Please also make
it compilable on all MSP430 compilers and, yes, I might want it on AVR
and ARM, so if you could just make it truly portable that would be just
the ticket!  It also needs to be open source.  Oh, and I might use
something other than Salvo, so it needs an RTOS abstraction layer.
Hell, I might not even have a RTOS if the customer can't afford it, so
make sure it works as a big control loop with ISRs, won't you?  I also
need extensive design documentation so I can use it.  And a reference
design so I can validate it.  This shouldn't be too much trouble for an
accomplished engineer.

Thanks!

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

Al, 

> Don't you just love all the effort that goes
into these 
> standard committees, and yet still they manage to stuff up 
> somethi ng so simple, and, to most people patently obvious?

If they "standardised" C++ without ambiguity it would be useless. 
The
same as some processors don't specify what happens when you run some
instructions, the C guys did a good job IMO.

If they had wanted to specify C with zero holes, previously-working
codes would break or not compile, and C would die a death under the
standard as Modula-2 did.  The Modula-2 standard did NOTHING to aid
Modula-2 becoming a more widespread language, and in my opinion, it
killed Modula-2 stone dead.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

Don't you just love all the effort that goes into these standard 
committees, and yet still they manage to stuff up somethi ng so simple, 
and, to most people patently obvious?

Al

Micah Stevens wrote:

>Thanks Anders, seems I should read more email
before asking questions. :) 
>
>
>
>On Friday 25 February 2005 08:00 am, Ing. Morra Antonio wrote:
>  
>
>> Thank you Anders !
>> So it is undefined in the sense that the standard does not say exactly
>>what to do with it.
>> And therefore people cannot be sure of what will happen in different
>> implementations.
>> The Renesas compiler seems to do what I expected ... but I shall not
rely
>> on it for future implementations etc...
>> I got the idea!
>> Thanks for helping me increase my knowledge
>> Antonio
>>
>> > > NOW:
>> > >        a[i]=i++ ;
>> > > to me means : make a[i]=i and (once this has been made)
increment i.
>> >
>> >The tricky point is that standard only specifies that it should be
>> >updated at the end of the statement (or sequence point, to be
>> >technical).  It is undefined if it is updated when the code writes
to
>> >"a[i]".
>>
>> .
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> .
>>    
>>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

Paul Curtis wrote:

>Al, 
>
>  
>
>>Don't you just love all the effort that goes into these 
>>standard committees, and yet still they manage to stuff up 
>>somethi ng so simple, and, to most people patently obvious?
>>    
>>
>
>If they "standardised" C++ without ambiguity it would be
useless.
>
I already thought it was! And this isn't uninformed criticism. I
spent 
nearly 18 months trying earnestly to figure out why I would want to use 
C++ over C

>  The
>same as some processors don't specify what happens when you run some
>instructions,
>
Eh! never met this. there are undefined instructions, but not defined 
instructions with undefined behaviour. A very different thing.

> the C guys did a good job IMO.
>
>If they had wanted to specify C with zero holes, previously-working
>codes would break or not compile, and C would die a death under the
>standard as Modula-2 did.  The Modula-2 standard did NOTHING to aid
>Modula-2 becoming a more widespread language, and in my opinion, it
>killed Modula-2 stone dead.
>
So if there were too many earlier variations to account for these with 
'compatibility switches' at least some of the glaring things like this

should have been cleaned up, so that the next round of code updates 
could see them 'corrected'. I used to follow the macinations of the 
standards committee through various sources, like IEEE and the C 
programmers Journal (I'm not anti C I keep telling you, just anti C on 
the sort of embedded designs I usually work on.) and it alwasy struck me 
that huge effort would be expended on absolutely trivial nonsense, while 
glaring issues such as this seemed to be brushed over and left in the 
too hard basket.

Al

>  
>

Hi Al, 

> >If they "standardised" C++
without ambiguity it would be useless.
> >
> I already thought it was! And this isn't uninformed 
> criticism. I spent nearly 18 months trying earnestly to 
> figure out why I would want to use 
> C++ over C
> 
> >  The
> >same as some processors don't specify what happens when you run
some
> >instructions,
> >
> Eh! never met this. there are undefined instructions, but not defined 
> instructions with undefined behaviour. A very different thing.

Try PUSH SP on x86--or even MSP430 (the MSP430 datasheet documents
incorrect behaviour IIRC).  I believe you will find disparity between
what x86 processors do.

Also, picking the MAXQ for instance, MOVE BP[OFFS], @BP[OFFS++] is an
instruction that has a well-defined encoding but its runtime behaviour
is undefined--the bytes that are written are not defined and nor is
where they are written.  Note that on the 68K, MOVE (A4)+,-(A4) is
similarly afflicted wrt A4 after the instruction.

Regards,

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors