Lines Matching full:to
11 | Requirements | Enlists the requirements to the component. |
12 | Key Design Decisions | Summarizes the key decisions to address the requirements. |
16 Please refer to the [glossary](glossary.md) for terminology clarification.
23 1. The platform should scale from microcontrollers to hi-end mobile phones:
25 1. It should be able to run consuming 64Kb of RAM.
33 1. Bytecode should allow the interpreter to run no slower than state of the art interpreters.
34 1. Bytecode should be compact in size to avoid bloating application code.
35 1. Bytecode description should have a single entry point to simplify maintenance
40 1. Bytecode is register-based: all arguments and variables are mapped to virtual registers,
58 * Converter from bytecode to the compiler's intermediate representation is partially implemented
73 1. All entities in the executable file should be encoded and stored compactly to avoid bloating
76 should be kept at minimum to reduce access overhead during runtime.
82 single file to gain maximum benefits from deduplicating constant string pools, information
89 1. The format uses raw offsets as the main access method to the actual data and doesn't
90 require explicitly how structures should be located relative to each other.
94 According to our measurements of the most popular 200 Chinese mobile applications,
99 Our aim is to address these issues by having a single file for application code. This, however,
101 more space. As a solution, our file format will support variable length of identifiers to
104 To enable even more compact size of resulting binaries, we will compress it with the
105 `zstd-19` algorithm. According to our research, it decreases file size by 21% and
117 1. Interpreter should be portable enough to run on targets from IoT devices
118 to hi-end mobile phones.
124 (implemented via computed goto) to reduce dispatch overhead.
128 to managed code is performed, no new host frame is created for the interpreter itself.
136 1. The "nativeness" of the language implementation to the platform. A language that is
139 1. An ideal target would be 5x-10x slowdown factor (compared to native execution)
144 optimal size of resulting native binary executable files, it is more reasonable to reimplement
146 1. According to our experiments, a stackless interpreter for a stack-based bytecode (which is by
159 objects and non-garbage collectable primitives to simplify automatic memory management.
160 1. Virtual registers should be able to hold following types: unsigned and signed integers with
161 the size of up to 64 bits, floating point numbers of single and double precision, raw pointers
162 to the objects on 32-bit and 64-bit architectures.
172 and can be reduced for memory-constrained targets and to 64 bits (using NaN-tagging technique).
173 1. By default virtual stack is not mapped to a host stack, instead it is allocated on heap using
176 mapping virtual stack directly to the host stack.
182 trying to distinguish between objects from non-objects on an "imprecise" stack.
185 size of the payload we are required to store in a virtual register). The second 64 is for tag
186 and padding. A lot of free space is expected to be in the padding area. Probably we may use it
188 1. Enforcing a virtual stack to mapped to the host stack faces us with some unpleasant constraints
190 managed application have to think about this limitation, which contradicts the idea of
212 1. A set of benchmarks is ported to Panda Assembly and maintained as a part of the source tree.
220 stable interpreter to run their code. At the same time, interpreter developers need some tools
221 beside too granular unit tests to ensure quality of the interpreter and companion components