4 ms·
Come on, 5 instructions per BF operation? They're on x86 right? Let's assume your memory pointer is in ebx. (Substitute rbx for x64 code) (nasm syntax) +:
by tomsmeding 9y ago
Come on, 5 instructions per BF operation? They're on x86 right? Let's assume your memory pointer is in ebx. (Substitute rbx for x64 code) (nasm syntax)
+: inc byte [ebx]
-: dec byte [ebx]
>: inc ebx
<: dec ebx
[: cmp byte [ebx], 0
jz endlabel
startlabel:
]: cmp byte [ebx], 0
jnz startlabel
endlabel:
That's ignoring . and , which I expect do not occur very often. (If they did, their compute-focused architecture wouldn't be a good choice anyway.)
This is more like 1.3 instructions per command. How did they get their "5"?
- imtringued 9y agoEven basic optimizing compilers collapse consecutive + and - operations into a single constant size instruction and does a dozen other optimizations so in practice the instruction density is crazy high compared to naively executing every BF operation individually. It could have been interesting if they used an optimized ISA inspired by [1]. There's a reason why CPUs that can execute JVM bytecode directly never caught on: They cannot apply any of the optimizations that a JIT or compiler can. [1] http://calmerthanyouare.org/2015/01/07/optimizing-brainfuck.html http://calmerthanyouare.org/2015/01/07/optimizing-brainfuck....
- tomsmeding 9y agoOf course you collapse sequences of BF instructions, but then you get an even lower cpu-instructions / bf-command ratio. The paper gives 5/1, I claim it's at MOST 1.3/1, and with a basic optimising compiler you can get far below that of course.