On Thu, 6 Jan 2000, Davide Libenzi wrote:
[SNIPPED]
>
> AFAIK the generated code is the same on intel.
> Having a single instruction to increment a memory location ( in any
> architecture ? ) why the compiler should split the operation ?
>
> Cheers,
> Davide.
The compiler can (and will) do anything it wants as long as it's
logically and mathematically what (it thinks) the source-code says.
However, the C-code hack to force reordering is incorrect. It ties
the generated code to a specific version of a compiler and, perhaps,
even how much memory the compiler had available today for optimization.
If it is essential that instructions be ordered in a specific way,
then a platform-specific macro should have been defined using the
necessary assembly language. Assemblers are not allowed to change
anything. (Although GAS does, which is another problem for another
topic. GAS should error-out if the operand size is not correct).
Incidentally, 'C' compilers used to follow parentheses, operating upon
the inner-most set first, etc. Now they are allowed to do anything.
This means that mathematical operations, that you have carefully
ordered, to maximize dynamic-range, or eliminate overflow, may
not perform as expected. We run into this all the time in signal-
processing. 'C' compilers also can't be trusted to do memory-mapped
I/O. If it is essential that one memory-mapped register be modified
before another, you have to do it is assembly. Even when defined as
'volatile', 'C' will happily reorder.
This is not meant mean anything other than what was stated. I will
wear my flak jacket when others try to change my statements into a
C-war. 'C' is a good tool. In particular, it has grown to where it
is the tool of choice for many writing portable code. However, specific
memory locations, and specific read/write orderings are not portable.
For this, you use another tool.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.35 on an i686 machine (400.59 BogoMips).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:06 EST