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: Legit Warnings or not
    ... vs. equality) are parts of the semantics, ... rather than to rely on the compiler. ... I want Ada to remain a universal programming ...
    (comp.lang.ada)
  • 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: OpenGL 4.1 is out
    ... if it didn't support it's own older instruction sets... ... complexity as possible gets pushed onto the compiler. ... Portability is provided by GLSL. ... machine code at run time, if only to placate management types who think ...
    (comp.graphics.api.opengl)
  • 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)