🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.c.moderated
Article #2221

Re: use of the break statement

#2221
From: Konrad Schwarz
Date: Sun, 10 Mar 1996 16:31
62 lines
2663 bytes
In article <4hqedf$1m0@solutions.solon.com>, kanze@gabi-soft.fr (J. Kanze) writes:
|> In article <4hladl$4cr@solutions.solon.com> Andrew Dalgleish
|> <andrewd@axonet.com.au> writes:
|> 
|> |> Compare snippet 'A':
|> |> long	l;
|> |> for (l = 0L; l < 1000000L; l++) {
|> |>   /* Stuff before test */
|> |>   if (condition) {
|> |>     break;
|> |>   }
|> |>   /* Stuff after test */
|> |> }
|> 
|> |> To snippet 'B':
|> |> long	l;
|> |> {
|> |>   /* Extra braces to limit scope of bBreak */
|> |>   BOOL	bBreak = FALSE;
|> |>   for (l = 0L; !bBreak && l < 1000000L; l++) {
|> |>   /* Stuff before test */
|> |>     if (condition) {
|> |>       bBreak = TRUE;
|> |>     } else {
|> |>       /* Stuff after test */
|> |>     }
|> |>   }
|> |> }
|> 
|> |> Example B may evaluate "bBreak" a million times.
|> |> It is *possible* that "condition" never evaluates TRUE, 
|> |> so you've evaluated "bBreak" a 1,000,001 times for nothing.
|> 
|> If this is the case, I would suggest that you change compilers.  I can
|> imagine cases where the control flow would be complex enough that the
|> compiler might have problems simplifying it, but this is certainly not
|> one of them.

Digital Unix (OSF/1) on Alpha processors has had the best SpecInt and SpecFP
performance within the last half year.

The native C compiler does not simplify snippet_B to snippet_A
if ``condition'' is replaced by ``1 == sin (l)''
and ``/* Stuff before test */'' and ``/* Stuff after test */''
is replaced by ``printf ("%ld\n", l);''.

snippet_A needs two labels, snippet_B needs three.

compiled with 
	c89 -c -migrate -std1 -source_listing -machine_code -O5 bbreak.c -lm

(-migrate, so I can get -O5 optimization (highest);
-source_listing -machine_code seems to be produced later than -S, also,
-S can't be used with -migrate, -std1 is a probably redundant force of ANSI C).

This was verified by disassembling bbreak.o, so that all assembler optimizations
are factored in.

Machine code listing available on request, omitted here as a waste of bandwidth.


Konrad Schwarz
Technical Details
Message-ID: <4hv05r$jaa@solutions.solon.com>
Path: arc1-ca.pugleaf.net!solon.com!not-for-mail
References: <4gfcl7$2ls@solutions.solon.com> <4gnbcp$biq@solutions.solon.com> <4h81gh$aql@solutions.solon.com> <4h9ml2$gub@solutions.solon.com> <4hqedf$1m0@solutions.solon.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!solon.com!not-for-mail
From: schwarz@a2.complang.tuwien.ac.at (Konrad Schwarz)
Newsgroups: comp.lang.c.moderated
Subject: Re: use of the break statement
Date: 10 Mar 1996 10:31:55 -0600
Organization: TU Wien
Sender: clc@solutions.solon.com
Approved: clc@solutions.solon.com
Message-ID: <4hv05r$jaa@solutions.solon.com>
References: <4gfcl7$2ls@solutions.solon.com> <4gnbcp$biq@solutions.solon.com>  <4h81gh$aql@solutions.solon.com> <4h9ml2$gub@solutions.solon.com> <4hqedf$1m0@solutions.solon.com>
NNTP-Posting-Host: solutions.solon.com