From Scratch Interpreter (FSI)

Introduced a new special instruciton called expose-function. If a function is exposed, translator adds information about its signature to the binary representation for the execution engine to take advantage of. You can't start a program without exposing your main function, for example.

Introduced a simple compression sequence for binary format which combines two algorithms. Sequence reduction, it is kind of similar to LZ77 because it uses circular buffer and replaces occurences of data that are already there with references to parts in said buffer. Static huffman, which requires me to store a frequency table at the start of the file.

Refactoring and a few bug fixes: disallow declaring functions with the same name, write 0 to bytes read from stdio if PRTS is not attached to it, properly handle undefined jump points in programs.

Fixed a few memory leaks in an execution module; slightly tweaked stdio processing logic so that it now relies on buffer sizes, not just newline characters. The output in the video may look kind of garbled because stdout gets mixed with stderr (which the execution engine uses to write its runtime logs) in a single console window.

The entire IO implementation is isolated in a single CPP file inside PRTS. That file is 1200 lines long. It would be nice to partition it. However, I don't think that this is possible or necessary: the implementation has rather complicated synchronization logic as is, trying to separate it into several files will make it even harder to understand what is going on. I tested both console input and output. I also tested file output. Next I'll have to ensure that file and pipe input work, along with pipe output.

Implemented IO workers and startup, shutdown sequences for them. Now I'll have to implement proper interface, so that programs will be able to interact with them.

Implemented a significant portion of the standard input output support for Program RunTime Services (PRTS). If I will succeed in making this work properly, then I would be able to use the execution engine with frontend applications that will redirect its (engine's) streams to provide different ways of interaction (CLI or GUI, for example).

Obviously I rely heavily on WinAPI to implement this, and the way it works is rather ridiculous: I must differentiate between console-like devices, files, pipes. So the code is complicated. I am not sure whether it'll work.

Introduced a Visual Leak Detector for Debug builds. Also added a new example: thread-groups-explosion which is just a stress test for the execution environment.

When I began this project I didn't really care about the quality: I just wanted to make it work. Now that it works it's time to collect some dividends from my technical debt.

Now program loader will provide more information about loaded programs. This includes: full program file name when compilation fails or succeds, general information (functions count, string count, etc.) about successfully loaded programs. Previously, it would just fail without specifying the name of the program that failed compilation.

Another thing is that program loader will finally provide information about instruction that failed compilation, as well as function name (if available).

I have started working on this way before the start of the summer, so this project can already do quite a lot. There is no way I'd be able to fully describe all of it here. Mostly, the reason why I am working on it is because this is my biggest project, so I must apply all of my knowledge about version control, refactoring, debugging, etc.