> I think there may be a more subtle issue going on here. The expression
> (S2_MAX + S2_STEP) is evaluated at compile time, not run time, as we can=
=20
> see
> from the generated code.
>
> My memory's a little hazy on this point, but doesn't the C standard state=
=20
> that
> compile-time operations are to be done with the largest available size of=
=20
> each
> type; i.e., longs for integers and doubles for floating-point?

Compile time computations are not required by the standard, except in place=
s=20
that require a constant value (for example: the values of an enum, the size=
=20
of an array, the case labels in a switch). Other than these sorts of=20
applications, folding compile time constants is just a performance=20
optimization (albeit one that nearly all(?) compilers do.

Where compile-time operations  do occur that are supposted to follow all th=
e=20
same rules as runtime computation. This is so that it doesn't matter whethe=
r=20
they are optimized away or not (principal of least surprise?).

A problem with C18, and many other 8-bit microcontroller C's is that they d=
o=20
*not* follow the standard when it comes to type promotion. The standard say=
s=20
that *every* arithmetic operation must be done using at least int precision=
=20
(or the results must be "as if" it was done in int precision). However this=
=20
would be very costly on a 8-bit micro, so most (many?) C compilers for them=
=20
will not promote byte-sized arguments to int in the absence of a specific=20
cast. Some compilers (C18??) provide switches to force int promotion, but=20
setting such a switch can have a strongly negative effect on performance.

-- Bob Ammerman
RAm Systems

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.