-----Original Message-----
From: Ben Pfaff [mailto:pfaffben@msu.edu]
>Jonathan George <Jonathan.George@trcinc.com> writes:
>
>> This patch has many bogus corrections where new variables were created,
but
>> the order of evaluation is already unambiguous.
>>
>> For example each comma separated clause in an expression is guaranteed to
be
>> completely evaluated before the next comma separated clause Including
>> Assignments.
>
>No, that is not true in general. When the comma in question is
>the comma operator, it is true. But when the comma separates
>arguments to a function, it is not: the order of evaluation of
>function arguments is implementation dependent. See C89 section
>6.3.2.2 "Function calls":
>
> $ The order of evaluation of the function designator, the
> $ arguments, and subexpressions within the arguments is
> $ unspecified, ...
>--
I sit surprised and corrected. With every version of every C compiler on
every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using
Manx C to E10000 using Kai C++) the behavior has been the same for parameter
lists as for the comma operator in this respect. Does this imply that even
the evaluation of a function pointer is itself undefined in terms of
ordering?
>"Premature optimization is the root of all evil."
>--D. E. Knuth, "Structured Programming with go to Statements"
Absolutely true.
However, optimization of well tested, and algorithmically validated kernel
code in a time critical section does not constitute premature optimization
as I'm sure Donald would agree.
I would be really interested to see how well the kernel compiler does at
optimizing out all of these new tmp variables in terms of the resulting
register utilization and performance. At least an assembler code size
comparison is in order for each of these individual cases.
That is my only real concern (other than all of that syntactically ambiguous
code I have written over the last 15 years ;-) is that critical performance
not be compromised in the kernel.
--Jonathan--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:10 EST