minivm VS android-luajit-launcher

> I developed a unique way to write interpreters based on threaded code jumps and basic block versioning when I made MiniVM (https://github.com/FastVM/minivm). It was both larger and more dynamic than WebAssembly.

I'd be very interested to read more about this. It looks like you are using "one big function" with computed goto (https://github.com/FastVM/Web49/blob/main/src/interp/interp....). My experience working on this problem led me to the same conclusion as Mike Pall, which is that compilers do not do well with this pattern (particularly when it comes to register allocation): http://lua-users.org/lists/lua-l/2011-02/msg00742.html

I'm curious how you worked around the problem of poor register allocation in the compiler. I've come to the conclusion that tail calls are the best solution to this problem: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

Maybe take a look at MiniVM[0]? It was on HN a couple months ago[1].

[0]: https://github.com/fastvm/minivm

MiniVM: A zero-dependency cross-language runtime on par with LuaJIT and C\ (19 comments)

Android 2.3 support was dropped back in 2019, see https://github.com/koreader/android-luajit-launcher/pull/91. The current minimum supported version is 4.0.

Here: https://github.com/koreader/android-luajit-launcher/blob/master/app/src/main/java/org/koreader/launcher/device/DeviceInfo.kt

That said, I've even developed a Lua/Android bridge myself back in time (other people have much improved that since) - https://github.com/koreader/android-luajit-launcher However, that was not driven by the idea to make "things simpler" somehow. I'm not providing that reference as a suggestion you use it for your task. It was done to provide means to run an existing Lua based codebase on Android devices. If I was to develop an application for Android devices from scratch, I think I would go with the Android SDK and Android Studio, probably using Kotlin.