I continue to pursue the ability to do “useful programming” with a popular EPL which I abbreviate BF (simply because I don’t want to type the name.. thanks Mueller).
I was thinking about a few of things.
1) There are only 8 instructions, represented by + – > < . , [ ] and usually stored in a byte array. This is inefficient.
2) A while back, I had some good success with C style macros and BF code. I’ve since had a few ideas that involve something similar, but with XML.
So, I’ve come up with a bytecode that is useful for making BF programs run faster.
At first, I decided to pack the value 0-7 into the upper three bits of a byte to represent the BF command. The remaining 5 bits would be a repeat count, so I could shorten the length of the instructions by a factor of 31 (potentially).
But then I realized that while repeat counts make sense for + – < > they don’t make as much sense for [ ] , . as these operators rarely repeat.
Also a repeat count of 0 is meaningless and would never be used.
Fortunately, this left me with four operations that could use repeat counts and four that didn’t need them, but could use the 0 repeat counts for the other operators.
So, here’s the bytecode map:
0×00: .
0×01 – 0×3f: + (from 1 to 63)
0×40: ,
0×41 – 0×7f: – (from 1 to 63)
0×80: [
0x81 - 0xBF: > (from 1 to 63)
0xC0: ]
0xC1 – 0xFF: < (from 1 to 63)
Yes, these could wind up moved around, but it winds up basically the same.
So, we wind up using ever value from 0×00 to 0xFF, with repeat counts of up to 63 for those operations that are most likely to use them.
This enhancement should easily speed up an interpreter.
