## 4 Results
### Performance Comparison  
Table 1 presents the results of executing certain test cases from \"The Great Win32 Computer Language Shootout\" suite, which were adapted from the original code for Visual C++ [32]. Two programming languages are included for comparison. The first is Lua, represented by three versions to illustrate the differences in implementation and optimization levels:  
* Lua 4.0 implements a stack-based virtual machine similar to Stella, utilizing only tables for storing objects and arrays;
* Lua 5.0 adopts a register-based approach, potentially leading to a more efficient use of load and save instructions, shorter bytecode, and faster execution due to fewer operations on values compared to pushing and popping them from the stack;
* Lua 5\({}^{\prime}\) represents a variant of Lua 5.0 without table optimizations for arrays, tail recursion, or dynamic stacks [31]. On the other hand, the selected version of MicroPython implements Python 3.4 along with select extensions from more recent language versions while retaining the core features of the CPython interpreter [17]. MicroPython was executed using Unix version port v1.10 in the same configuration as the other languages. The results presented in this table are derived from the average of twenty executions. The first test, involving summing a large number of values, clearly indicates the advantage of using registers for executing mathematical operations efficiently. The examination of the compiled bytecode shows that Lua 5.0 successfully maintains these values in two separate registers, with sum addition and counter incrementation written as two addition instructions. In contrast, stack-based languages must push both values onto the stack for each operation, execute the operation, pop the value from the stack, store it in a variable, and repeat this process for every computation and loop iteration. Decompilation further highlights this, as Lua 5.0 features a five-instruction loop compared to Stella's sixteen instructions, approximately proportional to the difference in execution time between the two languages, as highlighted in Figure 16.  
For recursive functions, such as the Ackermann or Fibonacci series, Stella demonstrates significant acceleration for two main reasons:  
* The interpreter uses an array of call frames for caching less deeply nested functions, doubling the frame size for deeper recursion. Conversely, Lua and Python allocate a separate object to track each call frame, deallocating it upon removal. This allocation \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Program** & **Lua 4.0** & **Lua 5\({}^{\prime}\)** & **Lua 5.0** & **Stella** & **Python 3.4** \\ \hline sum (2 \(\times\) 10\({}^{7}\)) & 1.237 & 0.541 & 0.546 & 1.622 & 1.481 \\ fibonacci (30) & 0.953 & 0.684 & 0.690 & 0.080 & 0.139 \\ ack (8) & 1.004 & 0.863 & 0.884 & 0.123 & 0.238 \\ random(1 \(\times\) 10\({}^{6}\)) & 1.045 & 0.969 & 0.963 & 0.121 & 0.168 \\ sieve(100) & 0.937 & 0.827 & 0.572 & 0.195 & 0.192 \\ heapsort (5 \(\times\) 10\({}^{4}\)) & 1.086 & 1.050 & 0.703 & 0.081 & 0.109 \\ matrix (50) & 0.847 & 0.828 & 0.599 & 0.122 & 0.097 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Execution time comparison of Lua, Stella, and MicroPython (measured in milliseconds). overhead is evident, particularly in the Ackermann function, which runs almost twice as slowly in Python. * Each call records the index of the new frame's starting value on the stack, which also serves as the call's return value. Consequently, access to local variables is achieved through this starting index and the instruction is offset without duplicating values, while object marking is determined solely by the stack's top index. The Linear Congruential Generator (LCG) function employs a comparable number of instructions across languages but benefits from avoiding the constant allocation and deallocation of call frames when fewer calls are made. The use of primitive single-precision floating-point types also prevents the instantiation of new number objects, unlike Python.