Re: language design implications for variant records in a pascal-like language

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Thu, 13 Jan 2011 07:59:55 +0000 (UTC)

          From comp.compilers

Related articles
[35 earlier articles]
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-10)
Re: language design implications for variant records in a pascal-like martin@gkc.org.uk (Martin Ward) (2011-01-12)
Re: language design implications for variant records in a pascal-like martin@gkc.org.uk (Martin Ward) (2011-01-12)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-12)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-01-12)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-13)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-13)
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-13)
Re: language design implications for variant records in a pascal-like noitalmost@cox.net (noitalmost) (2011-01-13)
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-14)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-14)
[15 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Thu, 13 Jan 2011 07:59:55 +0000 (UTC)
Organization: A noiseless patient Spider
References: 10-12-040 10-12-043 11-01-005 11-01-025 11-01-038
Keywords: design
Posted-Date: 14 Jan 2011 01:27:49 EST

Martin Rodgers <mcr@wildcard.demon.co.uk> wrote:
> George Neuner wrote:


>> Why do so many languages offer (at least) two forms of conditional
>> loop: one with the test at the beginning and another with the test at
>> the end? Why not just offer an infinite loop and a way to break out
>> that can be tied to any conditional?


> Because they behave differently. When you test at the entry point to
> a loop, the loop may run zero or more times. When you test at the
> end of the loop, just before the jump back to the beginning, you have
> a loop that will run one or more times.


The latter like Fortran DO loops on many systems before Fortran 77.
(and even though the standard didn't require, or even allow for, it.)


> This is why I shuddered with horror when I read that BBC Basic had
> REPEAT/UNTIL but no WHILE/WEND. I envisiged a host of bugs. Sure,
> you can write a REPEAT/UNTIL loop and put an IF/ENDIF around the
> code within it, but that's extra code and my cynical observation,
(snip)


> Another small point: almost every conditional loop I'd written up to that
> put had been a WHILE loop, not a REPEAT loop. This was true even when
> I wrote code in assembly language.


Yes "test at the top" loops are more common, but once in a while the
"test at the bottom" loop is needed. If you only have WHILE, then
you either code the whole loop contents once, outside the loop,
and then again inside the loop (if it is small), or use a variable
whose only purpose is to get into the loop the first time.


I might even have done something in C like:


      for(i=0; i==0 || (some other test) ; i++) {


where there is no other test on i, but that i might be needed
as a loop counter. (That is, there is no for with a test at the end.)


But otherwise, my first assembly programs were for S/360, where
the easiest loop instruction is BCT, something like "subtract one
and branch if not zero." That makes for a very easy "test at the end"
loop, using only one register. (But only if you can count backwards.)


That is much easier than BXH, which requires three registers, and
I would have to look up which one was which each time. There is
also the complementary BXLE, convenient for "test at the end" loops.
(That is, Branch if indeX High, and Branch if indeX Low or Equal.)


Even more, it has been found that on ESA/390 processors with
branch prediction, that BXH predicts not taken, and BXLE predicts
taken. It does that even for backward branch BXH and forward
branch BXLE.


> Several decades later, I still find that
> I'm writing zero-or-more loops, and *very* rarely one-or-more.


Rarely, but when they occur, you really want the right one.


(snip)


Now, why do some languages have DO ... UNTIL, where others have
DO ... WHILE for "test at the end" loops?


-- glen



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.