Malbolge-T versus binaries

[Arariel]

Which would be more difficult to write/read from the perspective of a programmer? Binaries, or software written in a Turing-complete dialect of Malbolge?

[EvanED]

Are you allowing at least some degree of assembly? (I.e. you can write it, and at least do some degree of trace-based disassembly for reading?)

Writing assembly is almost certainly easier.

[Arariel]

Well, yeah, assembly is definitely easier since people have actually written useful programs in it. But what about Malbolge-T versus pure binary?

[Carnildo]

I've programmed in binary. I've looked at Malbolge. I'd rather program in binary than try to do anything with Malbolge.

[Goplat]

No contest, writing machine code in binary is much easier by far. In fact, that's how people had to program before there were assemblers.

Compared to assembly, there are just two added difficulties:

• Having to use opcodes instead of mnemonics. A fair amount of work when you're getting started but once you've got some experience and have most of the common ones memorized it wouldn't be too bad.
• Having to use addresses instead of labels. This is definitely the larger handicap. To call a subroutine you have to know its address, and any time you insert code in the middle of your program the address of everything after it changes so you'd have to go back and adjust all the calls (it would be very easy to miss one...) Instead of inserting code you could patch in a jump to the end, append the code you want to insert followed by a jump back, but this would quickly turn into a mess of "spaghetti". If you're willing to waste space, you could make it easier for yourself by aligning functions to multiples of 256 bytes, or something like that; this would make addresses easier to remember, and would give code room to expand, thus avoiding fragmentation.

However, Malbolge not only has all the same difficulties as machine language, but also has an instruction set that makes it very difficult to do even ordinary things like addition and subtraction (which are both single instructions in any CPU's instruction set), and worst of all is the forced self-modification.

[korona]

I had to write an assembler once so I have some experience at programming in binary. It is not too hard to memorize the most common opcodes. The biggest problem is that, when working with an architecture that has non-constant instruction lengths, it is hard to figure out where instructions start. You basically have to either guess (for example: in x86 assembly 0xEB is often a relative jump with 1-byte offset but it also could be an immediate operand of another instruction) or read the whole basic block from the beginning.
Writing a hello world program in x86 assembly can be done in a few hours even if one has not seen any binary programs before.

[Derek]

The biggest problem is that, when working with an architecture that has non-constant instruction lengths, it is hard to figure out where instructions start. You basically have to either guess (for example: in x86 assembly 0xEB is often a relative jump with 1-byte offset but it also could be an immediate operand of another instruction) or read the whole basic block from the beginning.

This just gave me a hilariously bad idea for obfuscated assembly: Write the code in such a way that a mis-aligned jump causes a completely different set of instructions to execute (so the same bits are run twice, but with different alignment and so different instructions).

[EvanED]

This just gave me a hilariously bad idea for obfuscated assembly: Write the code in such a way that a mis-aligned jump causes a completely different set of instructions to execute (so the same bits are run twice, but with different alignment and so different instructions).

It's called "instruction aliasing" (at least, that's what "we" call it), and it's totally possible to do on x86 though not on your typical RISC architecture, as executing a misaligned instruction will cause a trap. ("typical" is not a thoroughly-researched claim.) There are actually somewhat important security consequences to the ability to execute "misaligned" instructions.

Interesting thing though: on x86, I think what you usually wind up seeing is that the aliased sequences aren't particularly long, as they tend to naturally realign. You might be able to force something different though; what I described is what happens if you look at what sort of "phantom" sequences are available in normal code. (In retrospect this isn't surprising -- in fact, it'd be surprising if it didn't happen -- but you might not think of it a priori.)

[Xanthir]

Given how long it took for someone to figure out how to write Hello World in Malbolge, the answer is pretty trivial, as others in this thread have explained. Binary is only somewhat less convenient than assembly.

[Carnildo]

The biggest problem is that, when working with an architecture that has non-constant instruction lengths, it is hard to figure out where instructions start. You basically have to either guess (for example: in x86 assembly 0xEB is often a relative jump with 1-byte offset but it also could be an immediate operand of another instruction) or read the whole basic block from the beginning.

This just gave me a hilariously bad idea for obfuscated assembly: Write the code in such a way that a mis-aligned jump causes a completely different set of instructions to execute (so the same bits are run twice, but with different alignment and so different instructions).

I've seen it. It gave my disassembler fits.

[Derek]

The biggest problem is that, when working with an architecture that has non-constant instruction lengths, it is hard to figure out where instructions start. You basically have to either guess (for example: in x86 assembly 0xEB is often a relative jump with 1-byte offset but it also could be an immediate operand of another instruction) or read the whole basic block from the beginning.

This just gave me a hilariously bad idea for obfuscated assembly: Write the code in such a way that a mis-aligned jump causes a completely different set of instructions to execute (so the same bits are run twice, but with different alignment and so different instructions).

I've seen it. It gave my disassembler fits.

I would love to see that, if you have a link.

[letterX]

The biggest problem is that, when working with an architecture that has non-constant instruction lengths, it is hard to figure out where instructions start. You basically have to either guess (for example: in x86 assembly 0xEB is often a relative jump with 1-byte offset but it also could be an immediate operand of another instruction) or read the whole basic block from the beginning.

This just gave me a hilariously bad idea for obfuscated assembly: Write the code in such a way that a mis-aligned jump causes a completely different set of instructions to execute (so the same bits are run twice, but with different alignment and so different instructions).

I've seen it. It gave my disassembler fits.

I would love to see that, if you have a link.

I've done it too -- I was writing in a bootloader that sucked in chunks of compiled code from disk and started executing them. Except that I had an off-by-one error in which instruction to jump to.

Confused the hell out of me. There are instructions that should just never be named...

[Arariel]

So if someone wrote a [insert language here]-to-Turing-complete-Malboge translator (if that's possible at all), wouldn't the resultant code technically be open source, yet more difficult to read/edit than binaries?

[Carnildo]

The biggest problem is that, when working with an architecture that has non-constant instruction lengths, it is hard to figure out where instructions start. You basically have to either guess (for example: in x86 assembly 0xEB is often a relative jump with 1-byte offset but it also could be an immediate operand of another instruction) or read the whole basic block from the beginning.

This just gave me a hilariously bad idea for obfuscated assembly: Write the code in such a way that a mis-aligned jump causes a completely different set of instructions to execute (so the same bits are run twice, but with different alignment and so different instructions).

I've seen it. It gave my disassembler fits.

I would love to see that, if you have a link.

No link. I found it while inspecting a floppy disk with a custom "this is not a bootable floppy" message.

[troyp]

So if someone wrote a [insert language here]-to-Turing-complete-Malboge translator (if that's possible at all), wouldn't the resultant code technically be open source, yet more difficult to read/edit than binaries?

I'm not sure of the details of OSI's definition of "open source", but it certainly wouldn't be free software under the FSF's definition (or, really, any reasonable definition).

In the GPL, for instance, "source code" is defined as the form in which the software is most easily written and modified (cba to look up the verbatim definition). So obfuscated or minified "source" for instance, doesn't qualify.

[lorb]

And by the way: no one has ever really coded something in malbolge. The existing "Hello World" was found by a program done in lisp. So to be fair you would have to allow the binary-people to use secondary helper languages as well, which really boils down to normal coding.