Architecture adjustment of Aq virtual machine and bytecode

Yesterday, AQ v0.1.0-alpha was released, and the virtual machine design continued the previous architecture without any architecture level adjustments. For current needs, it can meet certain requirements. However, in the recent development process, areas that can be optimized have been identified. The focus is on adjusting the memory architecture.

At present, bytecode directly stores all memory data and types. A large amount of data among them needs to be written by the virtual machine during runtime, so a large amount of data is allocated when not in use, resulting in a lot of memory waste. For the example Hello World (hello world. aq, hello world. aqbc), the AQ v0.1.0-alpha source code only occupies about 50 bytes, but the bytecode memory occupies about 100 bytes. To some extent, the original purpose of bytecode - to save memory - has failed to play a role and has increased the burden.

Therefore, it is extremely necessary to adjust the architecture of AQ virtual machines and bytecode. Refer to current interpreted programming languages. The most common approach is to use a constant pool.

To achieve this goal, the following changes are required:

1. Modify the relevant code of the compiler.

2. Modify the relevant code of the virtual machine.

3. Add new instructions to read data from the constant pool.

4. Adjust the original type storage method and refer to the bytecode constant pool design methods in Python and JavaScript.

There is still a significant amount of resource waste at present, and this issue should be addressed when AQ v0.11-alpha is released.

Meanwhile, in addition to the issues mentioned here, there are still many unresolved issues in the release of AQ v0.1.0-alpha. One of the more serious issues is the failure to handle the parameters and return values of custom functions.

For this issue, one should also refer to the design ideas of interpreted programming languages such as Python and JavaScript. Optimize function calls to avoid wasting resources during the calling process.

In addition, there is an extremely important issue that has not been resolved in this version release - the design of implementing standard libraries and the calling of third-party libraries. At present, only print function is supported, and third-party libraries cannot call it. Therefore, the resolution should also be accelerated.

In this version, there are still type conversion errors that cannot be automatically converted and should be fixed as soon as possible.

In this version, support for new syntax is still lacking and should be added as soon as possible.

In this version, support for dynamic types is not available and should be added in subsequent compiler and virtual machine adjustments.

Finally, the release of AQ v0.1.1-alpha version will also follow closely, and relevant issues should be resolved as soon as possible.