Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #8566 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-22 08:49 +0200
    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-22 00:58 -0700
    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); gwowen <gwowen@gmail.com> - 2011-07-22 01:46 -0700
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); gazelle@shell.xmission.com (Kenny McCormack) - 2011-07-22 13:16 +0000
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-22 06:35 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); tom st denis <tom@iahu.ca> - 2011-07-22 08:37 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-22 12:20 -0400
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-22 16:41 +0200
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-22 12:10 -0400
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-22 19:39 +0100
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); luser- -droog <mijoryx@yahoo.com> - 2011-07-22 21:05 -0700
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-23 13:24 +0100
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); gazelle@shell.xmission.com (Kenny McCormack) - 2011-07-23 15:11 +0000
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "io_x" <a@b.c.invalid> - 2011-07-23 22:16 +0200
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-22 09:39 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-22 22:30 +0300
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-22 13:15 -0700
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-23 01:02 +0300
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Jens Schweikhardt <usenet@schweikhardt.net> - 2011-07-23 13:06 +0000
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-23 16:51 +0300
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-25 12:06 -0400
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Jens Schweikhardt <usenet@schweikhardt.net> - 2011-07-25 20:39 +0000
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 10:43 -0400
                      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-26 08:58 -0700
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-25 12:03 -0400
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-29 01:51 +0300
    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); August Karlstrom <fusionfile@gmail.com> - 2011-07-22 12:15 +0200
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-22 16:11 +0200
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-22 08:14 -0700
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Thomas Boell <tboell@domain.invalid> - 2011-07-29 14:38 +0200
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); James Kuyper <jameskuyper@verizon.net> - 2011-07-29 09:23 -0400
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Thomas Boell <tboell@domain.invalid> - 2011-07-29 15:58 +0200
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); James Kuyper <jameskuyper@verizon.net> - 2011-07-29 10:42 -0400
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Willem <willem@toad.stack.nl> - 2011-07-29 14:56 +0000
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); James Kuyper <jameskuyper@verizon.net> - 2011-07-29 20:47 -0400
                      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Willem <willem@toad.stack.nl> - 2011-07-30 09:12 +0000
                        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); James Kuyper <jameskuyper@verizon.net> - 2011-07-30 07:30 -0400
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Thomas Boell <tboell@domain.invalid> - 2011-07-29 17:08 +0200
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ali <abdulrazaq@gmail.com> - 2011-07-29 08:21 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-22 12:24 -0400
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-25 10:34 +0200
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Willem <willem@toad.stack.nl> - 2011-07-25 08:54 +0000
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-25 09:08 -0700
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Willem <willem@toad.stack.nl> - 2011-07-25 16:52 +0000
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-25 11:37 -0700
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); cri@tiac.net (Richard Harter) - 2011-07-25 20:16 +0000
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-26 10:23 +0200
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 00:49 -0700
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "io_x" <a@b.c.invalid> - 2011-07-26 11:16 +0200
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 03:09 -0700
                      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "io_x" <a@b.c.invalid> - 2011-07-26 19:21 +0200
                        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 00:43 -0700
                          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "io_x" <a@b.c.invalid> - 2011-07-27 11:29 +0200
                            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-27 08:30 -0700
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 10:39 -0400
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Hallvard B Furuseth <h.b.furuseth@usit.uio.no> - 2011-07-26 12:37 +0200
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-26 12:52 +0200
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Hallvard B Furuseth <h.b.furuseth@usit.uio.no> - 2011-07-26 13:18 +0200
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-26 08:57 -0700
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Hallvard B Furuseth <h.b.furuseth@usit.uio.no> - 2011-07-27 10:18 +0200
    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ali <abdulrazaq@gmail.com> - 2011-07-23 15:38 -0700
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ali <abdulrazaq@gmail.com> - 2011-07-24 09:25 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 01:01 -0700
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); gwowen <gwowen@gmail.com> - 2011-07-25 03:08 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#8696

On 7/23/2011 9:06 AM, Jens Schweikhardt wrote:
> Phil Carmody<thefatphil_demunged@yahoo.co.uk>  wrote
> 	in<87ei1irn2s.fsf@bazspaz.fatphil.org>:
> ....
> # Yes, this is wrong. But I think only 1/3 wrong.
>
> The discovery of the truth quark! :-)

So, truths are really either 2/3 right, or 1/3 wrong?

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#8701

Kenneth Brody <kenbrody@spamcop.net> wrote
	in <gsKdnVvBOdr3CbDTnZ2dnUVZ_hOdnZ2d@bestweb.net>:
# On 7/23/2011 9:06 AM, Jens Schweikhardt wrote:
#> Phil Carmody<thefatphil_demunged@yahoo.co.uk>  wrote
#>       in<87ei1irn2s.fsf@bazspaz.fatphil.org>:
#> ....
#> # Yes, this is wrong. But I think only 1/3 wrong.
#>
#> The discovery of the truth quark! :-)
# 
# So, truths are really either 2/3 right, or 1/3 wrong?

Two wrongs cancel a right, that's for sure. I've lost my copy of QLD
(Quantumlogodynamics).

Regards,

	Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

[toc] | [prev] | [next] | [standalone]

#8737

On 7/25/2011 4:39 PM, Jens Schweikhardt wrote:
> Kenneth Brody<kenbrody@spamcop.net>  wrote
> 	in<gsKdnVvBOdr3CbDTnZ2dnUVZ_hOdnZ2d@bestweb.net>:
> # On 7/23/2011 9:06 AM, Jens Schweikhardt wrote:
> #>  Phil Carmody<thefatphil_demunged@yahoo.co.uk>   wrote
> #>        in<87ei1irn2s.fsf@bazspaz.fatphil.org>:
> #>  ....
> #>  # Yes, this is wrong. But I think only 1/3 wrong.
> #>
> #>  The discovery of the truth quark! :-)
> #
> # So, truths are really either 2/3 right, or 1/3 wrong?
>
> Two wrongs cancel a right, that's for sure. I've lost my copy of QLD
> (Quantumlogodynamics).

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

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#8743

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 7/25/2011 4:39 PM, Jens Schweikhardt wrote:
>> Kenneth Brody<kenbrody@spamcop.net>  wrote
>> 	in<gsKdnVvBOdr3CbDTnZ2dnUVZ_hOdnZ2d@bestweb.net>:
>> # On 7/23/2011 9:06 AM, Jens Schweikhardt wrote:
>> #>  Phil Carmody<thefatphil_demunged@yahoo.co.uk>   wrote
>> #>        in<87ei1irn2s.fsf@bazspaz.fatphil.org>:
>> #>  ....
>> #>  # Yes, this is wrong. But I think only 1/3 wrong.
>> #>
>> #>  The discovery of the truth quark! :-)
>> #
>> # So, truths are really either 2/3 right, or 1/3 wrong?
>>
>> Two wrongs cancel a right, that's for sure. I've lost my copy of QLD
>> (Quantumlogodynamics).
>
> 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.


-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8695

On 7/22/2011 6:02 PM, Phil Carmody wrote:
> Keith Thompson<kst-u@mib.org>  writes:
>> Phil Carmody<thefatphil_demunged@yahoo.co.uk>  writes:
>>> Keith Thompson<kst-u@mib.org>  writes:
>>>> gwowen<gwowen@gmail.com>  writes:
[...]
>>>>> Half-remembered saws like "Goto considered harmful" will never beat
>>>>> clear thinking.
>>>>
>>>> But break and continue aren't *just* disguised gotos.  They're
>>>> tightly restricted gotos.  They branch only to a specific point in
>>>> the code (the end of a certain construct), and unlike gotos they
>>>> can't branch to an earlier point in the code.
>>>
>>> Continue can. And does. Always.

I thought the same thing at first.

> Yes, this is wrong. But I think only 1/3 wrong.
>
>> C99 6.8.6.2 (emphasis added):
>>
>>      A continue statement causes a jump to the loop-continuation
>>      portion of the smallest enclosing iteration statement; that is,
>>      *to the end* of the loop body.
>>
>> The (optional) subsequent branch to the top of the loop is the normal
>> operation of the loop itself, not a result of the continue statement.
>
> Hmmm, I think I disagree. It is for a do {} while, certainly. However,
> in the absense of a definition of "loop-continuation portion", For me
> it's obviously expression_3 for a for loop (which is at the top) and
> the condition for a while loop (which is at the top). Their
> explication introduces more contradiction than explanation. So, to
> their "that is", I'd say "no, that isn't". It would have been better
> if they'd just used the final clause. Were I to be pedantic, I'd take
> issue with your '(optional)' is 2/3 wrong, as it's not optional in
> whiles and fors, only in dos.

But, consider that, if you were to use a "goto" to the top of the for- or 
while-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.

>> This is particularly relevant for a continue in a do-while loop, which
>> causes the condition at the bottom to be re-evaluated.
>
> Yup, you definitely got me there - good call. I dunno why, I was just
> in a 'for' train of thought, and a bit blinkered.

<aol>Me too.</aol>

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#8843

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 7/22/2011 6:02 PM, Phil Carmody wrote:
> > Keith Thompson<kst-u@mib.org>  writes:
> >> Phil Carmody<thefatphil_demunged@yahoo.co.uk>  writes:
> >>> Keith Thompson<kst-u@mib.org>  writes:
> >>>> gwowen<gwowen@gmail.com>  writes:
> [...]
> >>>>> Half-remembered saws like "Goto considered harmful" will never beat
> >>>>> clear thinking.
> >>>>
> >>>> But break and continue aren't *just* disguised gotos.  They're
> >>>> tightly restricted gotos.  They branch only to a specific point in
> >>>> the code (the end of a certain construct), and unlike gotos they
> >>>> can't branch to an earlier point in the code.
> >>>
> >>> Continue can. And does. Always.
> 
> I thought the same thing at first.
> 
> > Yes, this is wrong. But I think only 1/3 wrong.
> >
> >> C99 6.8.6.2 (emphasis added):
> >>
> >>      A continue statement causes a jump to the loop-continuation
> >>      portion of the smallest enclosing iteration statement; that is,
> >>      *to the end* of the loop body.
> >>
> >> The (optional) subsequent branch to the top of the loop is the normal
> >> operation of the loop itself, not a result of the continue statement.
> >
> > Hmmm, I think I disagree. It is for a do {} while, certainly. However,
> > in the absense of a definition of "loop-continuation portion", For me
> > it's obviously expression_3 for a for loop (which is at the top) and
> > the condition for a while loop (which is at the top). Their
> > explication introduces more contradiction than explanation. So, to
> > their "that is", I'd say "no, that isn't". It would have been better
> > if they'd just used the final clause. Were I to be pedantic, I'd take
> > issue with your '(optional)' is 2/3 wrong, as it's not optional in
> > whiles and fors, only in dos.
> 
> 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
-- 
Humans will have advanced a long, long, way when religious
belief has a cozy little classification in the DSM.
-- David Melville (on r.a.s.f1)

[toc] | [prev] | [next] | [standalone]

#8571

On 2011-07-22 08:49, Francois Grieu wrote:
> I just came into a case where I could use this:
>
> do
> {
> // local declarations and initializations
> switch(0)default:
> {
> // bunch of if/else; within that:
> // - "break" performs cleanup;
> // - "continue" skips cleanup.
> /*..*/;
> }
> /*..*/; // cleanup
> }
> while(0);

I must be missing something. Why can't you just do something like this?

	cleanup = 0;
	if (c1) {
		...
		cleanup = 1;
	} else if (c2) {
	
	}...
	
	}
	if (cleanup) {
	
	}


August

-- 
The competent programmer is fully aware of the limited size of his own 
skull. He therefore approaches his task with full humility, and avoids 
clever tricks like the plague. --Edsger Dijkstra

[toc] | [prev] | [next] | [standalone]

#8576

On 2011/22/07 12:15, August Karlstrom wrote:
> On 2011-07-22 08:49, Francois Grieu wrote:
>> I just came into a case where I could use this:
>>
>> do
>> {
>> // local declarations and initializations
>> switch(0)default:
>> {
>> // bunch of if/else; within that:
>> // - "break" performs cleanup;
>> // - "continue" skips cleanup.
>> /*..*/;
>> }
>> /*..*/; // cleanup
>> }
>> while(0);
>
> I must be missing something. Why can't you just do something like this?
>
> cleanup = 0;
> if (c1) {
> ...
> cleanup = 1;
> } else if (c2) {
>
> }...
>
> }
> if (cleanup) {
>
> }

I *CAN*. But I'd rather not. I know that most if not all the compilers I 
use will not notice that the "cleanup" variable can be suppressed, and 
knowing that an extra variable exists and code is here to set and test 
it is causing me brain pain. I'd rather use two gotos (or a single goto 
and a deep nesting of ifs, which often will do the job), and get 
basically the "right" executable.

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

[toc] | [prev] | [next] | [standalone]

#8581

On Jul 22, 4:11 pm, Francois Grieu <fgr...@gmail.com> wrote:
> On 2011/22/07 12:15, August Karlstrom wrote:
>
>
>
>
>
>
>
>
>
> > On 2011-07-22 08:49, Francois Grieu wrote:
> >> I just came into a case where I could use this:
>
> >> do
> >> {
> >> // local declarations and initializations
> >> switch(0)default:
> >> {
> >> // bunch of if/else; within that:
> >> // - "break" performs cleanup;
> >> // - "continue" skips cleanup.
> >> /*..*/;
> >> }
> >> /*..*/; // cleanup
> >> }
> >> while(0);
>
> > I must be missing something. Why can't you just do something like this?
>
> > cleanup = 0;
> > if (c1) {
> > ...
> > cleanup = 1;
> > } else if (c2) {
>
> > }...
>
> > }
> > if (cleanup) {
>
> > }
>
> I *CAN*. But I'd rather not. I know that most if not all the compilers I
> use will not notice that the "cleanup" variable can be suppressed, and
> knowing that an extra variable exists and code is here to set and test
> it is causing me brain pain. I'd rather use two gotos (or a single goto
> and a deep nesting of ifs, which often will do the job), and get
> basically the "right" executable.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#8864

On Fri, 22 Jul 2011 08:14:44 -0700 (PDT)
"Kleuskes & Moos" <kleuske@xs4all.nl> wrote:

> On Jul 22, 4:11 pm, Francois Grieu <fgr...@gmail.com> wrote:
> [..]
> > 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.

[toc] | [prev] | [next] | [standalone]

#8866

On 07/29/2011 08:38 AM, Thomas Boell wrote:
> On Fri, 22 Jul 2011 08:14:44 -0700 (PDT)
> "Kleuskes & Moos" <kleuske@xs4all.nl> wrote:
> 
>> On Jul 22, 4:11 pm, Francois Grieu <fgr...@gmail.com> wrote:
>> [..]
>>> 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.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#8868

On Fri, 29 Jul 2011 09:23:27 -0400
James Kuyper <jameskuyper@verizon.net> wrote:

> On 07/29/2011 08:38 AM, Thomas Boell wrote:
> > On Fri, 22 Jul 2011 08:14:44 -0700 (PDT)
> > "Kleuskes & Moos" <kleuske@xs4all.nl> wrote:
> > 
> >> On Jul 22, 4:11 pm, Francois Grieu <fgr...@gmail.com> wrote:
> >> [..]
> >>> 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. 

[toc] | [prev] | [next] | [standalone]

#8871

On 07/29/2011 09:58 AM, Thomas Boell wrote:
> On Fri, 29 Jul 2011 09:23:27 -0400
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
>> On 07/29/2011 08:38 AM, Thomas Boell wrote:
...
>>> 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...

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.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#8872

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

[toc] | [prev] | [next] | [standalone]

#8889

On 07/29/2011 10:56 AM, Willem wrote:
> 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.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#8897

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

[toc] | [prev] | [next] | [standalone]

#8899

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.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#8874

On Fri, 29 Jul 2011 10:42:10 -0400
James Kuyper <jameskuyper@verizon.net> wrote:

> On 07/29/2011 09:58 AM, Thomas Boell wrote:
> > On Fri, 29 Jul 2011 09:23:27 -0400
> > James Kuyper <jameskuyper@verizon.net> wrote:
> > 
> >> On 07/29/2011 08:38 AM, Thomas Boell wrote:
> ...
> >>> 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...
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#8875

On Jul 29, 9:23 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 07/29/2011 08:38 AM, Thomas Boell wrote:
>
>
>
>
>
>
>
>
>
> > On Fri, 22 Jul 2011 08:14:44 -0700 (PDT)
> > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote:
>
> >> On Jul 22, 4:11 pm, Francois Grieu <fgr...@gmail.com> wrote:
> >> [..]
> >>> 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.
> --
> James Kuyper

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

I will go for "goto".

regards,
ali

[toc] | [prev] | [next] | [standalone]

#8589

On 7/22/2011 10:11 AM, Francois Grieu wrote:
> On 2011/22/07 12:15, August Karlstrom wrote:
>> On 2011-07-22 08:49, Francois Grieu wrote:
>>> I just came into a case where I could use this:
>>>
>>> do
[... convoluted code that looks like "avoid goto at all costs" ...]
>>> while(0);
>>
>> I must be missing something. Why can't you just do something like this?
>>
>> cleanup = 0;
[... snip less-convoluted code ...]
>
> I *CAN*. But I'd rather not. I know that most if not all the compilers I use
> will not notice that the "cleanup" variable can be suppressed, and knowing
> that an extra variable exists and code is here to set and test it is causing
> me brain pain. I'd rather use two gotos (or a single goto and a deep nesting
> of ifs, which often will do the job), and get basically the "right" executable.
>
> 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.

Then I ask you, what's more important, avoiding "goto" or more efficient code?

> 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%.

I repeat my question above.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web