OSDev.org

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/

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.

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

PatrickV wrote: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

Troy Martin wrote: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.

JamesM wrote:

Troy Martin wrote: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!

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:
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: 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.

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

Masterkiller wrote: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.

NickJohnson wrote:

Masterkiller wrote: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: 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: 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: 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.

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

@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.

NickJohnson wrote:@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.

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

fronty wrote:

NickJohnson wrote:@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.