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:
0x01 – 0x3f: + (from 1 to 63)
0x41 – 0x7f: – (from 1 to 63)
0x81 – 0xBF: > (from 1 to 63)
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 0x00 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.