Tiny on microcontrollers - separate VM from compiler

[hiperiondev]

I came across this project and found it very interesting. In particular, I focus on developments in microcontrollers and Tiny is a good "glue" language for these jobs. I have changed the code a little to separate the VM from the compiler (not necessary on a microcontroller where 200k of RAM is a luxury!). Now need separate compiler state from VM state... work in progress I have also made some aesthetic and "standard" changes such as using the _t suffix for the typedefs. In a few days I am going to create a project for ESP32 and see its application in more depth.

The project is at: https://github.com/hiperiondev/tiny-lang

[hiperiondev]

Now decoupled compiler state. I think it's not a good work but works

[hiperiondev]

I see there have been some changes recently. Do you plan to separate the VM from the compiler?

[hiperiondev]

Now is complete separated VM from Compiler in my project. Next I'll add the last changes in the original project

[goodpaul6]

@hiperiondev I can look into separating the VM from the compiler as long as we can keep the ergonomics of the binding API. I'd probably offer a single function that dumps the Tiny_State to a buffer and then another function that allows you to load it up from a buffer as well.

I'd be happy to look at your diff if you open a PR. Did you end up with a similar approach?

[hiperiondev]

I don't think a diff can be followed very much because I have made several changes to the ordering of the code (but without modifying its operation at all). I basically isolate the VM and separate the functions that operate directly on it. If you look at my repo you will see that I moved many functions to be able to compile and make the VM work independently, without needing the compiler. I also separated the state from the code generated by the compiler (for now I keep a certain reference but it should disappear. For this I should modify the compiler functions and transport both states separately) In this way it is now possible to directly dump the generated code and recover it without having to compile the complete environment.

[goodpaul6]

@hiperiondev I'll probably implement this by allowing you to dump/load the state (as I stated earlier) + a compilation flag which removes the compiler and it's functions.

You'll still have to re-bind all the foreign functions before executing but it can report an error if you start a thread with any functions unbound.

Should accomplish what your fork does but avoids changing the API/code structure too drastically.

My reasoning is that eventually I want to offer a machine-amalgamated single-header library version of Tiny and I want it to have a small API surface area.

Let me know if that could work for you.

[hiperiondev]

Maybe, but I think we see things from two different positions. I have a lot of experience in embedded systems on very diverse microcontrollers and their architectures and resources vary greatly. It not only happens with memory shortages but also with how the instructions are resolved. For example, on a PC, using a computed goto is usually not very efficient because it breaks the jump prediction, but on many microcontrollers it greatly optimizes the speed of the code. Also it is not a good idea to add the compiler in the application when it only has 100Kb or less of RAM in total. That is why the VM must be able to be optimized independently of the compiler and must be separate projects.

[goodpaul6]

@hiperiondev I think we're on the same page here. With the ifdef in place none of the compiler code should be compiled into the library so you should still get a very small executable, but it also avoids bifurcating Tiny into two separate libraries/codebases (vm/compiler).

[hiperiondev]

Well, it doesn't seem like an important topic to discuss right now and it's fine for me to add compilation conditions. If you agree, I could reorder the code (just reorder, not modify its functionality) to make it easier to choose the compilation blocks.

[hiperiondev]

I have pushed the modifications. In this way the compiler is optional. It is not possible to remove header entries until the structs are decoupled from the compiler and the VM.

[hiperiondev]

Some notice about pull request?

[goodpaul6]

@hiperiondev I think it's pretty much good to go from my perspective except perhaps adding tests for the standalone VM functionality

[hiperiondev]

After much thought I completely rebuilt the VM, taking into account the requirements of use in microcontrollers. I also added a complete assembler with directives and a disassembler. Also added a simple and fast heap and the creation of per frame elements, which are automatically removed with the frame. Global variables and arrays are also created in the heap The new VM is this: https://github.com/hiperiondev/stack_vm/

I will try to adapt the compiler to the new VM.