Are while(1) and for(;;) really the same?

May 21, 2019

Programmers have long said that writing while(1) can be replaced by the more compact form for(;;). However, I have always wondered: apart from syntax, are there any differences under the hood in how they function? If so, we should know about it so we use the more efficient form.

To answer this question, we need to look under the hood. Whether they are the same boils down to CPU-level instructions. Each CPU runs on a set of possible instructions that it can do, and together, they form the CPU architecture. Instructions are the basic building blocks of every program; ultimately, everything is compiled down to machine instructions to be run. When an instruction is run, it completes a single action that the architecture has defined. Ultimately, a programming language will translate actions down into instructions to be run on the CPU, whether through an intermediate programming language or through directly compiling down to machine code. Therefore, we can judge if while(1) and for(;;) are functionally the same if their machine code matches.

Instead of dealing with a higher level language like Java or Python, I'm choosing C because it compiles to object code, which can be disassembled to get the assembly instructions. If the assembly instructions match, then while(1) and for(;;) are functionally equivalent. I wrote two functions in C that are nearly identical except one uses while(1) and the other uses for(;;):

void func1(int x) {
    while (1) {
        x++;
    }
}
void func2(int x) {
    for (;;) {
        x++;
    }
}

I put these functions in their own files, func1.c and func2.c. In each file, I call the function afunc to maintain consistency.

For this example, I will use AArch64 (the architecture of ARMv8 and beyond) assembly instructions to demonstrate.

On the command line, I do the following to compile these functions to object code and then dump it into a disassembled assembly file:

$ gcc -c func1.c -O0
$ gcc -c func2.c -O0
$ objdump -D func1.o > func1.disas
$ objdump -D func2.o > func2.disas
$ diff func1.disas func2.disas

The -c flag tells GCC to only compile down to the object code (.o file) while the -O0 flag tells GCC to not optimize the instructions that it performs.

It turns out that the diff proves that func1 and func2 are completely the same. Here they are:

func1.disas:

func1.o:     file format elf64-littleaarch64

Disassembly of section .text:

0000000000000000 <afunc>:
   0:   d10043ff    sub sp, sp, #0x10
   4:   b9000fe0    str w0, [sp,#12]
   8:   b9400fe0    ldr w0, [sp,#12]
   c:   11000400    add w0, w0, #0x1
  10:   b9000fe0    str w0, [sp,#12]
  14:   17fffffd    b   8 <afunc+0x8>

Disassembly of section .comment:

0000000000000000 <.comment>:
   0:   43434700    .inst   0x43434700 ; undefined
   4:   4c28203a    .inst   0x4c28203a ; undefined
   8:   72616e69    .inst   0x72616e69 ; undefined
   c:   4347206f    .inst   0x4347206f ; undefined
  10:   2e352043    usubl   v3.8h, v2.8b, v21.8b
  14:   30322d35    adr x21, 645b9 <afunc+0x645b9>
  18:   312e3731    adds    w17, w25, #0xb8d
  1c:   35202930    cbnz    w16, 40540 <afunc+0x40540>
  20:   302e352e    adr x14, 5c6c5 <afunc+0x5c6c5>
    ...

func2.disas:

func2.o:     file format elf64-littleaarch64

Disassembly of section .text:

0000000000000000 <afunc>:
   0:   d10043ff    sub sp, sp, #0x10
   4:   b9000fe0    str w0, [sp,#12]
   8:   b9400fe0    ldr w0, [sp,#12]
   c:   11000400    add w0, w0, #0x1
  10:   b9000fe0    str w0, [sp,#12]
  14:   17fffffd    b   8 <afunc+0x8>

Disassembly of section .comment:

0000000000000000 <.comment>:
   0:   43434700    .inst   0x43434700 ; undefined
   4:   4c28203a    .inst   0x4c28203a ; undefined
   8:   72616e69    .inst   0x72616e69 ; undefined
   c:   4347206f    .inst   0x4347206f ; undefined
  10:   2e352043    usubl   v3.8h, v2.8b, v21.8b
  14:   30322d35    adr x21, 645b9 <afunc+0x645b9>
  18:   312e3731    adds    w17, w25, #0xb8d
  1c:   35202930    cbnz    w16, 40540 <afunc+0x40540>
  20:   302e352e    adr x14, 5c6c5 <afunc+0x5c6c5>
    ...

Because the results are the exact same, this proves that while(1) and for(;;) are actually functionally equivalent when compiled for this specific case. Of course, by some anomaly, maybe they will be different, but that is highly unlikely with the GNU C Compiler, whether for AArch64 or x86-64.

I also tried this with -O3 optimization and instead of doing sub, str, ldr, add, str, and finally b, it skipped all of that and simply had a lone b instruction that referred to itself. Unfortunately, the processor does not raise an exception when the program counter is the same as the argument of b, which I found a little concerning. (The program counter is a special-purpose register inside the CPU that contains the memory address of the instruction that the CPU is currently executing. b is an instruction that branches—or in x86 terms, jumps—to the address specified.)

This neat little technique was first shared by my Computer Architecture professor. It's a great way to ensure that programming hacks are actually good hacks below the surface, not just what appears to the programmer.

Back to blog

Back to top