Umka for microcontrollers

[hiperiondev]

I'm doing a port of umka for the ESP32 microcontroller but I run into a problem. The compiler is too large (it cannot hold the compilation in memory) Is it possible to compile the program and only execute the result? Is it possible to "decouple" the compiler as optional? These two features are essential for a low-resource environment and that is why Wren is not useful in this type of application, unlike Lua.

[hiperiondev]

VM seem to be simple to decoupling with files: umka_common.c umka_common.h umka_ident.c umka_ident.h umka_lexer.h umka_types.c umka_types.h umka_vm.c umka_vm.h. Only needs to disable asm and a couple of functions that depend of lexer.

[vtereshkov]

@hiperiondev The Umka compiler/interpreter has never been targeted at such low-resource platforms. Even though it's a feasible task, additional efforts are needed to complete it.

• The VM is hard to decouple from the compiler because it relies on the type list referenced by Type *. This is needed by the RTTI for interfaces and many other things. In other words, a hypothetical bytecode file would have to also contain this type list in some serialized form.
• The bytecode itself is quite bloated. Each VM instruction currently occupies 48 bytes, which is too much. It can easily be reduced to, say, 16 bytes. But it again requires some care.
• If you only have 512 kbytes RAM, I cannot even guarantee that the compiler alone can run on this platform.

All in all, rewriting Umka for microcontrollers seems to be a good non-trivial project on its own.

[hiperiondev]

Thanks for the reply. Indeed the requirements are too big and it would be necessary to completely rewrite the code. Unfortunately it's not something I can do right now.

[skejeton]

P.S. this also related to libc-less umka, I think it's important for WASM targets especially

[vtereshkov]

@skejeton That's right. However, I already have one WASM target, the Umka playground.

[skejeton]

indeed, but this is an emscripten target, many WASM developers prefer to not use libc for the sake of not having to use emscripten. However there's MUSL libc that can be used with WASI (a Posix environment for WASM), but I think it's worth removing the use of libc functions one by one in favour of custom utility ones