do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0);

[Keith Thompson]

On 2011/07/26 12:37, Hallvard B Furuseth wrote: [...]

Have you looked at the assembly output to check this?

Yes, repeatedly on PIC18, 8051, ST7, ST7M; and recently on ARM,
though not with all optimizations, since they break the
vendor-supplied code frameword :-(

Oh, yuck. gcc without optimization also keeps the cleanup variable.

If you're running gcc without optimization, you're pretty much
telling the compiler that you don't care much about code quality.
There's not much point in complaining that unoptimized code is
unoptimized.

[...]

 

[Keith Thompson]

Ahh... So the old saying "two wrongs don't make a right" should really be
"two wrongs cancel a right". Got it.

Two wrongs don't make a right, but three lefts do.

 

[Nick Keighley]

you couldn't switch to a more standard way of marking other people's
posts could you?

"Nick Keighley" <[email protected]> ha scritto nel messaggio

"Nick Keighley" <[email protected]> ha scritto nel messaggio

For instance this is reasonably clear:-

loop:
if (!finished)
{
do_more_stuff();
goto loop;
}

This less so

loop1:
if (!finished)
{
do_first_stuff();
if (reloop())
goto loop1;
loop2:
do_second_stuff();
if (sudden_death())
goto end;
do_third_stuff()
goto loop1;
}

end:
skip_many_pages();
if (reprocess_event())
goto loop2;

#i not have all your fears
#this "goto loop2;" seem to me a problem [i never wrote something as that]

#i there will write

# {renewVaribleLoop1and2(); goto loop1}
#or but with some problem
# {renewVaribleLoop1and2(); goto loop2}

#and write a end condition that exit function
#or program

I don't know how you can be sure the two programs are equivalent.
Which is my point.

#i don't know if they are equivalent because functions has to be defined

exactly my point. To remove goto tangles you have to do quite deep
analysis of the code.

I refer the honourable memeber to my response to his previous
question.

#what question? who is the "honourable memeber"?

It's a standard formula used in the UK Parliament. If a government
minister is being harried by repetitions (or variations) on the same
question he may respond in the manner above.

What I meant is that I have already addressed your point when I said
"how you can be sure the two programs are equivalent?"

When gotos are discussed people don't always realise the full horror
of old code.

#olds not used indentation and multi instruction for line with goto
#for reduce size of function and see all function
#with the right indentation...

trust [me] twelve page functions don't squish down onto one page no matter
how many statements you put on a line. The great advantage of gotos is
taht you dispense with the indentation. Hence enabling you to compress
the code even more.

this was sarcasm.

This gets boring. If your gotos follow structured programming then
they are easy to follow. So why not use for, while, if etc?

Tangled goto-ful programs are hard to understand.

<snip tedious illustration of what I said>

 

[Hallvard B Furuseth]

If you're running gcc without optimization, you're pretty much
telling the compiler that you don't care much about code quality.
There's not much point in complaining that unoptimized code is
unoptimized.

Yeah. The yuck was addressed to the vendor requirements, not to gcc.

 

[Keith Thompson]

you couldn't switch to a more standard way of marking other people's

exactly my point. To remove goto tangles you have to do quite deep
analysis of the code.

#if you change some function too, you have to do quite deep analysis too;
#if you change even a bit in a variable you have to do some analysis on that

#i remain in what i think
#yes compiler tricks prototipes, type sys, while() if() lint etc etc
#could help in find errors and can make fast who write;
#but one easy language scale complexity well and can outperform the
#compilers out, in structure programming;
#outperform the time to write something too [at end]
#
#not take all that very seriously i not have enough experience
#in programming area

"io_x": Quoted text is normally prefixed with "> ", and new text is
*not* normally prefixed with "#", or with anything else. Whatever
news client you're using should do this for you automatically.
If yours doesn't, please find one that does. Your headers indicate
that you're using Microsoft Outlook Express; either use a different
newsreader (strongly recommended), or look up something called
"OE-Quotefix".

Your articles are difficult enough to read without having to figure
out who wrote what.

 

[Phil Carmody]

I thought the same thing at first.


But, consider that, if you were to use a "goto" to the top of the for-
or while-loop

But which *bit* of the top, the top's large and has many stages in the
case of a for loop?

, rather than "continue", the conditions would not be
re-tested, nor would the for-loop's "expression_3" be executed.
Therefore, while the code that gets executed is at the top, it only
happens because you hit the bottom.

Because you restricted your 'jump' to 'goto', but we're not constrained
by 'goto', merely jumping.

Phil

 

[Thomas Boell]

If such finegrained control is needed, wouldn't you be better off
using assembly? Most uC targeted compilers i know of mix the two quite
well.

From what i read portability isn't a great concern, since you're quite
specific on the platform, so that can't be the issue.

Have you ever used assembly on a microcontroller? Many of the
widely-used Atmel uCs, for example, don't have a multiply instruction.
They cannot do calculations on any integers larger than 8 bits
directly. There is no "add immediate" instruction either; you have to
negate the value and use "subtract immediate" instead. Letting the
compiler handle things like 16-bit multiplication certainly makes
things a lot easier.

Programming uCs in assembly is hard, error-prone, and the code will not
be easy to maintain. If anyone says they would rather program uCs in C,
they certainly have a point.

 

[James Kuyper]

Have you ever used assembly on a microcontroller? Many of the
widely-used Atmel uCs, for example, don't have a multiply instruction.
They cannot do calculations on any integers larger than 8 bits
directly. There is no "add immediate" instruction either; you have to
negate the value and use "subtract immediate" instead. Letting the
compiler handle things like 16-bit multiplication certainly makes
things a lot easier.

Programming uCs in assembly is hard, error-prone, and the code will not
be easy to maintain. If anyone says they would rather program uCs in C,
they certainly have a point.

That's a very reasonable decision to make, but there's a corresponding
price you'll pay for the convenience of having the compiler generate
assembly for you: you lose control of details such as the ones Francois
was worried about.

 

[Thomas Boell]

[..]
If I rationalize: on low-end platforms (PIC..) that I often use, RAM
size is a few hundred bytes and program space a few kbytes, so every
byte counts. Even on relatively powerful CPUs (Arm, x86) and when memory
is not an issue, using one more register may force the shift of
something into memory rather than in a register, or/and a little extra
code could abruptly reduce cache efficiency, and in turn slow down
things considerably. I bet I could construct an articial demo where the
suggested change increases execution time/power draw quite perceptibly,
say by 30%.

Francois Grieu

If such finegrained control is needed, wouldn't you be better off
using assembly? Most uC targeted compilers i know of mix the two quite
well.

From what i read portability isn't a great concern, since you're quite
specific on the platform, so that can't be the issue.

Have you ever used assembly on a microcontroller? Many of the
widely-used Atmel uCs, for example, don't have a multiply instruction.
They cannot do calculations on any integers larger than 8 bits
directly. There is no "add immediate" instruction either; you have to
negate the value and use "subtract immediate" instead. Letting the
compiler handle things like 16-bit multiplication certainly makes
things a lot easier.

Programming uCs in assembly is hard, error-prone, and the code will not
be easy to maintain. If anyone says they would rather program uCs in C,
they certainly have a point.

That's a very reasonable decision to make, but there's a corresponding
price you'll pay for the convenience of having the compiler generate
assembly for you: you lose control of details such as the ones Francois
was worried about.

Not necessarily, which I think was kind of his point...

In this case, I would still prefer "goto" over the do{switch(... etc,
though.

 

[James Kuyper]

Not necessarily, which I think was kind of his point...

If so, his point was wrong. C provides no way to specify such details. C
source code which you might imagine specifies generation of one
particular sequence of assembly language instructions on a given
platform does nothing of the sort. A conforming compiler for that
platform can translate that code into any other sequence that produces
the same result.

 

[Willem]

James Kuyper wrote:
) If so, his point was wrong. C provides no way to specify such details. C
) source code which you might imagine specifies generation of one
) particular sequence of assembly language instructions on a given
) platform does nothing of the sort. A conforming compiler for that
) platform can translate that code into any other sequence that produces
) the same result.

Technically/pedantically, yes. Practically, given a known compiler,
you can most certainly influence the output by the choice of C code.
The case in point is if the compiler would use a variable or not for
a certain construct, and that seems entirely plausible.

I would imagine that C compilers that target embedded systems could
even document this to an extent, given that embedded programmers care
so much about such issues.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Thomas Boell]

If so, his point was wrong. C provides no way to specify such details. C
source code which you might imagine specifies generation of one
particular sequence of assembly language instructions on a given
platform does nothing of the sort. A conforming compiler for that
platform can translate that code into any other sequence that produces
the same result.

uC code is not really portable anyway. You use a specific compiler and
toolchain, so it's valid to optimize for that particular toolchain.

Besides, it's reasonable to assume that code which specifies to create
a variable will create a variable more often than code which specifies
not creating one. Optimizing the variable away might not be possible
at all. Also, relying on the compiler to always generate optimal code
regardless of what you throw at it is just wishful thinking.

 

[Ali]

On Fri, 22 Jul 2011 08:14:44 -0700 (PDT)

[..]
If I rationalize: on low-end platforms (PIC..) that I often use, RAM
size is a few hundred bytes and program space a few kbytes, so every
byte counts. Even on relatively powerful CPUs (Arm, x86) and when memory
is not an issue, using one more register may force the shift of
something into memory rather than in a register, or/and a little extra
code could abruptly reduce cache efficiency, and in turn slow down
things considerably. I bet I could construct an articial demo where the
suggested change increases execution time/power draw quite perceptibly,
say by 30%.
   Francois Grieu
If such finegrained control is needed, wouldn't you be better off
using assembly? Most uC targeted compilers i know of mix the two quite
well.
From what i read portability isn't a great concern, since you're quite
specific on the platform, so that can't be the issue.

Have you ever used assembly on a microcontroller? Many of the
widely-used Atmel uCs, for example, don't have a multiply instruction.
They cannot do calculations on any integers larger than 8 bits
directly. There is no "add immediate" instruction either; you have to
negate the value and use "subtract immediate" instead. Letting the
compiler handle things like 16-bit multiplication certainly makes
things a lot easier.

Programming uCs in assembly is hard, error-prone, and the code will not
be easy to maintain. If anyone says they would rather program uCs in C,
they certainly have a point.

That's a very reasonable decision to make, but there's a corresponding
price you'll pay for the convenience of having the compiler generate
assembly for you: you lose control of details such as the ones Francois
was worried about.

And we have a nice old thing to talk. Goto Vs. Function return calls.

I will go for "goto".

regards,
ali

 

[James Kuyper]

James Kuyper wrote:
) If so, his point was wrong. C provides no way to specify such details. C
) source code which you might imagine specifies generation of one
) particular sequence of assembly language instructions on a given
) platform does nothing of the sort. A conforming compiler for that
) platform can translate that code into any other sequence that produces
) the same result.

Technically/pedantically, yes. Practically, given a known compiler,
you can most certainly influence the output by the choice of C code.
The case in point is if the compiler would use a variable or not for
a certain construct, and that seems entirely plausible.

Yes, by knowing enough about a given compiler, you can do that. However,
in order to be certain, you really need to disassemble and understand
the generated assembly language, to make sure it's generating the code
that you want. If you change compilers, or even if you merely update the
compiler, you'll have to check all over again, because something
relevant might be different. If you know what you want in sufficient
detail to second-guess the compiler, it's much simpler to just write the
code you want yourself.

 

[Willem]

James Kuyper wrote:
) Yes, by knowing enough about a given compiler, you can do that. However,
) in order to be certain, you really need to disassemble and understand
) the generated assembly language, to make sure it's generating the code
) that you want. If you change compilers, or even if you merely update the
) compiler, you'll have to check all over again, because something
) relevant might be different.

Not in all cases. Looks like you're using reductio ad absurdam.
It al depends on how fine the requirements are. Some things are
really easy to spot in a disassembly output, such as register use,
flow control statements, stuff like that.

Also, 'disassemble the generated assembly language' is an absurd statement.
You generate machine code by assembling assembly language, and when you
disassemble machine code, you get assembly language.

Note that most compilers generate assembly language, not machine code
directly, so examining the generated assembly is quite easy.

) If you know what you want in sufficient
) detail to second-guess the compiler, it's much simpler to just write the
) code you want yourself.

All the OP wanted was to avoid the use of extra variables tying up
registers or memory slots. That's a pretty coarse requirement which
can certainly be influenced by changing the code, will work on a range
of compilers, and is very easily checked by a once-over of the assembly
output, whereas writing everything yourself would be very much harder.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[James Kuyper]

On 07/30/2011 05:12 AM, Willem wrote:
....

Also, 'disassemble the generated assembly language' is an absurd statement.

It's an editing error; the original statement was about disassembling
the program, then I incompletely corrected it to refer directly to the
generated assembly language, forgetting to remove the word disassemble.