## 3 Materials and Methods
### Language Concepts and Extensions
#### 3.2.2 Compatibility Limitations  
In porting the original version of the virtual machine and its libraries, it was essential to account for all limitations, available modules, and the behaviour of memory management functions to ensure an efficient environment that mirrors the functionality of the desktop version. However, due to differences in architecture, platform-dependent library behaviours and calls, as well as resource availability, certain features initially designed for optimization and performance on desktop platforms were either constrained or entirely removed. Furthermore, the handling of requests for loading and processing bytecode required careful consideration, as differences in available data types could potentially lead to corrupted or unexpected states. Below, several constraints are outlined that, while not directly affecting the interpreter's function in the microcontroller, ensure stable platform operation regardless of memory and system requirements. Initially, Stella's base implementation includes a custom memory management system that categorizes memory fragments into predefined block sizes, reusing freed blocks by storing them in a temporary array for rapid future allocations. This reduces fragmentation and improves performance compared to standard \"malloc\" and \"free\" calls. Each allocation in this model includes a memory fragment structure with metadata, allowing efficient management and the quick allocation of available block counts on demand, although this increases overhead since it does not immediately release freed memory but marks it for reuse within the program. This system is primarily designed for caching temporary local variables, such as strings and numbers, with a predefined one-megabyte size [7]. However, given the significantly reduced memory available on microcontrollers, this system was completely replaced with standard system calls and an auxiliary map for caching temporary values. TCP and UDP socket libraries were replaced with integrated network connection libraries, and the threading and signalling mechanism libraries were removed entirely. The serialization and transmission of bytecode with numeric values, as well as the deep copying of reference types, present additional challenges. Some platforms, such as Arduino Uno, use the \"double\" label interchangeably with \"float\" for single-precision floating-point numbers. This can lead to scenarios where values cannot be correctly loaded on certain platforms, and can also result in misaligned bytecodes during deserialization, which may cause unstable behaviour or a corrupted virtual machine state before execution. To address this, byte sizes were added for storing bytecode values, enabling validation and type determination based on the platform, while compatibility was further enhanced by using 32-bit values for decimal numbers within loading requests. This allows for conversion to 64-bit storage if the virtual machine detects that the format is supported. Finally, to make memory use more efficient, the garbage collector can be further adapted to the selected development board. The initial collection threshold was reduced from 1 kilobyte to 256 bytes, while the growth factor for subsequent collections remains at 2, meaning the threshold doubles after each collection. An additional parameter, the threshold reduction factor, was added to lower the memory threshold for the next collection in cases where the occupancy criterion is satisfied prior to the next collection. For example, if at any point the virtual machine registers memory occupancy three times below the next collection limit, it can automatically lower the threshold by a predetermined factor. The application of these values depends on the use case and frequency of memory allocation, but they offer development teams greater flexibility in managing collection conditions.