BF interpreter (bad language warning)

[Tursi]

I don't remember if anyone already did this...

 

I wrote a Brainf**k interpreter for the TI... you can enter a program and see the output. Note I don't censor the word in the program.

 

bf.zip

 

This simple little interpreter for Brainf**k is meant to be run from Editor/Assembler.

 

You can find a doc at Wikipedia: https://en.wikipedia.org/wiki/Brainfuck

 

Brainf**k is a minimal language, hard to read, hard to code, and ... yeah, it's silly.

 

To copy the notes:

 

The brainf**k language uses a simple machine model consisting of the program and instruction pointer, as well as a one-dimensional array of at least 30,000 byte cells initialized to zero; a movable data pointer (initialized to point to the leftmost byte of the array); and two streams of bytes for input and output (most often connected to a keyboard and a monitor respectively, and using the ASCII character encoding).

 

>    increment the data pointer (to point to the next cell to the right).
<    decrement the data pointer (to point to the next cell to the left).
+    increment (increase by one) the byte at the data pointer.
-    decrement (decrease by one) the byte at the data pointer.
.    output the byte at the data pointer.
,    accept one byte of input, storing its value in the byte at the data pointer.
[    if the byte at the data pointer is zero, then instead of moving the instruction pointer forward to the next command, jump it forward to the command after the matching ] command.
]    if the byte at the data pointer is nonzero, then instead of moving the instruction pointer forward to the next command, jump it back to the command after the matching [ command.

 

Start the program from Editor/Assembler option 3 (it's not configured to start properly from #5 or cart).

 

DSK1.BF_OBJ

 

Press enter, and enter the program name "START"

 

The program will launch, and display the built-in sample program, which prints the title information.

 

 

When it finishes, it will display "** DONE ** REDO, CLEAR OR QUIT"

 

Press REDO (Fctn-8) and the program will run again.
Press CLEAR (Fctn-4) and the program will be cleared, and enter input mode.
Press QUIT (Fctn-=) to reset the computer, as normal.

 

In input mode, you can enter a program (type or paste in Classic99). If the program is larger than the screen, it will still be entered but it will not be displayed and you can not retrieve the non-visible part. It's expected you usually are pasting in a program.

 

When you press ENTER, the program will execute.

 

Only three lines are preserved for the output. You can output more characters, but they will be overwritten by the ** DONE ** message. The character >0A (ascii 10) is a carriage return/line feed. If you run off the bottom of the screen, you will corrupt the system, starting with the color table. Extremely clever people might take advantage of that... (extremely BORED clever people...)... but I think it should be possible to generate static pictures with color, if you can fit the generator in 6k.

 

There is no editor! If you want to export the sample program, you can use the Classic99 feature Edit->Copy Screen to copy the text out, or copy it out of the source code.

 

Advanced information:

 

The screen outputs starting at >0000 in VDP RAM, and is not range tested. The sprite attribute table is at >0300, the color table is at >0380, and the pattern descriptor table is at >0800. Yes, you can write to these if you run off the end of the screen... however, interrupts are not enabled so sprite automotion is not possible. It's not possible to move the VDP pointer backwards, either, nor will wraparound work well because eventually you wil hit the VDP registers.

 

The BF program is stored starting at >2080, and has 6784 bytes until the interpreter code starts at >3B00.

The data array starts at >A000 and has 24k available - slightly less than the usual 30,000 bytes.

 

This is useful for debug - you can use the Classic99 debugger to look at the data array during and after execution.

 

I didn't write the sample program, I used a converter here: https://kleshni.github.io/Brainfuck-converter/

 

[Tursi]

Ah ha, @Willsy did it in Forth back in 2014, hehe...

 

 

[+Vorticon]

You got my curiosity piked. I'm going to implement a version in pcode just because... I am absolutely certain that I have far more important things to do, but what the hell... 

[+TheBF]

4 hours ago, Tursi said:

Ah ha, @Willsy did it in Forth back in 2014, hehe...

 

 

This totally blew my mind when I saw it.

 

Here it is slightly modified to run on ANS/ISO Forth systems just in case anyone wants to use it on GNU Forth. :-)))

\ brainfuk.f in ANS Forth based on work by Mark Wills
\ Thanks to Willsy on Atariage.com who wrote this in TurboForth
\  A M A Z I N G  !!!!!!!!!!!

HEX
CREATE MEMORY   2000 ALLOT
VARIABLE ^P   \ the memory pointer

: RESET ( -- ) MEMORY DUP 2000 0 FILL  ^P ! ;
: PEEK  ( -- ) ^P @ C@ ;
: POKE  ( -- ) ^P @ C! ;
: >     ( -- )  1 ^P +! ;    
: <     ( -- ) -1 ^P +! ; 
: +     ( -- ) PEEK 1+ POKE ;  
: -     ( -- ) PEEK 1- POKE ;  
: .     ( -- ) PEEK EMIT ; 
: ,     ( -- ) PAD DUP 3 ACCEPT  EVALUATE POKE ;

\ jump forward past the matching ] if the byte at the ^P is zero
: [     ( -- ) POSTPONE BEGIN  POSTPONE PEEK  POSTPONE WHILE ; IMMEDIATE

\ jump backward to the matching [ unless the byte at the ^P is zero
: ]     ( -- ) POSTPONE REPEAT ; IMMEDIATE

: RUN ( hello world in BrainF__k )
    RESET
    + + + + + + + + [ > + + + + [ > + + > + + + > + + + > + < < < < - ] > +
    > + > - > > + [ < ] < - ] > > . > - - - . + + + + + + + . . + + + . > >
    . < - . < . + + + . - - - - - - . - - - - - - - - . > > + . > + + . ;

 

[Willsy]

2014... Man how time flies!?

[+OLD CS1]

1 hour ago, Willsy said:

2014... Man how time flies!?

Time is the ultimate brainfuck.

 

(you were warned by the topic title.)

[Willsy]

That was a nice trip down memory lane!

 

<brag>

It turns out I did an *optimising* BF compiler!

http://turboforth.net/fun/brainfuck.html

</brag>

 

'yall got some work to do!?

[Tursi]

Everyone who does it calls it an optimizing compiler, and I guess it is, but given the advantages every other language on the planet has over BF (you know, like integers ), optimizing compilation to another language is just "ok". 

 

I spent a significant amount of time looking for an actual BF optimizer - that is, BF in, optimized BF out - and found nothing. It must be possible to condense long sequences into shorter ones, or look for generation patterns that can be made shorter... but I admit off the top of my head how baffles me just a bit.

 

The best thing I could come up with is many programs probably have opportunity for constant folding and loop optimization. Long sequences that generate a fixed set of output values might be improved if we could determine a shorter way to generate that same sequence. Loops might be made faster, if not shorter, by unrolling a bit (for instance, counting down, [-] is conceivably slower than [--], if you can guarantee the count is an even number). 

 

I don't know the language well enough to know how many opportunities are out there, and nearly all hits for optimizing BF are about translating it to other languages.