Simulating Exploding Dice Your task is to make a program that takes in an integer n &gt; 1, and outputs the roll of a single n-sided die. However, this dice follows the rules for exploding dice.

When you roll the die, check what value you rolled. If you got the maximum for that kind of die (on a standard d4 that would be 4, or 6 on a d6, etc.), roll again and add the new roll to that total. Each roll continues adding to the total, until you don't roll the max number anymore. That final number is still added though.

Your program should take in a single integer n, and roll the exploding n-sided die. Here's an example distribution to show what it should look like for n=4. Note that you should never output any multiples of n, since they will always explode. 

You can assume the stack size for any recursion you do is infinite, and your random function must meet our standards for randomness (built-in random generator or time/date). Your random function should also be as uniform as possible, vs. something like a geometric distribution, since these are dice we're talking about.
x86 Machine Code (for Intel Ivy Bridge and later), 17 bytes

31 C9 0F C7 F0 31 D2 F7 F6 42 01 D1 39 F2 74 F2 C3


The above bytes of code define a function that simulates an exploding die. It takes a single input, passed in the ESI register, indicating the maximum number of the die. It returns a single value in the ECX register, which is the result of the rolls.

Internally, it uses the RDRAND instruction to generate a random number. This uses a random number generator (RNG) that is built into the hardware on Intel Ivy Bridge processors and later (some AMD CPUs also support this instruction).

The logic of the function is otherwise quite straightforward. The generated random number is scaled to lie within the desired range using the standard technique ((rand % dieSize) + 1), and then it is checked to see if it should cause an explosion. The final result is kept in an accumulator register.

Here is an annotated version showing the assembly language mnemonics:

           unsigned int RollExplodingDie(unsigned int dieSize)
31 C9        xor     ecx, ecx    ; zero-out ECX, which accumulates the final result
           Roll:
0F C7 F0     rdrand  eax         ; generate a random number in EAX
31 D2        xor     edx, edx    ; zero-out EDX (in preparation for unsigned division)
F7 F6        div     esi         ; divide EDX:EAX by ESI (the die size)
                                 ;   EAX receives the quotient; EDX receives the remainder
42           inc     edx         ; increment the remainder
01 D1        add     ecx, edx    ; add this roll result to the accumulator
39 F2        cmp     edx, esi    ; see if this roll result should cause an explosion
74 F2        jz      Roll        ; if so, re-roll; otherwise, fall through
C3           ret                 ; return, with result in ECX register


I am cheating a bit. All standard x86 calling conventions return a function's result in the EAX register. But, in true machine code, there are no calling conventions. You can use any registers you want for input/output. Using ECX for the output register saved me 1 byte. If you want to use EAX, insert a 1-byte XCHG  eax, ecx instruction immediately before the ret instruction. This swaps the values of the EAX and ECX registers, effectively copying the result from ECX into EAX, and trashing ECX with the old value of EAX.

Try it online!

Here's the equivalent function transcribed in C, using the __builtin_ia32_rdrand32_step intrinsic supported by GCC, Clang, and ICC to generate the RDRAND instruction:

#include &lt;immintrin.h&gt;

unsigned int RollExplodingDie(unsigned int dieSize)
{
    unsigned int result = 0;
Roll:
    unsigned int roll;
    __builtin_ia32_rdrand32_step(&amp;roll);
    roll    = ((roll % dieSize) + 1);
    result += roll;
    if (roll == dieSize)   goto Roll;
    return result;
}


Interestingly, GCC with the -Os flag transforms this into almost exactly the same machine code. It takes the input in EDI instead of ESI, which is completely arbitrary and changes nothing of substance about the code. It must return the result in EAX, as I mentioned earlier, and it uses the more efficient (but larger) MOV instruction to do this immediately before the RET. Otherwise, samezies. It's always fun when the process is fully reversible: write the code in assembly, transcribe it into C, run it through a C compiler, and get your original assembly back out!