BFK - My brainf**k compiler

[shikhin]

Hi,

Code: Select all

    if(NeedToFixBug() && IsWeekend())
        GetBored();

So, yes, I was bored. Yes, I wrote a Brainf**k compiler in the meanwhile. Yes, I am a little whacky.

Anyway, here I go about to present before you:

The world's best optimizing Brainf**k compiler. The compiler is built for all BF enthusiastics, who want to write small, fast and elegant programs in BF. In the future, I'd even extend the language, to at least support File I/O, and probably whatever you suggest.

The code can be seen at http://github.com/Shikhin/BFK

How can I help?
You can help in various ways, two of which are:

• You can improve my code quality (which is poor), by donating some code.
• You can improve the over all product (which is just my weekend timepass) by giving out some ideas.

If I get positive response [1], I'd continue development on this, hoping to make it the most weird language ever to exist, with a good IDE (probably). Hope you respond...

Regards,
Shikhin

[1] Now, now, examples are: You are mentally unstable. You need medical attention. Go visit the hospital. Et cetera.

[Solar]

My response would be, don't try to improve the language. It's perfect as-is. Do you really want to bloat the language by 25% or more just to add file I/O?

[shikhin]

Hi,

Do you really want to bloat the language by 25% or more just to add file I/O?

Actually, I don't want to, thus I had thought of the following idea:

I'd introduce another keyword, which would most probably be ^ (or something similar). This would be 'read one byte from file' operator. For example, the steps I'd need to take to read one byte from file XYZ.ZYX would be:

• Prepare file name, such that the current 'index' points to a null terminated "XYZ.ZYX".
• Do a ^

That'd open file XYZ.ZYX, and read one byte at the current index. The only problem that I can think of the above is that it would destroy the filename.

But, well, I am biased to make the language a little more "useful" ( ), so I'd love if you review this, and say if it is "bloat-y" or not.

Regards,
Shikhin

[Solar]

Well, BF already allows reading from stdin and writing to stdout. Combined with pipes and output redirection, isn't that all the file I/O you need?

cat input.txt | my_bf_executable > output.txt

As for usefulness, I've used BF a couple of times as an introduction to elemental programming. No, seriously. At least for the first lesson.

You get to explain "memory as an array", pointers, the difference between incrementing a pointer and incrementing the value it's pointing to, and the equivalence of ASCII characters and certain numbers. You can also show the importance of breaking down a problem into individual steps. All that with a language you can explain with a single slide projected to the wall.

You also show that programming isn't all about being serious. And you get your audience craving for a higher-level language, so when I toss C++ at them the next lesson, they're actually thankful.

[shikhin]

Hi,

Well, BF already allows reading from stdin and writing to stdout. Combined with pipes and output redirection, isn't that all the file I/O you need?

Perhaps, perhaps not. But, I think I see the sense in your "bloating it 25% more" line. As for other interesting ideas, I just don't want the project to die out so soon.

As for usefulness, I've used BF a couple of times as an introduction to elemental programming. No, seriously. At least for the first lesson.

You get to explain "memory as an array", pointers, the difference between incrementing a pointer and incrementing the value it's pointing to, and the equivalence of ASCII characters and certain numbers. You can also show the importance of breaking down a problem into individual steps. All that with a language you can explain with a single slide projected to the wall.

You also show that programming isn't all about being serious. And you get your audience craving for a higher-level language, so when I toss C++ at them the next lesson, they're actually thankful.

/me suddenly starts hoping that Solar would introduce BFK in his next "first lesson".

Regards,
Shikhin

[davidv1992]

Your implementation does some very basic optimizations. You could try to implement more optimizations though. For example combinations like the following are often found in BF programs: [->>+>+<<<]. Optimizing these into moves can make quite a difference in performance. You could even try to start recognizing more complex patterns such as additions and maybe even multiplication.

[Solar]

/me suddenly starts hoping that Solar would introduce BFK in his next "first lesson".

I wouldn't actually go as far as writing or running BF in one of these intro lessons. Having people look at source at the whiteboard makes their eyes water already. Oh, another message that BF helps driving home: comment your source.

[shikhin]

Hi,

For example combinations like the following are often found in BF programs: [->>+>+<<<].

Please excuse my ignorance, but what would you optimize that to?

Optimizing these into moves can make quite a difference in performance. You could even try to start recognizing more complex patterns such as additions and maybe even multiplication.

That sounds like a reasonable idea, though I'd like to start with basic optimization (and understand what the above can be optimized to).

Oh, another message that BF helps driving home: comment your source.

Of course.

Regards,
Shikhin

[Solar]

[->>+>+<<<]

Please excuse my ignorance, but what would you optimize that to?

Copying the value of address 0 to address 1 and 2...!?!

[shikhin]

Copying the value of address 0 to address 1 and 2...!?!

Doh - /me bangs head. /me bangs head. /me bangs head.

I guess, back to optimizing.

Thanks for the ideas, everybody.

Regards,
Shikhin

[xenos]

[->>+>+<<<]

Please excuse my ignorance, but what would you optimize that to?

Copying the value of address 0 to address 1 and 2...!?!

Wait a second... Are you sure? o.O I just tried to understand this tiny bit of code and I think it rather does something like this (where d is the initial data pointer):

Code: Select all

d[2] += d[0];
d[3] += d[0];
d[0] = 0;

[shikhin]

Wait a second... Are you sure? o.O I just tried to understand this tiny bit of code and I think it rather does something like this (where d is the initial data pointer):

Code: Select all

d[2] += d[0];
d[3] += d[0];
d[0] = 0;

I think that's what he meant (as long as you assume d[2] and d[3] haven't been operated on), the thing becomes:

Code: Select all

d[2] = d[0];
d[3] = d[0];
d[0] = 0;

On another note: did you use my compiler to try that? </sarcasm>

Regards,
Shikhin

[davidv1992]

the most correct translation would be (assuming previous notational norm)

d[2] += d[0];
d[3] += d[0];
d[0] = 0;

Of course, in case the compiler can prove that d[2] and d[3] are zero upon entering this piece of code it can be simplified to the version with just assignments, giving the advantage of saving two reads from memory.

[xenos]

Thanks for the confirmation Actually I used the BF compiler that was shipped with my human brain operating system, it is written completely in BF

[shikhin]

Hi,

Of course, in case the compiler can prove that d[2] and d[3] are zero upon entering this piece of code it can be simplified to the version with just assignments, giving the advantage of saving two reads from memory.

Another "stupid" question on the way. The above sounds simple enough; but how do you determine which code piece can be optimized how? The human brain would probably be able to do it more easily. I am very inexperienced with compiler writing, and moreover compiler optimizations (which is one of the reasons I am writing this too).

The only way I can think of is to first take a paper and pen, and note down every method for which I'd be able to optimize. For example, for [->>+>+<<<] or the simple [->+<], I just detect that the programmer is trying to copy one value to x other positions (by seeing that with every loop, he increases a value "somewhere" and decreases the value at the current index). In the same way, I optimize for every method I note down. This is the only way I can think, but I don't think compiler optimizations work this way. I did some STFW'ing, but some just describe the theory (which doesn't work in this case), and some are too specific (for another language - don't have any hints I can pick up on).

I hope someone ignores my ignorance, and has the patience to explain to me, whatever is happening behind the scenes.

Regards,
Shikhin