This will hopefully help with others making programming languages and serve as some kind of documentation. Though Flpc was designed to be relatively easy to change, there is a surprising amount that stayed unchanged since the start of this project, perhaps unfortunately. I'm sure some of this post will still become outdatated and the intended final format is an interactive tutorial to teach you how to recreate Flpc so different design decisions can be made (similar to How to make these slides) but we're still very far from that.

I've recently ported Flpc's C source to Nim, which now runs faster than C (when all Nim/underlying C compiler optimization flags are turned on) thanks to folks from the Nim forum.

In this post, I want to describe an instruction level variant of this.

I think the best way to describe instruction level just-in-time programming (IL-JIT programming) is by showing how it works. I'll start with the classic Fibonacci example (Rosetta code has many implementations). We'll implement Fibonacci while evaluating fib(3).

The most common FFIs are C FFIs where the target language is C.

I just pushed a new version of Flpc where I added a very limited FFI for calling Python. Highlights of some other changes are:

They helped make dictionaries [names] which can

An example of a dictionary:

So instead of

$ python compiler.py file1.flpc file2.flpc file3.flpc > output.f

you can now run

$ ./flpc precompiled/compiler.f
> push: output.f init_g
> push: file1.flpc compile_file
> push: file2.flpc compile_file
> push: file3.flpc compile_file

To automate a program, it makes use of screenshots and image recognition to decide where to click and type [automation_methods]. As you can see above, Sikuli uses Python for its script's language (plus rendered image). But under the hood, its implemented in Java and runs Jython. Since nothing Sikuli uses really needs Java, we'll try to implement some GUI automation in pure Python.

and then program Tetris for your computer. Nand game cover the first 3 projects of the course using a nice drag-and-drop interface

Nand game includes a number of (in my opinion) improvements to the presentation. I feel it really lets me get to the crux of the matter quickly.

This post contains solutions to Nand game and therefore Nand to Tetris. Try them first if you haven't already.

One thing I wish I could do in Nand game is to experiment with the CPU designs (rather than just implement an existing design). I quite like their interface but am much quicker (and used to) a text interface.

In part 1, we got the assembly parts: read/write registers and memory, single step, single instruction execution, function calls (although not perfect), set/restore breakpoints, memory allocation and examining upcoming instructions.

In part 2, we got the C parts: read/write variables using ptrace and memory maps, a C read-eval-print loop (REPL), line numbers from DWARF headers and undo using fork().

Its now time to actually use our debugger/editor! We'll try to use it to write a C program.

We got all the assembly parts: read/write registers and memory, single step, single instruction execution, function calls (although not perfect), set/restore breakpoints, memory allocation and examining upcoming instructions.

This post will try to do similar things in the C portion. Next time, we'll try using it to make something.

Being able to recreate flpc in a more interactive ways is one of these times. In this post, I try to make a debugger from more primitive pieces: the ptrace system call wrapped by the python-ptrace library, pyelftools and later on, the disassembly library distorm3.

Because those debuggers are very large projects, trying to remake them seem daunting. But since I mostly want to debug and live-edit a binary I've created, I don't need maximum compatibility. Simplicity will be favoured over completeness when it seems like a good trade. Hopefully, this post itself exposes enough of the underlying ideas to bridge the gap in case of a slightly different environment and standard.

Display a sequence of images fast enough and the eye perceives motion. In this post, I want to look at possible architectures and APIs for an animations library (to potentially be used with Make these slides or plain guitktk).

Basically, the idea is to coordinate with a group where each person makes one program and when we are all done, the union contains many programs that each person wants.

When writing Flpc in C, I found it a difficult to transition. In this post, I describe how to use gdb to get a similar workflow.

nasm -f elf64 forth.asm -o forth.o ;and ld forth.o ;and ./a.out < test2.f

inside forth22.

Which came first? The chicken or the egg?

This post discusses bootstrapping: the first step when trying to make something new. Bootstrapping is needed in many places.