In this case the specific FOR NEXT loop in question is :

For X As UInt8 = 0 To 255 
  Dim strAnything As String = "Hello World" 
Next

If you run this code you’ll find that it runs forever. You’ve accidentally created an infinite loop.

How did this come to be this way? There are two things involved. One is what range of values a Uint8 can actually store. And the second is the actual code generated for the for loop itself. When these two combine the stopping conditions will never occur.

Uint8 values can hold a range of values like any integer. They are all positive. And the range is from 0 – 255.

So a Uint8 will NEVER hold a value > 255 or < 0.

Combine this with the fact that a FOR loop is generated using roughly this underlying code

Dim loopCounter As UInt8
Dim loopLimit As Integer = 255
Dim loopBase As Integer = 254
Dim loopStep As Integer = 1

loopCounter = loopBase

loopTop:
  If loopCounter > loopLimit Then
    GoTo loopEnd
  End If
  
  // loop body code would be here
  // its been elided to focus on the actual loop mechanics
  //    dim strAnything as string = "Hello World" 
  // 
  loopCounter = loopCounter + loopStep // NOTE THIS CAN CAUSE OVERFLOW !

  GoTo LoopTop

loopEnd:

This is NOT the actual code used. It is just a Xojo version of the actual underlying LLVM IR code that gets generated.

Hopefully this explains the confusion. Since a Uint8 cannot hold a value greater than 255, you will find that when loopCounter IS already 255 and the increment, or loopStep in this example, is added to the existing value the loopCounter goes NOT from 255 to 256 but back to 0. It wraps around. This isn’t a bug.

The addition of the loopStep value causes the Uint8 to overflow since the value 256, in binary, requires 9 bits, not 8 but the Uint8 can only hold 8 bits. And so when you add it the 8 bits the value can hold are all 0 and the loop counter resets to 0.

And this behavior is not specifically a Xojo thing, most programming languages do this. In fact, there are some very well know encryption algorithms, like BlowFish, that rely on this  .

In the specific sample code that prompted this post, a loop counter that is an Integer or Uint16 is needed because they can hold values that exceed the loops upper bound.

Loops that count down have a similar problem. but counting down and underflowing instead of overflowing.

The moral of the story is to stick to using the general Integer data type unless you have a specific need for a size-specific Integer type.

This is the fourth post in our Compiler series. Other posts:

• LLVM Everywhere
• Compilers 101 – Overview and Lexer
• Compilers 102 – Parser
• Compilers 103 – Semantic Analyzer

What is IR?

After the Semantic Analyzer, the next step is to turn the trees that it validated and added type information to into a representation that is much closer to what the machine is actually going to generate. This representation is called an intermediate representation (IR). The Xojo compiler, when building for 64-bit or ARM, uses LLVM IR.

The resulting LLVM IR describes the actual control flow of the program and every single thing that will be in the final program. In addition to the user-visible code that gets executed and the implicit conversions that are now in the trees, it also needs to contain all of the hidden, behind the scenes calls like reference counting and introspection metadata.

LLVM IR is actually higher level and more abstract than the actual assembly that it’ll end up generating. For example, unlike assembly language, it’s entirely strongly typed and the Xojo compiler has to be very precise in what it generates (which is a good thing!).

IR Code Generation

To get started, here is the abstract syntax tree that was previously created by the Semantic Analyzer:



To generate IR, the compiler walks through the above tree, depth first, to get to the leaf nodes. Doing this gets us to the BinaryOperator* for the multiple on the lower right side of the tree.

The LLVM IR to multiply those two values (mul) looks like this:

%1 = mul i32 2, 4

Now it works backwards through the tree. So the next item is the implicit cast, which has to cast the value that was calculated in the previous command:

%2 = sitofp i32 %1 to double

The sitofp IR command means “Signed Integer to Floating Point”.

Continuing up the tree, the binary operator is next, so it can now grab the left hand-side value to apply to the right-hand side value. This is the IR to add the values:

%3 = fadd double 3.14, %2

The fadd IR command means “floating point add”.

And continuing up the tree, the implicit cast is next:

%4 = fptosi double %3 to i32

The fptosi IR command means “floating point to signed integer”.

Lastly, we reach the actual assignment (store) with IR that looks like this:

store i32 %4, i32* @sum

Here is the complete IR that gets generated:

%1 = mul i32 2, 4
%2 = sitofp i32 %1 to double
%3 = fadd double 3.14, %2
%4 = fptosi double %3 to i32
store i32 %4, i32* @sum

Reading through this you should now understand why no one wants to manually write code at such a low-level.

This is the last part of the compiler that is considered to be part of the front end. The rest of the compiler components belong to the back end.