Constant Expressions in C

[skibud2]

Consider this example:

u8 my_array[10];

for (i = 0; i < (sizeof(my_arra y)/sizeof(u8)); i++) {
...
}

In the standard C specification, is the evaluation of
'(sizeof(my_arr ay)/sizeof(u8))' to 10 guarenteed to happen at compile
time? Or is it a compiler optimization? From what I have read, it
looks like it is a compiler optimization, but I would like to get
confirmation.

Now if is not guarenteed to happen at compile time, is it better to do
something like the following:

const u8 my_array_size = (sizeof(my_arra y)/sizeof(u8));

to guarentee that you are not doing a divide a run time? On the
systems I have worked on, divides take a very long time. However,
almost every compiler that I have dealt with does the evaluation at
compile time.

[christian.bau]

On Apr 21, 11:38 pm, "kar1...@gmail. com" <kar1...@gmail. comwrote:

That really surprises me. And 'significantly' faster? that's puzzling.
Mostly small integer constants (that can fit in, say 16 bits) are
directly
encoded in the same machine instruction. Thus no load/store for the
operand.
So I'm wondering why any compiler would ever do things slowly on using
a literal '1'
than using thru' a variable (named like one above).

The PowerPC has a single instruction that performs that operation a =
b << c; if a, b and c are all in registers. There is _no_ single
instruction to calculate a = 1 << c: Two instructions are needed, one
to load the constant 1 into a register, and one to shift. Now if you
have an operation that calculates 1 << n in the critical path of a
very short loop with gazillions of iterations then this can make a
significant difference. This happened to me on a compiler that was
actually quite good at optimisations, except that it didn't recognise
that a constant can actually be a loop-invariant that should be
removed from a loop!

Similar things can happen with floating-point constants used in a
loop; a compiler should hold them in a register but often doesn't
whereas complex operations could be removed as loop-invariants from a
loop, with the result being kept in a register.

[Peter Nilsson]

Ian Collins <[e-mail] mwrote:

Jack Klein wrote:

Despite what others have said, the C language standard does not
require a compiler to evaluate constant expressions at compile time

Vacuously true.

unless it needs to use the value at compile time, as in Ian's example
of using it to define the size of an array.

Thanks for the clarification Jack, I wasn't aware of that "unless".

What "unless"?

The standard simply says (Epmhasis mine): "A constant expression _can_
be evaluated during _translation_ rather than runtime..." There is no
"must"
or "shall" precluding runtime evaluation of all constant expressions.

Expectations of QoI is the only guide. But when it comes to constant
expressions, expectations are pretty high these days. :-)

--
Peter

[Ian Collins]

Peter Nilsson wrote:

Ian Collins <[e-mail] mwrote:

>>Jack Klein wrote:

>>>Despite what others have said, the C language standard does not
require a compiler to evaluate constant expressions at compile time

Vacuously true.

Vacuous?

>>>unless it needs to use the value at compile time, as in Ian's example
of using it to define the size of an array.

Thanks for the clarification Jack, I wasn't aware of that "unless".

What "unless"?

The standard simply says (Epmhasis mine): "A constant expression _can_
be evaluated during _translation_ rather than runtime..." There is no
"must"
or "shall" precluding runtime evaluation of all constant expressions.

Expectations of QoI is the only guide. But when it comes to constant
expressions, expectations are pretty high these days. :-)

I have never come across a compiler that does not do this, so naturally
I assumed it was standard behaviour.

--
Peter

Your sig is missing the space after the --

--
Ian Collins.

[Peter Nilsson]

Ian Collins <[e-mail] mwrote:

Peter Nilsson wrote:

Ian Collins <[e-mail] mwrote:

Jack Klein wrote:
Despite what others have said, the C language standard does not
require a compiler to evaluate constant expressions at compile time

Vacuously true.

Vacuous?

Yes, the notion of compile and link time are not mentioned. The word
"compiler"
only appears in a non-normative footnote of N1124. Obviously there is
an intuitive
mapping between the translation phases...

Preprocessing - TP1..4
Compilation - TP5..7
Linking - TP8

That said, there is often a degree of overlap on actual
implementations ,
particularly between compilation and preprocessing, especially with
pragma
extensions.

unless it needs to use the value at compile time, as in Ian's example
of using it to define the size of an array.
>
Thanks for the clarification Jack, I wasn't aware of that "unless".

What "unless"?

The standard simply says (Epmhasis mine): "A constant expression _can_
be evaluated during _translation_ rather than runtime..." There is no
"must" or "shall" precluding runtime evaluation of all constant expressions.

Expectations of QoI is the only guide. But when it comes to constant
expressions, expectations are pretty high these days. :-)

I have never come across a compiler that does not do this,

Nor are you likely to. Conditional preprocessing often involves
constant
expressions, so you're unlikely to find an implementation that can't
work
them out as it goes.

so naturally I assumed it was standard behaviour.

Whilst highly pragmatic and practical in nature, the language standard
is nonetheless an abstraction.

--
Peter

Your sig is missing the space after the --

As is...

--
Ian Collins.

Of course, I believe that you typed/inserted it.

Either google or IE managed to delete it. AFAIK, I'm not in a position
to
rectify this. If you're going to tell me how annoying it is for you,
then
realise that as a very reluctant google groups user I probably have to
do
things ten times more annoying than manually trimming signatures.

--
Peter

[Ian Collins]

Peter Nilsson wrote:

Of course, I believe that you typed/inserted it.

Either google or IE managed to delete it. AFAIK, I'm not in a position
to
rectify this. If you're going to tell me how annoying it is for you,
then
realise that as a very reluctant google groups user I probably have to
do
things ten times more annoying than manually trimming signatures.

Like reading badly wrapped lines :)

--
Ian Collins.

[David Thompson]

On 22 Apr 2007 17:16:57 -0700, Peter Nilsson <ai***@acay.com .au>
wrote:

Ian Collins <[e-mail] mwrote:

Jack Klein wrote:

Despite what others have said, the C language standard does not
require a compiler to evaluate constant expressions at compile time

Vacuously true.

unless it needs to use the value at compile time, as in Ian's example
of using it to define the size of an array.

Thanks for the clarification Jack, I wasn't aware of that "unless".

What "unless"?

The standard simply says (Epmhasis mine): "A constant expression _can_
be evaluated during _translation_ rather than runtime..." There is no
"must"
or "shall" precluding runtime evaluation of all constant expressions.

Expectations of QoI is the only guide. But when it comes to constant
expressions, expectations are pretty high these days. :-)

True. But for some _integer_ constant expressions:

- the ICE specifying bitfield width in a struct must not be greater
than the 'normal' width (before C99, of [u]int) nor less than zero and
if zero must not be named; this is a constraint and so any violation
of it must be diagnosed. It's hard to do that without evaluating the
constant expression at compile time, unless you weasel out with a
blanket diagnostic like "this program may contain errors".

- the ICE specifying the value of an enumeratee must be in range of
int, as a constraint. This might not be too hard to defer, except that
the enumeratee can in turn be used in other ICEs which may need to be
evaluated.

- if the (integer) expression for array bound in a declarator is
constant it must be positive as a constraint; plus whether two array
types are compatible depends on whether their bounds are ICEs with the
same value, and compatibility is in some constraints.

- (ICEs for) case labels in a switch must be distinct, a constraint.

And as already noted, (integer) constant expressions in #if or #elif
must be evaluated at preprocessing time, at least in principle BEFORE
compile time, because
#if 0
#include "nonexistentfil e"
#endif
int main (void) { return 0; }
must succeed (or at least not fail because of that construct).

OTOH it may actually make sense to defer floating-point constant
expressions in cases of cross compilation where the target floating
point arithmetic is different from the host and not worth the trouble
of simulating or (God forbid) not documented well enough to simulate.

- formerly david.thompson1 || achar(64) || worldnet.att.ne t