Re: Linux kernel, possible useless continue

Ulrich Eckhardt <doomster@xxxxxxxx> writes:
Rainer Weikusat wrote:
Ulrich Eckhardt <doomster@xxxxxxxx> writes:

[...]

for(...)
if(x)
continue;
for(..; .. && !x; ..)
..

The only difference is the initialisation statement in the inner
loop, and for the case we're talking about this small difference
doesn't make a difference overall, in particular not when it is
compiled with a halfway-decent optimiser.

As I understood the original question, it was about code semantics and
not about hypothetical, accidental properties of unknown machine code
generated by a random compiler for an arbitrary architecture.

The compiler that is able to digest Linux is not so random ... ;)

It is at least a range of gcc releases.

Seriously, fact remains that the initialisation is low-cost in any
environment.

This depends on the generated machine code (eg does it initialize a
register or a memory location) and on the definition of 'low-cost'.

Also, it might even be weighed up by the removal of the check
for the continue and less instruction-cache use,

This depends on the generated return code as well.

but neither is important enough to merit any obfuscations in code

To me, the code is 'more obfuscated' if it contains more semantically
useless things, which I have to understand to understand that they are
semantically useless.

[...]

What remains fact is that the if-clause with the continue can be removed
without changing the behaviour of the code,

This may or may not be so, and depends on the generated machine code
as well.

And wasn't "established theory" that one should rather not code to
the idiosynkrasies of some translation or execution environment, but
instead try to express the intent of the code clearly and leave 'the
gory details' exactly to the compiler?

I'm not sure what you are implying with this.

I am not implying anything. What you advocate would be a
compiler version and translation algorithm dependant hack. That the
hack is not intended to improve the generated code, only believed to
not make it worse doesn't make it less of one. This is the stuff one
may include in code if there is evidence that it actually improves
something relevant, and even then, it should better be avoided.
.

Relevant Pages

  • Re: Is C99 the final C? (some suggestions)
    ... This would violate the division between preprocessor and compiler too ... much (the preprocessor would have to understand quite a lot of C semantics). ... ...This is legal C (as per the Standard), but it overflows the stack on ...
    (comp.lang.c)
  • Re: How do I dig a memory value out?
    ... The only C compiler I could find at the time was ... The Atari keyboard was missing several characters, ... higher level language plus a few common data types ... hand tweeked machine code was entered directly in the ...
    (microsoft.public.vb.general.discussion)
  • Re: Source to Source compilation - targeting C?
    ... high level language (syntax and semantics) to target C as the output? ... Does the ROSE compiler framework do this? ... you don't really need "code generation knowledge" to target C, ... and mostly "unwinding" this into C style syntax and semantics ...
    (comp.compilers)
  • Re: left-to-right (was In-Out Parameters for functions)
    ... >> The question is what gets lost if an evaluation order is fixed. ... What I would expect from a good compiler is factoring out the cycle ... There is no need to check program semantics very precisely. ... language may simply outlaw "pure" functions like: ...
    (comp.lang.ada)
  • Re: Glasgow haskell vs. Lispworks
    ... gotos with block structured programming and the harmfulness of goto ... How many languages even have formally-defined semantics that a compiler must ... And WRT to your dislike of Haskell: ...
    (comp.lang.functional)