The vision of this group is to create a Forth based AI Computer where you can communicate with the system using an English conversational approach. We will add many high level Words for string manipulation, arrays, and other structures as we develop this computer. We will extend Forth to include AI words too. All of this will be built into FPGAs which are really parallel computers written in Behavioral System Verilog (the Assembler).
For a long time we all agreed that we need a mainstream language running on top of the Core 1. Recently the idea of implementing Lua was well received. Here is a paraphrase of our discussions from the Facebook group, archived before it scrolls away. First the market analysis, then the technical issues.
Lua is embedded in NGINX, so it is great for coroutines. Really CSP communicating sequential processes. Which is also the basis for GoLang, another of the fastest growing languages.
Lua is very strong in embedded systems. Not quite the same as real time control, but related. At least in my mind.
Onto the technical issues.
Lua 4.01 uses a stack based virtual machine. We only need to implement 48 op codes.
https://www.lua.org/source/4.0/lopcodes.h.html
Each opcode could be a Forth routine, so easy to divide up the work. Plus we need a garbage collector, ideally real time. And some other things which we do not yet know about.
We all agreed that the garbage collection part was not so easy.
Lua 4.01 is only 9K lines of code, so not that hard to reproduce. Probably quite easy, since we already have a stack machine.
But Lua 5.0 is a different beast. First of all it is the one with coroutines. So worth using it. But Lua 5.0 is a virtual register machine. These are not CPU registers, they are references into the stack. Lua 5.0 references into the stack, from either the bottom or the top.. If you cache the TOS and NOS in a register, the top of stack is not on the stack. Ouch!
Then we have the issues if you implement LUA on a stack machine then you loose all of the C libraries. A huge hit, from not doing what the mainstream world is doing. But you gain all of the FPGA functionality. And you gain fast context switching between those coroutines.
And we have to build up some infrastructure to support the application. Not yet sure what it is.
I will also point out that one target application is a web server. Turns out that LUA runs inside of NGINX. They both share the same co-routine model. Which means there is a potential community of users, if we can figure out something that a web server should be able to do. Audio or video compression comes to mind.
For a long time we all agreed that we need a mainstream language running on top of the Core 1. Recently the idea of implementing Lua was well received. Here is a paraphrase of our discussions from the Facebook group, archived before it scrolls away. First the market analysis, then the technical issues.
Lua is the fastest growing language. Grew 50% last year, followed by Rust at 40% https://thenewstack.io/70-percent-of-developers-using-or.../
Lua is great for Robotics. https://bvisness.me/coroutines/
Lua is embedded in NGINX, so it is great for coroutines. Really CSP communicating sequential processes. Which is also the basis for GoLang, another of the fastest growing languages.
Lua is very strong in embedded systems. Not quite the same as real time control, but related. At least in my mind.
eLua is strong in microcontrollers. https://github.com/elua/elua
Onto the technical issues. Lua 4.01 uses a stack based virtual machine. We only need to implement 48 op codes. https://www.lua.org/source/4.0/lopcodes.h.html Each opcode could be a Forth routine, so easy to divide up the work. Plus we need a garbage collector, ideally real time. And some other things which we do not yet know about.
We all agreed that the garbage collection part was not so easy.
Lua 4.01 is only 9K lines of code, so not that hard to reproduce. Probably quite easy, since we already have a stack machine.
But Lua 5.0 is a different beast. First of all it is the one with coroutines. So worth using it. But Lua 5.0 is a virtual register machine. These are not CPU registers, they are references into the stack. Lua 5.0 references into the stack, from either the bottom or the top.. If you cache the TOS and NOS in a register, the top of stack is not on the stack. Ouch!
Then we have the issues if you implement LUA on a stack machine then you loose all of the C libraries. A huge hit, from not doing what the mainstream world is doing. But you gain all of the FPGA functionality. And you gain fast context switching between those coroutines.
And we have to build up some infrastructure to support the application. Not yet sure what it is.
I will also point out that one target application is a web server. Turns out that LUA runs inside of NGINX. They both share the same co-routine model. Which means there is a potential community of users, if we can figure out something that a web server should be able to do. Audio or video compression comes to mind.