>
>
> > 1. volatiles _NEVER_ ever sit in a regester except for reload phase.
> > even local volatile will be saved in memory (on stack)
>
> That is the intent of "volatile" qualifier but unfortunately is not
> always true. For example (just a test case, does not do anything
> useful):
>
> -------------------
> volatile short *pbuf, *plast;
>
> int main(void)
> {
> short buf[10];
> pbuf = buf;
> plast = buf + 10;
> while(pbuf < plast);
> return 0;
> }
>
> Compiles into:
>
> while(pbuf < plast);
> 4054: 0f 9e cmp r14, r15 ;
> 4056: fe 2b jnc $-2 ;abs 0x4054
>
>
Your pointers are declared as non-volatile pointers to pointer data, so it
is not surprising that the compiler optomises them like this. Remember,
"typedef" is your friend - avoid any variable or type decleration that
requires more than one qualifier at a time, and you'll get it right:
typedef short *pShort;
volatile pShort pbuf, plast;
(or, if you want the data pointed to to be volatile as well)
typedef volatile short vShort;
typedef vShort *pvShort;
volatile pvShort pbuf, plast;
Giving:
40 .L2:
41 0012 1E42 0000 mov &pbuf, r14 ; pbuf
42 0016 1F42 0000 mov &plast, r15 ; plast
43 001a 0E9F cmp r15, r14
44 001c FA2B jlo .L2
> > 2. volatile var updates every time after 'volatile value' updated.
>
> See above.
>
> > 3. gcc _DOES_ optimize over functions calls (how does it work
> > otherwise?)
>
> Errr.. Not sure if we are talking about the same thing. What I meant is
> that if I hide the
> (pbuf <= plast) comparison into a separate function, reload will not get
> optimized away.
>
Do you mean something like this:
volatile short *pbuf, *plast; // Original incorrect types
int test(volatile short *p, volatile short *q) { return (p < q); }
int main(void) {
short buf[10];
pbuf = buf;
plast = buf + 10;
while (test(pbuf, plast));
return 0;
}
When compiled with -O3, the reloads are optomised away as the test function
is inlined (the code is not quite as efficient, as the function result gets
turned into a 1 or a 0 (as asked for). I find that if the code generated
with -O3 optomisation appears to be wrong, then it is my C code that is
incorrect.
>
> > if you still think gcc does not do a proper job -- please let
> > us know, we'll
> > fix it shortly.
>
> You all guys did a terrific job with msp430 port of gcc. Documentation
> is exemplary which is not often the case with open projects. The code
> generated with mspgcc was beating IAR hands down last time I did a
> compare. Debugger/insight part can use some improvement though.
>
> Sergei
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&opÌk
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
>
