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

Groups > comp.lang.python > #56907 > unrolled thread

Possibly better loop construct, also labels+goto important and on the fly compiler idea.

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

Contents

  Possibly better loop construct, also labels+goto important and on the fly compiler idea. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2013-10-17 01:36 +0200
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2013-10-17 01:44 +0200
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Ben Finney <ben+python@benfinney.id.au> - 2013-10-17 10:47 +1100
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Steven D'Aprano <steve@pearwood.info> - 2013-10-17 09:06 +0000
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 16:53 -0700
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Skip Montanaro <skip.montanaro@gmail.com> - 2013-10-17 19:39 -0500
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 17:41 -0700
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-18 08:40 +0100
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Chris Angelico <rosuav@gmail.com> - 2013-10-18 18:44 +1100
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-18 09:11 +0100
        Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-21 14:19 -0700
          Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Dave Angel <davea@davea.name> - 2013-10-22 03:34 +0000
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-17 17:43 -0700
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-18 08:42 +0100
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-21 22:35 +0100
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Bernhard Schornak <schornak@web.de> - 2013-10-23 15:13 +0200
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2013-10-24 22:02 +0200
        Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 15:13 +0100
        Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Bernhard Schornak <schornak@web.de> - 2013-10-28 10:58 +0100
        Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Bernhard Schornak <schornak@web.de> - 2013-10-28 11:49 +0100
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-25 11:57 -0700
      Don't use default Google Group client (was re:....) Terry Reedy <tjreedy@udel.edu> - 2013-10-25 16:05 -0400
        Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-25 16:44 -0700
          Re: Don't use default Google Group client (was re:....) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 01:19 +0100
            Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 07:58 -0700
              Re: Don't use default Google Group client (was re:....) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 16:38 +0100
                Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 21:36 -0700
          Re: Don't use default Google Group client (was re:....) Chris Angelico <rosuav@gmail.com> - 2013-10-26 11:25 +1100
            Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 07:55 -0700
          Re: Don't use default Google Group client (was re:....) Terry Reedy <tjreedy@udel.edu> - 2013-10-25 20:35 -0400
            Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 08:00 -0700
          Re: Don't use default Google Group client (was re:....) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 02:40 +0000
            Re: Don't use default Google Group client (was re:....) rusi <rustompmody@gmail.com> - 2013-10-26 05:15 -0700
              Re: Don't use default Google Group client Ben Finney <ben+python@benfinney.id.au> - 2013-10-27 00:02 +1100
              Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 08:07 -0700
              Re: Don't use default Google Group client (was re:....) Chris Angelico <rosuav@gmail.com> - 2013-10-27 00:25 +1100
                Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 21:43 -0700
            Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 08:05 -0700
              Re: Don't use default Google Group client (was re:....) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 17:24 +0000
                Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 21:33 -0700
              Re: Don't use default Google Group client (was re:....) Chris Angelico <rosuav@gmail.com> - 2013-10-27 09:15 +1100
                Re: Don't use default Google Group client (was re:....) rurpy@yahoo.com - 2013-10-26 21:45 -0700
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-10-25 22:09 +0100
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-26 13:37 -0700
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. rusi <rustompmody@gmail.com> - 2013-10-26 18:45 -0700
        Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Chris Angelico <rosuav@gmail.com> - 2013-10-27 12:56 +1100
          Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. rurpy@yahoo.com - 2013-10-27 22:29 -0700
        Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. rurpy@yahoo.com - 2013-10-26 22:04 -0700
          Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. rusi <rustompmody@gmail.com> - 2013-10-27 00:59 -0700
            Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. rurpy@yahoo.com - 2013-10-27 22:40 -0700
              Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. rusi <rustompmody@gmail.com> - 2013-10-27 22:56 -0700
                Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. rusi <rustompmody@gmail.com> - 2013-10-27 23:51 -0700
        Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-10-27 12:10 -0400
      Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. rusi <rustompmody@gmail.com> - 2013-10-27 03:53 -0700
    Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea. Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-26 19:02 -0700

Page 1 of 3  [1] 2 3  Next page →

#56907 — Possibly better loop construct, also labels+goto important and on the fly compiler idea.

version 0.01 created on 17 october 2013 by Skybuck Flying.
(after having some experience with python which lacks repeat 
until/goto/labels and programming game bots)
(the exit conditions described below prevent having to use logic inversion: 
while BeginCondition and not EndCondition <- ugly logic for while loops, 
below construct should be cleaner: LoopBegin(True)  LoopEnd(True)  instead 
of While (True and not True) therefore below construct is more consistent 
all conditions evaluate to true to trigger it's affect, begin=true, 
end=true)

Possibly a better looping construct for programming languages.

To understand why the proposed looping construct is better than existing 
constructs we first have to analyze and describe the problems with current 
existing looping constructs:

Programming languages: C, Pascal, Delphi, Java, Phython have the "while" 
construct:

while Conditions do
begin


end

Logically this loop makes no sense assuming the following 
theory/assumptions/concepts about loops:

Either a loop is something that always enters and continues forever until 
otherwise specified (most basic form)

Or a more clean approach:

A loop has a starting condition, a ending/exiting condition and additional 
exiting/continueing options.

Therefore a more basic construction could be:


LoopBegin( EnterConditions )

    if Conditions then LoopBreak

    if Conditions then LoopContinue

    if Conditions then LoopsExit

LoopEnd( ExitConditions )


^ This integrates the while loop and the repeat until loop of C and Pascal 
into one construct saving the programmer
from having to fiddle around with code... changing while to repeat until or 
vice versa.

This hereby indicates problems with the while loop: it makes little sense to 
put the exiting conditions at the top.

These belong at the bottom or in the intermediate code.

One drawback of this proposed new structure is that it introduces unnecesary 
complexities but those could be optional.

A cleaner loop construct could be:

LoopBegin

    if Conditions then LoopBreak

    if Conditions then LoopContinue

    if Conditions then LoopsExit

LoopEnd


This allows the programmer to place the beginning and exiting conditions 
anywhere.

Ofcourse the entering conditions could simply be omitted and still lead to 
valid code so they could be optional as mentioned above.


The LoopBreak would cause the loop to proceed to it's exit point.

The LoopsExit would cause all nested loops to proceed to the main exit 
point.

The loopContinue would cause the loop to skip all code and proceed back to 
the start of the loop.

After a while I think programmers would get more used to these kinds of 
programming constructs and don't have to choose between while or repeat 
until.

Another syntax form could be:

BeginLoop

    if Conditions then BreakLoop

    if Conditions then ExitLoops

    if Conditions then ContinueLoop

EndLoop

To be more inline with the Pascal Syntax.


Computer languages should also support labels and the goto statement so that 
code recovery from failures is more easy:

Example:

while True:
    Step1:
        ...Code...

    Step2:
        ...Code..

        if ...Failure.. then
            GoTo Step1


    Step3:

        ...Code...

        if ...Failure... then
            Goto Step 2

    Step 4:
        ... Code...

        if ... Failure... then
            GotTo Step 0

    Step 5:
        ... Code...

        if ...Special... then
            GoTo step 10

Unfortunately python does not have labels and goto statements as far as I 
know which makes the writing the following code a bit more complex and 
slower:


while True:

    if Step = 1:
        ... Code ...
        Step = Step + 1

    if Step = 2:
        ... Code ...

        if ...Failure... then
            GotoStep1

        Step = Step + 1

    etc

^ unnecessary step variable introduced to mimic goto+labels, unnecessary if 
statements introduced to support it.

Current problem with intel instruction set is instructions have variable 
size, this prevents using the instruction pointer to simply jump to certain 
instruction addresses.
(It's possible but it's hard to know where the addresses are, the idea below 
could solve this):

One possible solution could be to introduce a "on the fly compiler".

It compiles the code "on the fly" and indicates to the programmer where 
certain instruction addresses are.

Then perhaps the programmer can write code as follows:

    ... Code1 ...

    ... Code2 ...

        if Failure then
            GoTo CodeAddress1

    ... Code3 ...

        if Failure then
            GoTo CodeAddress2

The code addresses could be shown on the left side just as line numbers.


Possible problems introduced: when instruction code addresses would be off. 
Either the programmer has to correct this, or the IDE/Tool could auto 
correct it.

Leading to slightly more clean code and might make programming in 
machine-like languages more popular, these languages would offer more 
flexible and more power, especially
for writing high performing and robust code.

Perhaps even self modifying code programming languages in the future for 
artifical intelligence/evolving computer programs/warfare bots/etc,
a fixed size instruction set would be preferred for such a beast.

Bye,
  Skybuck. 

[toc] | [next] | [standalone]

#56908

One final example plus further analysis to be perfectly clear what fine code 
would look like and why it's adventage:

At the bottom I come to the conclusion that the proposed loop construct with 
begin and ending conditions has merit after all ! ;) =D

LoopBegin

    if not BeginningCondition then LoopBreak

    ...Code...

    if EndingCondition then LoopBreak

LoopEnd


This gives programmer full control over if the loop should be a while loop 
or a repeat until loop.

Should it have a beginning condition ?

Should it have a ending condition ?

Both can be writting without having to change the main loop statement block:

Begin

End

Also both kind of while/repeat until functionalities can be integrated.

It also allows to seperate logics, from begin/enter and end/exit.

There is one little problem with the above code:

the not, this is still logic inversion.

It could have been written as follows

if LoopSkipCondition then LoopBreak

However that's not convenient.

Therefore this posting must conclude that a special loop construct is 
usefull:

LoopBegin( EnterCondition )

LoopEnd( ExitCondition )

This would have allowed the code above to be written as:

LoopBegin( BeginningCondition )

LoopEnd( EndingCondition )

^ No logic inversion needed.

So this construct has merit after all.

Bye,
  Skybuck.

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

#56910

"Skybuck Flying" <Windows7IsOK@DreamPC2006.com> writes:

> version 0.01 created on 17 october 2013 by Skybuck Flying.

Thanks for writing your essay, but it's rather too long and context-free
to make a good post here.

Could you please post it on your weblog instead?

-- 
 \     “Beware of and eschew pompous prolixity.” —Charles A. Beardsley |
  `\                                                                   |
_o__)                                                                  |
Ben Finney

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

#56948

On Thu, 17 Oct 2013 01:36:36 +0200, Skybuck Flying wrote:

> Computer languages should also support labels and the goto statement so
> that code recovery from failures is more easy:

O_o

That's a very ... interesting ... statement.

Oh look, your post was cross-posted to no fewer than four newsgroups. 
What a surprise!



-- 
Steven

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

#57002

You know, I'd heard somewhere that Goto was considered harmful.... trying to remember exactly where....

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

#57007

[Multipart message — attachments visible in raw view] — view raw

On Oct 17, 2013 6:59 PM, "Peter Cacioppi" <peter.cacioppi@gmail.com> wrote:
>
> You know, I'd heard somewhere that Goto was considered harmful.... trying
to remember exactly where....

I can't tell if you were kidding or not... Just in case:

http://en.m.wikipedia.org/wiki/Considered_harmful

(can't grab the [2] & [3] links on my phone)

Skip

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

#57009

[Multipart message — attachments visible in raw view] — view raw

yes it was a joke, apparently not a good one



On Thu, Oct 17, 2013 at 5:39 PM, Skip Montanaro <skip.montanaro@gmail.com>wrote:

>
> On Oct 17, 2013 6:59 PM, "Peter Cacioppi" <peter.cacioppi@gmail.com>
> wrote:
> >
> > You know, I'd heard somewhere that Goto was considered harmful....
> trying to remember exactly where....
>
> I can't tell if you were kidding or not... Just in case:
>
> http://en.m.wikipedia.org/wiki/Considered_harmful
>
> (can't grab the [2] & [3] links on my phone)
>
> Skip
>

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

#57034

On 18/10/2013 00:53, Peter Cacioppi wrote:
> You know, I'd heard somewhere that Goto was considered harmful.... trying to remember exactly where....
>

Yep, but it's used throughout the CPython code for error handling, 
nothing wrong with that as it's crystal clear that you're going to one 
place for one purpose.  Contrast that with its use in spaghetti code 
where you're leaping around like a naked person on an ant hill.

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

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

#57035

On Fri, Oct 18, 2013 at 6:40 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 18/10/2013 00:53, Peter Cacioppi wrote:
>>
>> You know, I'd heard somewhere that Goto was considered harmful.... trying
>> to remember exactly where....
>>
>
> Yep, but it's used throughout the CPython code for error handling, nothing
> wrong with that as it's crystal clear that you're going to one place for one
> purpose.  Contrast that with its use in spaghetti code where you're leaping
> around like a naked person on an ant hill.

How bad can it be?

http://xkcd.com/292/

ChrisA

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

#57038

On 18/10/2013 08:44, Chris Angelico wrote:
> On Fri, Oct 18, 2013 at 6:40 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 18/10/2013 00:53, Peter Cacioppi wrote:
>>>
>>> You know, I'd heard somewhere that Goto was considered harmful.... trying
>>> to remember exactly where....
>>>
>>
>> Yep, but it's used throughout the CPython code for error handling, nothing
>> wrong with that as it's crystal clear that you're going to one place for one
>> purpose.  Contrast that with its use in spaghetti code where you're leaping
>> around like a naked person on an ant hill.
>
> How bad can it be?
>
> http://xkcd.com/292/
>
> ChrisA
>

Love it :)

See also http://matplotlib.org/xkcd/index.html ???

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

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

#57209

Just because the CPython implementation does something doesn't mean that thing is something other than risky/tricky/to-be-avoided-if-possible. Python (and it's implementations) exist so that ordinary people can avoid doing risky stuff.

I'm not critiquing the CPython implementation here, I'm pointing out that some languages are just better than others for most projects. Working in a higher level where gotos aren't needed is the right call most of the time. 

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

#57228

On 21/10/2013 17:19, Peter Cacioppi wrote:

> Just because the CPython implementation does something doesn't mean

If you're going to drop messages in here with no context, you'd be
better off just putting it in a bottle and tossing it into the sea. 

Include a quote from whomever you're responding to, and we might
actually take you seriously.  And of course, make sure you don't delete
the attribution.

-- 
DaveA

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

#57008

Cmon, Skip, assuming everyone gets the "considered harmful" reference falls under the "we're all adults here" rubric.

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

#57036

On 18/10/2013 01:43, Peter Cacioppi wrote:
> Cmon, Skip, assuming everyone gets the "considered harmful" reference falls under the "we're all adults here" rubric.
>

Context, context everywhere.... trying to remember exactly where....

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

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

#57211

On 17/10/2013 00:36, Skybuck Flying wrote:
>
> Unfortunately python does not have labels and goto statements as far as
> I know
>

http://entrian.com/goto/

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57360

Skybuck Flying schrieb:


> This hereby indicates problems with the while loop: it makes little sense to put the exiting
> conditions at the top.


Why?

      ...
      dec     rcx
      jbe     1f
    0:some
      code
      to
      perform
      ...
      jmp     0b

      p2align 5,,31
    1:continue
      with
      something
      else
      ...

This code triggers one penalty if RCX was zero or negative (it jumps directly
to label 1 after the penalty for the wrong assumption "not taken" passed by),
or two penalties if RCX was positive - one for the 2nd assumption is "taken",
one for the finally taken conditional jump.

The same applies if you moved the condition check to the end of the loop, but
you could not catch negative numbers / zero without executing the code in the
loop at least once.

There is no general rule which construct should be preferred. In the end, the
one suiting your needs might be the best choice. On the other hand, no one is
able to predict which code might be generated by a specific HLL-compiler.


Greetings from Augsburg

Bernhard Schornak

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

#57515

Because it's logical.

If the exit condition was placed on the top, the loop would exit immediatly.

Instead the desired behaviour might be to execute the code inside the loop 
first and then exit.

Thus seperating logic into enter and exit conditions makes sense.

Bye,
  Skybuck. 

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

#57524

On 24/10/2013 21:02, Skybuck Flying wrote:
> Because it's logical.
>
> If the exit condition was placed on the top, the loop would exit
> immediatly.
>
> Instead the desired behaviour might be to execute the code inside the
> loop first and then exit.
>
> Thus seperating logic into enter and exit conditions makes sense.
>
> Bye,
>   Skybuck.

Are you replying to Her Majesty the Queen, President Obama or whom? 
What context is this in?

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#57807

Skybuck Flying wrote:


> Because it's logical.


What is logical?


> If the exit condition was placed on the top, the loop would exit immediatly.


This might be the programmer's intention?


> Instead the desired behaviour might be to execute the code inside the loop first and then exit.


It might ... but it might be something very different, too.

Let us assume a function with variable iteration count for its loop, where the
count is passed as parameter.  If the loop body always was executed completely
before the final conditional test, we had to check at least the iteration count to avoid crashes if the
iteration count is used as an array index, someone passed a negative number or
zero.  Moreover, we had to restore all data manipulated by instructions inside
the loop body if we only wanted to alter data whenever the final condition was
met.


> Thus seperating logic into enter and exit conditions makes sense.


No. It introduces tons of -avoidable- extra cycles, but nothing of true value.
If exit code always was placed at the bottom, and we have a loop with variable
iterations passed as one of the function's input parameters, we had to reverse
all manipulations applied within the loop, if the exit conditions were not met
at the end of the first iteration. Moreover, every erroneously passed negative
iteration count caused a crash if the passed count was used as an array index.
Hence, we had to insert input parameter tests prior to the first execution of
the loop, adding more misprediction penalties.

To get a picture: Each misprediction penalty costs an absolute minimum of ~ 20
clock cycles on recent machines. It surely is not zher best idea to add a lot
of mispredictions with the (questionable) intention to force other programmers
to obey your universal "Condition checks belong to the bottom!" law.

As assembler programmers, we can write the fastest possible code without being
bound to counter-productive rules. Compiler developers who declare conventions
just to force programmer to use delay mechanisms like "condition checks belong
to the bottom!" are a dangerous species. With compilers like that, it is quite
obvious why software became slower and slower while processor power is growing
from one hardware generation to the next.


BTW: I placed label 0 at the wrong place. The proper loop should look like this:

func:...
      ...
    0:dec     rcx
      jbe     1f
      ...
      some
      code
      to
      perform
      ...
      jmp     0b

      p2align 5,,31
    1:continue
      with
      something
      else
      ...


Greetings from Augsburg

Bernhard Schornak

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

#57809

Due to unknown "improvements", SeaMonkey's built-in news editor meanwhile ignores
saved changes and sends long deleted text parts rather than thwe last seen text -
"What you See Is _Not_ What You Get"...

This is the real reply to Skybuck's posting. Please ignore the mixture of deleted
text parts, older and newer text posted at 10:58 h.  Unfortunately, the option to
remove messages from the server became the victim of another "improvement", so it
is impossible for me to delete the other post.

Bernhard Schornak



Skybuck Flying wrote:


> Because it's logical.


What is logical?


> If the exit condition was placed on the top, the loop would exit immediatly.


This might be the programmer's intention?


> Instead the desired behaviour might be to execute the code inside the loop first and then exit.


With a 50 percent chance it might not. Are we fortune tellers who guess which one
might be true?


> Thus seperating logic into enter and exit conditions makes sense.


Let us assume a loop with variable iterations where the iteration count is passed
as function parameter. The code inside the loop body uses this iteration count as
index into an array and alters data in other arrays depending on computations and
set flags.

If we probed the loop's repeat condition at the end of the loop body per default,
we had to verify the passed iteration count before we enter the loop - otherwise,
the program crashed with erroneously passed negative numbers. We also had to sort
out zero. Otherwise, we started a count down through the full 32 or 64 bit range.
The last problem pops up, if the loop's repeat condition isn't met. In this case,
we had to restore all altered data before we could continue with the instructions
following the loop body.

Programming on machine language level grants us the freedom to create the fastest
possible code. It is no good idea to slow down our code just to obey questionable
"Universal Laws".


BTW: I placed label 0 at the wrong place. The proper loop should look like this:

func:...
      ...
    0:dec     rcx
      jbe     1f
      ...
      some
      code
      to
      perform
      ...
      jmp     0b

      p2align 5,,31
    1:continue
      with
      something
      else
      ...


Greetings from Augsburg

Bernhard Schornak

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web