Malbolge programming

The Malbolge language has eluded many attempts to use it for some years. That was before Lou Scheffer published his cryptanalysis of the encryption algorithm it uses. This article walks the way he opened, explaining many of his findings in detail and other caveats that must be taken into account not mentioned by him.

Weaknesses
Malbolge's probably biggest piece of evilness comes from the encryption of instructions as they are executed. That encryption, fortunately, has a few weaknesses that make writing Malbolge programs feasible.

Jumps are not encrypted
First of all let's examine the order in which instruction fetching and execution is performed:


 * 1) Fetch the instruction from  and decrypt it.
 * 2) Execute the instruction.
 * 3) Encrypt the byte at.
 * 4) Increment.

In the case of the jump instruction, whose execution has the effect of changing the value of the code pointer  in step 2 above, the memory position that gets encrypted via step 3 is the final value of the code pointer, i.e. the address previous to the target of the jump, instead of the jump instruction itself which remains unencrypted. That's a great advantage as we will see later.

Cycles of length 2
Another weakness that can be exploited is the existence of length-2 cycles in the encryption step. Every possible instruction can be written as a 2-cycle in which the other instruction in the cycle is a NOP, that is, when an instruction is executed it turns into a NOP and when that NOP is executed it turns into the original instruction.

Here's a table of these memory addresses modulo 94 allowing period-2 instructions where the second is a NOP, together with the instruction itself (there are exactly two possible addresses for each of these instructions, so both are listed):

The remaining three instructions are irrelevant here:   is executed at most once per program,   is not encrypted as explained above, and   is part of the immutable NOPs mentioned below and the cycle length is not important.

Immutable NOPs
The last weakness that makes it practical to write Malbolge programs is the existence of at least one immutable NOP for every possible memory address. An immutable NOP is an instruction that always behaves as a NOP no matter the number of times it is executed. However very few addresses allow to directly enter immutable NOPs into the code because the range of allowed values in the source code is very limited. (Lou Scheffer notes that such values can always be entered by using a bug in the reference interpreter which allows values greater than 126 to be entered, then rotating with the   instruction, but other authors consider that making use of that bug is cheating.)

Note the distinction between the   instruction and any of the other NOPs: the former may be entered directly into the code while the latter can only be obtained by indirect means. Both can be immutable NOPs, though, depending on the address. The following addresses modulo 94 allow to directly enter an immutable NOP into the code by using the   instruction:

6, 8, 10, 17, 26, 27, 37, 42, 48, 51, 82, 86, 88, 92

In memory addresses other than these the   (NOP) instructions will mutate into a non-NOP instruction after a variable number of executions. For example, an   executed at position 0 modulo 94 will become a   after 29 executions.

The values 70 and 74 form the 2-cycle: an instruction with value 70 becomes 74 when executed and 74 becomes 70 and this is independent of the memory address (what is dependent is the meaning of that value). They are immutable NOPs for most addresses modulo 94. The following table lists all the addresses that are an exception to this rule, together with sample values which are immutable NOPs for them:

The importance of immutable NOPs can easily be seen by realizing that the data pointer  is incremented with every instruction executed, just as the code pointer, so in order to position the data pointer as required it's sometimes necessary to advance it by inserting NOP instructions in the code.

Putting all together
We'll see now how to take advantage of these weaknesses to write actual programs.

Program flux
Let's assume we want to execute the following code (as in the cat program):


 * 1) Input a character.
 * 2) Output the character.
 * 3) Jump to step 1.

Easy as it looks, it's not so easy to write in Malbolge. To start with, this must be translated to the following:


 * 1) Input a character (at address 43 mod 94)
 * 2) Jump to address 25 mod 94.
 * 3) Output a character (at address 25 mod 94)
 * 4) Jump to address 60 mod 94.
 * 5) Reload the data pointer to start again.
 * 6) Jump to address 43 mod 94.

Since the instructions are at addresses which form a 2-cycle, in the first execution all instructions will perform their function while in the second they will act as NOPs, then the cycle will start again.

Now it starts to look more promising, doesn't it? Unfortunately that's not the whole story.

Store operation
Crazy as it is, the crazy operator can be very useful. At a minimum it provides a mechanism for storing values into memory, which is necessary for almost any operation except the most basic ones as the above. For example, checking for EOF before printing the character is not possible without using at least a partial version of the store operation, because there's no way to examine the contents of the accumulator without altering it.

It has to be made in several steps. Prior to the store itself the memory address &lt;addr&gt; in which it is performed must be initialized to 1111111111 ternary (29524 decimal). This can be done in this way:


 * 1) Set  to 1111111111t (29524 decimal).
 * 2) Op into &lt;addr&gt;.
 * 3) Op into &lt;addr&gt;.

After step 3, the memory word at &lt;addr&gt; will contain 1111111111t no matter the initial value it contained. Now &lt;addr&gt; is ready for a value to be stored in it.

The store of the accumulator  into memory now consists of two steps: first OP the value into a location already containing 1111111111t; (this will swap the 0's and 1's in  ); then OP the resulting value into &lt;addr&gt; (this will unswap the 0's and 1's, leaving the original value stored in both   and &lt;addr&gt;). Note that this method makes it necessary to perform the above 3 steps into just another memory address. That's part of the fun of writing Malbolge programs.

Load operation
There are two simple(ish) ways of loading a value from memory into ; a straightforward one is to perform ten rotates, but this is very costly. There's another one using the crazy operator: load  with 2222222222t (this requires just one rotation), then OP into the address with the value to load, then load   again with 2222222222t, then OP again into that address. After these operations the accumulator will hold the value originally present in that address.

Not so easy as it looks
Now that we've reached the point where Scheffer stops let's continue from there, pointing out the problems that are encountered on the way. For now we'll assume that the memory can be preloaded at will, even if that's not the case.

Data pointer load operations need fixup
Let's remember the algorithm for writing a cat program which does not stop on EOF:


 * 1) Input a character (at address 43 mod 94)
 * 2) Jump to address 25 mod 94.
 * 3) Output a character (at address 25 mod 94)
 * 4) Jump to address 60 mod 94.
 * 5) Reload the data pointer to start again.
 * 6) Jump to address 43 mod 94.

The first point to note is that step 5 can't be performed every two cycles: it must take effect immediately or otherwise the jump addresses have to be repeated again, meaning an avoidable waste of preinitialized data space. The solution to this problem is to revert the   instruction at step 5 just after it's executed. The way of doing this is to re-execute or "pseudo-execute" it (a pseudo-execution means to jump to the instruction immediately following it, so that the encryption step is performed on it anyway). We add a step 5b executed after step 5:


 * 5b. Encrypt the   instruction of step 5.

This will complete the simplified version of the cat program. The design involves working with both the data and the code section at the same time, keeping track especially of the value of the  register, as follows (the choice of 97 as the start of the data area is arbitrary):

Data:

Code:

(Remember that both  and   are incremented between steps, and that the final value of   prior to the increment is the position that gets encrypted.)

This will loop forever; every two iterations it will input a byte and output it, and execute two NOPs at the next iteration. It does not stop on EOF; instead it outputs 2222222222t mod 256 = 168 repeatedly.

Now it should be apparent that it's possible to achieve execution of arbitrary code by means of jumping to the places where the instructions are to be executed, but there are still a few problems that need to be addressed: the overhead due to data manipulation and the initialization of memory with the desired values.

Initialization of memory
We've assumed that the memory can be preloaded at will, even if that's not the case. Why? Because it's possible (in principle) to create an initialization routine that is executed only once, with no loops or repetitions, so that there's no need to care about self-encryption. That routine's mission is to set up the memory just as needed. The problem is that the routine can be very expensive in terms of number of instructions used: many instructions may be needed for one single memory word to reach the desired value. Fortunately it's much easier in Malbolge to write execute-once code than reusable code.

Overhead due to data manipulation
With the programming method exposed above, when a memory word at address &lt;addr&gt; needs to be manipulated (e.g. for a store operation), for each instruction that acts on it there's a need of:


 * A data pointer that positions the data register before it via a   instruction (it can be before or after &lt;addr&gt;).
 * A program pointer to fix up that   instruction.
 * A program pointer that jumps to the instruction that manipulates &lt;addr&gt;.
 * A program pointer that jumps to the next instruction, which is probably a   if more operations on &lt;addr&gt; are needed.
 * A certain number of immutable NOPs around the instruction that make the data register skip other words used to manipulate the value at &lt;addr&gt; (if it's the only instruction manipulating &lt;addr&gt;, then these are not necessary).

As we've explained things, it's not possible to reuse an instruction which already has the desired number of immutable NOPs around it in the same turn of the main loop, because the second time it's executed it acts as a NOP. This means that either of these two approaches has to be taken: either the instructions have to be allocated (in different addresses which have the same value mod 94) or they have to be fixed up on the fly in the same manner as the   instruction was. The second approach is by far the most desirable one because it means just one extra program pointer per instruction, while the first one implies initialization of lots of immutable NOPs and allocation of many extra instructions. So we add one extra word of overhead to the ones already stated:


 * A program pointer to fix up the data manipulation instruction for reuse.

Now it may be more apparent why the approach of making ten rotate operations for one load was not the preferred one, as that would mean ten times the overhead explained above plus the initialization of it all.

Example: How to store the accumulator into memory (long)
Here's an example of a subprogram that stores the accumulator into a memory position, for the purpose of illustrating how the influence of the overhead mentioned above applies to Malbolge programs. Please note that the code is untested and there might be bugs; it's more an example than anything else. It's possible to reduce the total size, but not much. The code pointers use labels while the data addresses are expressed numerically. Address 200 is chosen as the target of the store/load operation and address 300 is chosen as the ancillary address that has to be filled with 1111111111t as part of the store operation. All instructions except   are assumed to be length-2 cycles. The labels for code pointers represent the address of the memory word prior to the address where the label points to. The labels starting with "R_" are the restoring addresses of the corresponding instructions. Thus, code pointers with this prefix directly point to the command's address instead of the memory word before the command. In general, special care must be taken to ensure that the address prior to the target of a jump always contains a character in the printable ASCII range (33-126) or the reference interpreter may crash. Execution starts with data register pointing to address 400.

Code:

Data starting at address 199 (target variable):

Data starting at address 299 (temporary variable):

Data starting at address 400 (initialization):

Data starting at address 500 (storing the value):

Trace:

Reducing the number of immutable NOPs
Instead of controlling the program flow with the code register, which means that all commands are written in their correct order filled with immutable NOPs, it is possible to control the program flow using the data register. This technique has been developed by Hisashi Iizawa et al. and has been used in their 99 bottles of beer program.

Using this technique every instruction in Malbolge (except Jmp) will only occur once in the whole program at a position where the encryption function has a 2-cycle, followed by a Jmp instruction (there may be some exceptions, but this is the basic idea). Thus we know that after the execution of every instruction a Jmp instruction will follow.

Example: Loading 0t1111111111 into the A register

The next data word will be a pointer to another Malbolge command, e.g. the crazy instruction, followed by the cell used by it.

When we control the program flow with the D register, branches can be executed by MoveD. If we use a MoveD instruction with a 2-cycle of the encryption function without a restore operation, we can build a loop that will be executed two times.

Using this technique it's possible to save many immutable NOPs, so the number of cells that have to be initialized decreases dramatically. Simple programs in Malbolge still need many memory cells. However, with this technique programs like a cat that halts on EOF are possible.

Programming with memory addresses is very confusing, and it may be time-consuming to manually write code in Malbolge to initialize the memory cells that are needed. To avoid this one can use a Malbolge assembler. Such an assembler can be found in the external resources: LMAO (Low-level Malbolge Assembler, Ooh!). LMAO comes with some examples written in the Malbolge assembler language HeLL (Hellish Low-level Language), so the user can understand the way HeLL works. One of the examples is a cat program that halts on EOF.

Introducing assembly language for Malbolge
Let's consider the example above and introduce labels for data pointers.

Variable val (offset 199):

Variable tmp (offset 299):

Initialization (offset 400):

Write value (offset 500):

We just introduced a Malbolge assembly language and got rid of absolute positions for code or data sections. Thus, the code above can be extended easily. A Malbolge program can be created from the assembly program above as follows. We must choose positions of code and data sections, replace labels by the address of the memory word prior to the address where the label points to, and write use-once Malbolge code to initialize everything. However, one may use a Malbolge assembler in order to automatize this process.

External resources

 * Lou Scheffer's discussion about Malbolge programming
 * Matthias Ernst's Malbolge assembler LMAO
 * Online Malbolge assembler