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

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


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