Creating a OS in BrainFuck

[astei]

I'm going this as a experiment.

The OS will be written partially in C.

I'm aiming for 64-bit support, but I'm starting with 32-bit support for now.

http://code.google.com/p/brainfuckos/

[Troy Martin]

So how do you execute I/O? Run assembly language statements? Interface with the C parts?

BF is a little limited, but I'm interested in how one could use it for an OS.

[PatrickV]

On fringe(Tv Program)i saw an episode of a computer program thats melts peoples brains. But anyway that name for your operating system seems inapropiate

[neon]

But anyway that name for your operating system seems inapropiate

Considering the language that he is wanting to use, not really.

I personally think anything with that language is a waste of time. Of course, I have to assume that this is just for fun, so good luck with it

[JamesM]

So how do you execute I/O? Run assembly language statements? Interface with the C parts?

BF is a little limited, but I'm interested in how one could use it for an OS.

It's turing complete.

[stephenj]

So how do you execute I/O? Run assembly language statements? Interface with the C parts?

BF is a little limited, but I'm interested in how one could use it for an OS.

It's turing complete.

And a Turing Tarpit

Writing an OS in BF, I wish I had that kind of time on my hands!

[Troy Martin]

Okay, I think I got how this could be done.

The low level part of the kernel itself is best written in something like assembly and/or C, with a built-in custom BF interpreter (written in the same language as the kernel) on top. Writing a BrainFuck interpreter isn't that hard, it's just eight byte-long instructions in a row. Whitespace is ignored, as well as, as far as I know, other non-instructional characters. You could also write a "comment" extension.

As most of you interested in this topic know, the BrainFuck base language has eight instructions:

Code: Select all

Command 	Description
----------------------
>          Move the pointer to the right
<          Move the pointer to the left
+          Increment the memory cell under the pointer
-          Decrement the memory cell under the pointer
.          Output the character signified by the cell at the pointer
,          Input a character and store it in the cell at the pointer
[          Jump past the matching ] if the cell under the pointer is 0
]          Jump back to the matching [ if the cell under the pointer is nonzero 

There's also a few interesting extensions, including the # and ! instructions and BrainFuck++, which adds file I/O and, apparently, networking support. More "extensions" and related languages can be found here.

I propose the following two additions for OS development:

Code: Select all

Command 	Description
----------------------
%          Reads the memory cell under the pointer as an I/O port number for an IN instruction, storing the inputted byte at *(p+1)
@          Reads the memory cell under the pointer as an I/O port number for an OUT instruction, outputting the byte at *(p+1)

A limitation I find with BrainFuck is the inability to nest [ ] sequences. However, this is likely an easy thing to implement (nested stack work is all. This is best done in assembly language.)

Okay, I think I'm going to try writing a BrainFuck OS now.

[Masterkiller]

I think it'll be good idea next 512-byte OS competition to be a brainfuck 512-byte OS competition.

[NickJohnson]

I think it'll be good idea next 512-byte OS competition to be a brainfuck 512-byte OS competition.

Only if you compressed it - 512 bytes means 512 BF instructions, and even very simple functions are hundreds of them. With a simple range encoder, you could pack it at least 3-fold, judging by the number of symbols used.

[Troy Martin]

I think it'll be good idea next 512-byte OS competition to be a brainfuck 512-byte OS competition.

Only if you compressed it - 512 bytes means 512 BF instructions, and even very simple functions are hundreds of them. With a simple range encoder, you could pack it at least 3-fold, judging by the number of symbols used.

I agree. The smallest (functional) program I can think of is the following:

Code: Select all

,[.,]

Five bytes. It takes whatever key you press and prints it to the screen. No more, no less.

Now, that doesn't do anything useful. Let's do a bit of thinking here. Here's a basic puts() routine:

Code: Select all

[.>]

Now, all that does is prints characters starting at the data pointer before the [.>] block and stops when it hits a zero. If you want to print a newline like the libc puts() does, that's just as easy:

Code: Select all

[.>][-]++++++++++.[-]

Now, let's break it down: [.>] prints the string. [-] clears whatever's in the current byte at the data pointer. The ten pluses and the dot increments that byte to 0Ah (newline), followed by printing it. The final [-] clears it again, restoring it to zero. Technically, as the data pointer is on the null after the string, the first [-] isn't really necessary, but it's a good touch. The final [-], however, is necessary to prevent the computer from asploding if the string is printed again and there's no null at the end, printing theoretically endless amounts of garbage.

Now I don't know about you, but I think that looks pretty damn confusing just for a freaking puts() function.

Now think about implementing "if": there's going to be a lot of decrementing and weird nested [] blocks in that.

Your small little OS is going to become a big beehawtch after a while. Debugging will be worse than hell.

[fronty]

What about translating brainfuck into assembly? At least the result would be smaller and it would be easier to debug.

[NickJohnson]

@fronty: That would kind of defeat the purpose, wouldn't it?

How about instead of a kernel for BF, a kernel for a universal Turing machine emulator? That's even harder, because it's neither procedural nor functional. It would be dead slow, even compared to BF, but IMO would be much cooler.

[fronty]

@fronty: That would kind of defeat the purpose, wouldn't it?

I thought the goal was operating system partially written in brainfuck, not a kernel which includes a brainfuck interpreter and some parts of kernel running on top of it.

[Troy Martin]

I'm almost done writing a small Brainfuck interpreter in assembly.. The only problem is it's quite jumpy. I tried the ,[.,] program and it started printing out pieces of the assembly language code

[NickJohnson]

@fronty: That would kind of defeat the purpose, wouldn't it?

I thought the goal was operating system partially written in brainfuck, not a kernel which includes a brainfuck interpreter and some parts of kernel running on top of it.

Sorry, I thought you meant that he should translate the BF to assembly initially, then fix/debug the program by modifying the assembly.