| Age | Commit message (Collapse) | Author |
|---|
|
The names stand for Oreo's Brainfuck Interpreter and Oreo's Brainfuck
Compiler, separate tasks that shouldn't be packaged in one executable.
|
|
Provides:
+ Transpilation from brainfuck code into intel style assembly
+ functions to assemble and link code
|
|
No need to interpret "multiple files in sequence". Just execute the
one file given.
|
|
|
|
|
|
RELEASE and DEBUG builds have differing build flags, triggered by
setting RELEASE variable. No longer doing object based compilation
because:
+ gcc is fast enough without it
+ stale code compilation bugs are annoying
+ having one output binary to clean-up is just easier when switching
build-types
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Flag which provides some helpful messages for debugging.
|
|
Really easy implementation considering opcodes are super simple. I
was right to implement the loop_ref system so at parse time we have
resolved references and don't need to do it at runtime (helps with
compilation I guess as well).
|
|
Same principle as main->lib (previous commit).
|
|
lib.(h|c) basically has structures and functions I no longer want to
stare at in main.c
|
|
Now you can use command line arguments to list a set of input files
for the interpreter to use.
Currently outputs the data parsed per file.
|
|
Apparently you can't just `fseek` because it's "not portable" and
"deeply offensive" or whatever, so here's a really dirty chunk based
allocator which uses `fread` to just read chunks of data at a time and
basically runs around this issue.
While it's slower than an fseek solution for general files, this
solution allows pipes and other _weird_ things that count as "files"
to just werk.
|
|
Using a buffer structure allows me to pass more information to
callers and a bit more discretion over how data is passed.
Better error reporting via having a file handle and reporting it
Emacs/GCC style.
|
|
Simple parser, took like an hour.
Not very smart but at least it's like O(n).
|
