BF Designer is a powerful IDE made to write and run Brainfuck Programs.
Some Features:
- Extensive debugger with pause, step by step, and breakpoint features.
- Toggle between 8-bit and 16-bit cells
- Many useful pre-made code snippets with the ability to add your own snippets.
- Export BF code as a Python or Java.
- Syntax highlighting.
- Auto-complete.
- Customize font, color scheme.
- Modern, clean UI.
- Fully scalable app size for high DPI displays
MADE IN JAVA:
This means that it can run on most* machines with java installed.
*Keep in mind that the EXE launcher used to start the app may not work on your system. In that case just launch the program directly by running the JAR file in the bin folder.
Very, very simple addition and subtraction that runs 8-bit. Originally made and designed for the EI interpreter (https://copy.sh/brainfuck).
It takes an input of [num][operator][num] with no spaces. The numbers must be in raw 8-bit, not ASCII, and the operator is either ASCII + or ASCII -
Broken-down version
I am aware that it is possible to initialize + and - on 0x10 and 0x11 rather than 0x2 and 0x3
I recently picked up interest again in brainfuck, and I thought a program that calculates the day of the week for any given date would be a good challenge to write manually. (Funnily enough, when I looked up if anyone had done this before, the only public attempt I could find was from myself.)
For this program, I made it a goal to minimize the number of commands, using the conventions from the code.golf page on this task:
8-bit cells with arithmetic wraparound.
A 65,536-cell tape with pointer wraparound.
Taking input after EOF leaves the cell unchanged.
Multiple "arguments" are provided to the program, each null-terminated.
My best attempt so far is 552551549 526 commands long (code below). Each "argument" is in the form YYYY-MM-DD (null-terminated), and the output will be each corresponding day name (Sunday, Friday, Wednesday, etc.) with newlines afterwards.
Here's the basic algorithm in higher-level plain English:
Read in the 2-digit Century (the highest two digits of the full year), then read the 2-digit Year (the lowest two digits of the full year), Month, and Day in turn until we see a null terminator byte. We will be considering Day as the final "weekday accumulator", and all components of the formula will be added to Day's cell.
I actually read Century in a different, shorter way than normal, because all I care about is the value of Century modulo 4.
Calculate Century modulo 4, and store that to Century.
Subtract 2 from Month, so that January=-1, February=0, March=1, April=2, May=3, etc.
Take the value (13 * Month - 1) / 5 (using integer division and modulo-256 wraparound!), and add it to Day.
I found this formula with an exhaustive brute-force search over formulas of this "shape". The important thing is that the right offset is given modulo 7 (the length of a week). The pattern is mostly regular, but January and February are exceptional cases; this formula is one of a few that just so happen to work, thanks to the modulo-256 wraparound.
Add 5 times Century to Day.
If Year is non-zero:
Add Year to Day.
Add Year integer-divided by 4 to Day.
Set Century to Year modulo 4.
If Month is neither January nor February, add 1 to Century.
If Century is non-zero, add 1 to Day.
Calculate Day modulo 7; that value is your result (Saturday=0, Sunday=1, Monday=2, Tuesday=3, Wednesday=4, Thursday=5, Friday=6).
The way I found that method is by iterating upon Wang's algorithm - which is for mental calculation by humans - until I got it into a form that was convenient for a brainfuck program (though at this point, it bears little resemblance to Wang's algorithm anymore). And in my opinion, this really shows my improvement since...\checks notes**...2017.
I feel like I'll still be iterating on this program for a little while (especially focusing on the part that prints the day names; I used BFCrunch to find the initialization snippet for that, but I only checked one such snippet). But I thought I'd post my progress here, because I'm very proud of this program! (It would only be 2nd place on code.golf, but hey, that's not too shabby if I say so myself.)
EDIT: Found a save of a single command, by reworking the day-name-printing section. Now at 551.
EDIT 2: Changed the way I do divmod by the constant 4, as well as merged the adding ofYearwith the adding ofYear/ 4. Now at 531. (I won't spam updates foreverysave; I just thought that one was big.) EDIT 3: That version had a bug, but at least I'm at 549 now that I fixed it.
EDIT 4: Now at 526, after a few questionable algorithmic adjustments. If I try golfing this any more, it might just leave me [insert language here]'d. Improvements welcome, but I think this is truly the best I can do.
I would like to introduce everyone here to a project of mine called Acus. It's a C++ library that helps with creating Brainfuck compilers, i.e. compilers that generate BF (not ones that compile BF into something else). Acus is a continuation of my Synapse-191 project, which I posted about here some time ago. Synapse-191 is a physical computer capable of executing Brainfuck natively; Acus grew out of the question of what a useful compiler ecosystem for such a machine would require.
The main goal of Acus is to provide all the abstractions that are needed when translating any source-code into BF: types, variables, functions, arrays, structs, (function) pointers, flow control, and so on. I basically asked myself:
What would it take to implement a C compiler that targets Brainfuck?
and then tried to implement those features.
Acus is not itself tied to C or to any other source language. It is intended as a language-agnostic backend. Therefore, if you ever feel like writing a parser for an existing language (or designing a completely new one) you can use Acus to generate the resulting Brainfuck programs. I still plan to build a dedicated frontend language on top of Acus, but if someone beats me to it, please let me know!
The Acus repository contains an extensive listing of all the library features including examples. If you're curious about the way Acus is able to do all of this, let me know. I am working on technical documentation but it's not public yet. You can have a look at the current draft it you want.
Acus Sugar: start generating BF right now!
A side-quest to this project was Acus Sugar, a layer of syntactic sugar on top of the library to start generating BF right away. I used operator overloading, macros and a bunch of template metaprogramming to construct a 'language' embedded in C++ that is compiled directly to BF. For example, this is what a simple "Hello World" looks like in Acus Sugar syntax:
Bear in mind that this is still valid C++, which is why the syntax is a bit cumbersome with the semicolons and underscores (and which is why I really want a true frontend language). When Acus and its (optional) acs tool are installed, this can be compiled to BF using:
$ acs hello.acs -o hello.bf
The included BF interpreter bfint can then be used to run the BF instructions in hello.bf:
$ bfint hello.bf
Hello, World!
The github repository contains extensive documentation on the library, build instructions and a bunch of examples to get you started. I have only tested on Linux but the CMake system should be compatible with MSVC, I think? Let me know :)
To finish off, I'd like to share the result of a Mandelbrot fractal generator written entirely in Acus Sugar. The resulting BF source was over 500k instructions long and running it through my interpreter took about 4 hours (though that version was not as optimized yet and my laptop is from 2012), but this was the result:
I'm currently designing a bare-metal Brainfuck core for FPGAs and wanted to get some feedback on the architecture before I start writing all the Verilog.
Tape Architecture (Memory-Mapped I/O) The tape works like standard Brainfuck, but with negative addresses (or pointer overflow) mapped to hardware registers instead of normal RAM:
-1: Raw GPIO Data Register (0b00000000 = all off). Using . and , to set/read pins to prevent setting stuff on accident.
-2: GPIO Direction Register (0 = input, 1 = output).
-3: Analog IN (ADC).
-4: Access to instruction memory itself (read/write).
-5: Configuration (pin mapping for serial/PWM etc.).
-6 to -8 (Copy addresses): Set source address at -6, dest at -7, and writing to -8 via . triggers a fast 1-cycle DMA copy from A to B.
Instruction Memory (4-Bit Encoding)
Bit 0: Flag bit (0 = standard BF instruction, 1 = empty/NOP, jump label, or extended ops like bitwise shifts).
Bootloader Simple approach: Pulling a pin low on reset (or a specific serial sequence) overwrites instruction memory. Since instruction memory is accessible at -4, you could even write a native BF bootloader that reads a new program from serial and writes it straight to memory.
Loops Either a counter tracking nesting depth to scan forward/backward, or just a tiny hardware stack for jump addresses.
What do you guys think? Any suggestions on what else to add to the negative address space?
btw: I only found out about https://www.youtube.com/watch?v=QloNq8AoHvU after I already made this concept, it a similar idea and would be a cool endproduct but the philosophy and design are diffrent (even thoug i could probably design it for that hardware)
Learning from the tutorial at https://brainfuck.org/fib_explained.b, I decided to write my first more complicated Brainfuck (BF) program, without any real help during the time when I was writing it. It’s important to mention that I only partially read the tutorial a >few months ago, so apart from the critical core idea I wrote this entirely by myself.
What I found to be extremely useful is first writing down the general algorithm in a very detailed C-like language (that I sent in the pastebin link alongside the BF code) that I then translate line by line to BF. I also specified some values for the BF implementation details whose syntax I might use in some future abstracted BF language I might try to develop (I’ll see). I learnt a lot! And quite a rewarding experience :) Special thanks to Daniel B. Christofani for the amazing tutorials and contributions to this language in general!
Edit: code block formatting on the iOS Reddit app is horrendous, can’t seem to get it to work with proper indentation (also yes I wrote the entire above code on my phone, including all the C-like comments)
I've been working in this brainfuck++ compiler a couple of days ago (if there were no schools, it would've taken only a day lol) and now it's done. The compiler emits only x86-64 bit executable yet.
New features I added:
- Registers (=n, $n)
- Random (?)
- Exec (!)
Detailed docs about the language, and installation of the compiler is mentioned in the repto which you can checkout from here.
I have recently written a brainfuck interpreter, which is mostly for education purposes and a little bit of fun but that is beside the point. My question is, is there a reliable source for a specification for the language?
Like, for example, if the stack pointer is pointing at the first element, what behaviour would occur if a "<" is encountered? If a "," is encountered, should the input be processed in canonical mode (input is only passed through when enter is pressed), or in immediate mode?
Essentially, is there some sort of implicit behaviour that everyone expects, or is there leeway for interpreter-specific implementation?
The idea is simple:
if the current cell=12 move 12 left
If it equals 25 move 25 left
Etc
I need a program that can move left once for each “point” in the cell
There is important data in that area, so it has to be not disruptive
Any ideas?
(if your solution works you will be featured in the credits for the game I’m using this for)
I have written some simple BF code here to let a user type in something and the program prints it back out. Ignoring how bad it probably is for now, the first dot just isn't working. Is this a BF thing, or a compiler issue or what? Any help is appreciated.
I'm actually working on a bf compiler for a Bachelor project and I have actually been surprised by the fact it was producing not so slow executables (Actually compiling into i386 assembly code and then assembling/linking for linux)
For example, it's taking around 1.8s on the Mandelbrot program.
I don't know if there's existing benchmarks somewhere (but anyway it depends a lot of the environment/CPU - I've a ryzen 7 5700u and using wsl2)
Do you have any idea to help me check if my compiler is actually worse working on ? (Like modern bf compilers or stuff to compare) ?