Skip to content

Latest commit

 

History

History
54 lines (46 loc) · 4.65 KB

TODO.md

File metadata and controls

54 lines (46 loc) · 4.65 KB

#TODO

While the program is nowhere near complete, I will be trying to keep track of my todos through this file.

##General

  • Auto detect source language from the extant of the input
  • Concatination of source files (why you'd wanna do that in brainfuck, beats me, but it should be an option)
  • MAYBE: reading from stdin
  • MAYBE: reading the ! flag to start input to program

##Optimization Passes

  • Lazy Moves: Moves wouldn't be evaluated until they absolutly had to, all other operations would operate with an offset. e.g. ++++>>>+++>[-] would be ADD, ADD, MV, CLEAR
  • Dead Code Removal: Removes all dead loops, either because they would never be reached because it's inherant [...code...][this wouldn't run] (or a loop at the beginning of the program) or if the compiler already knows that it starts on a 0 due to Compile Time Evaluation.
  • Infinite Loop Removal: Any loop which doesn't effect the starting cell at all should be a compiler error for an infinite loop. Any loop which effects the starting cell by a even number will fail if the starting cell is an infinite loop. This should be an error at runtime, with a warning at compile time
  • Clear loops: [-], [+++], etc. They all automaticly clear the current cell, with the caviat of [--]. This (or any other loop with an even amount of minuses), if called on a cell with a odd value, would cause an infinite loop, and throw a runtime error. This should warn if compiled.
  • Multiplication loops: [->+++++>++<<] or [--->++++>++<<]. Translate to a multiplication with an optional devision. The amount of minuses on the starting cell is the divisor. If divisor is even, could cause infinite loop, see writeup on clear loops.
  • Compile Time Evaluation: A multi-pass optimzation that allows cells to be set at the beginning of a program, releaving stress on run-time. Time that is no longer spent setting things up. This is a multiple pass job, as the influence of any input has to be tracked across the data (and instruction) array. All instructions before an input can be evaluated without second thought. Loops that don't touch a input-influenced cell can be evaluated in full.
  • Threading: This is honestly the holy-grail of brainnfuck optimizations in terms of detectability, though I'm not sure how much benefit it would have. The ability to detect that two loops are completly independant, and evaluate them concurently. This will probably never happen ever.

##Front Ends These will be supported in both input and output. They are directly equivalent to brainf*ck These can be lexed with simple translators.

##Variations that need ast/optimizer support

  • Brainfork Needs support for forking (either simultaneously using multi-threading or sequentially with a stack).
  • Boolfuck Needs custom i/o and binary support
  • Derpcode Needs binary support
  • COW Needs a register/stack and additional control characters
  • DNA# Needs a second pointer
  • TinyBF Needs direction variable

##Target languages These are all of the languages that bfcc will compile to

  • C
  • Go
  • Java
  • Python
  • Support for most of the brainfuck variants above (no promises)