Got egnufeB?
News News
Befunge Befunge
   - Programs
   - Compilers
   - Interpreters
   - Documentation

Doom Doom
Inform Inform
Quake Quake
Misc Misc
Links Links
Contact Contact

Befunge-in-befunge interpreters

This is a set of Befunge-93 interpreters, written in Befunge-93. They work via use of self-modifying code: Any instructions which can be directly executed by the interpreter will be copied into the interpreter's memory and executed.

jbefbef.bf (1,082 bytes)

My first attempt at such an interpreter. Not very complete; I can't remember how much it can do, but it probably doesn't feature any stringmode support or protection against spurious memory reads/writes. Complete with address lookup ruler thing and miscellaneous bits of code at the end of the file :p
May require signed cells to work properly.

jbefbef2.bf (1,126 bytes)

A slightly modified version of the above. Don't ask me what's different though ;-)

jbefbef3.bf (1,121 bytes)

Stringmode support! However I think it's still lacking memory protection, and runs a at a snails pace compared to the 80x6 (480 cell) JIT interpreter by mtve. Also needs signed cells to work properly.

jbefbef32.bf (885 bytes)

jbefbef3.bf, but with one of my troll programs loaded. Should finish copying itself by eternity.

jbefbef4.bf (828 bytes)

jbefbef3.bf, but without the need for signed data cells. I've also managed to free up a few cells at the bottom, which suggests that it may be possible to make an even smaller interpreter. The loaded program is troll7.

jbefbef5.bf (737 bytes)

Yet Another Interpreter (TM). Hopefully this one is free of bugs and will actually work correctly on a strict Befunge-93 interpreter. It's also a lot smaller than jbefbef4, weighing in at a mere 15x25 (375) cells, meaning you can fit five interpreters and a small (5x25) program into one fungespace. You can modify the "A" variable at the top-right of the interpreter to change the width of the space it interprets (A=64, 64+15=79). The get/put protection used protects the interpreted program from reading the interpreter; -15<x<0 addresses are left as they are instead of having the intepreter width (15) added to them, thus deferring the out-of-bounds activity to the parent interpeter. Unlike some of my previous interpreters, the IP wrapping should now work correctly (honest!). The only bug I can think of is that unimplemented instructions will cause an infinite loop.

Page last modified 03/03/2005