Lines Matching full:the
5 This document outlines the key design decisions in the interpreter and its companion components:
11 | Requirements | Enlists the requirements to the component. |
12 | Key Design Decisions | Summarizes the key decisions to address the requirements. |
13 | Rationale | Elaborates on the rationales behind the decisions. |
16 Please refer to the [glossary](glossary.md) for terminology clarification.
20 This section outlines common requirements that should be considered while designing the interpreter
21 and all related components of the platform:
23 1. The platform should scale from microcontrollers to hi-end mobile phones:
27 1. The platform should support multiple programming languages
33 1. Bytecode should allow the interpreter to run no slower than state of the art interpreters.
36 across all components of the platform.
49 For the rationale on the bytecode type, please see [here](rationale-for-bytecode.md).
51 Rationale on the machine-readable instruction set architecture is following. Since bytecode
52 is the main form of program representation, information about it is needed in many components of
53 the platform outside the interpreter. Having this crucial information copy-pasted or delivered as
54 a bunch of C/C++ headers is very fragile and error-prone. At the same time,
55 with the machine-readable ISA we can re-use this information in many places already now, e.g.:
57 * In Panda Assembler's back-end, we automatically generate emission of bytecode in the binary form.
58 * Converter from bytecode to the compiler's intermediate representation is partially implemented
59 with code autogenerated from the ISA.
61 Besides, the machine-readable form naturally sets up the framework for self-testing (e.g.
67 Please find the implementation of the instruction set architecture [here](../isa/isa.yaml).
73 1. All entities in the executable file should be encoded and stored compactly to avoid bloating
81 1. The entire code of the application (excluding frameworks and external libraries) fits into a
84 1. All metadata entities are split into two groups: local (declared in the current executable file)
85 and foreign (declared elsewhere). Local entities can be accessed directly by the offset
86 in the offset. Additionally, 4-byte alignment is enforced for the most of data structures for
87 more efficient data reads from the Panda binary file. Foreign entities are loaded from their
89 1. The format uses raw offsets as the main access method to the actual data and doesn't
94 According to our measurements of the most popular 200 Chinese mobile applications,
96 for the same application introduces extra duplication of metadata and implies extra burden on
102 select the optimal size based on actual code base.
104 To enable even more compact size of resulting binaries, we will compress it with the
110 Please find the specification [here](file_format.md).
116 1. Interpreter should run no slower than state of the art interpreters.
119 1. Interpreter should not create extra pressure on the host system.
126 are reimplemented by the platform.
127 1. Interpreter is stackless (from the host stack perspective): Whenever a call from managed code
128 to managed code is performed, no new host frame is created for the interpreter itself.
133 1. The inevitable extra cost that interpreters pay for decoding and dispatching bytecode
135 1. The "heaviness" of language semantics that interpreters should implement.
136 1. The "nativeness" of the language implementation to the platform. A language that is
137 implemented in another language that runs on the platform may run slower because of
140 for statically typed languages that run on the platform natively, and 15x-20x for L2 languages.
142 more toolchains support C++ compilation for IoT, the standard library is often not present
143 on the device. Since static linking with a subset of the library is a pain and may not guarantee
152 Please find the reference implementation [here](../runtime/interpreter).
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.
163 1. Virtual stack should abstract limitations possibly imposed by the host stack.
167 1. All virtual registers are "tagged", meaning that they contain both the payload and additional
170 1. The size of a virtual register is not hardcoded by design. Currently it is always 128 bits,
171 but this is an implementation detail which is hidden behind the interfaces
176 mapping virtual stack directly to the host stack.
183 1. Where does 128 comes from? It is `128 = 64 + 64`. The first 64 is either `sizeof(long int)`
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
189 on IoT devices. On such devices the size of the host stack may be severely limited: as a result,
190 managed application have to think about this limitation, which contradicts the idea of
192 constraint, which can be relaxed even further with the stackless interpreter (see above).
196 Please find the reference implementation [here](../runtime/interpreter/frame.h).
208 1. A light-weight Panda Assembly language is developed, along with the Panda Assembler tool.
209 1. A compliance test suite for the Panda Assembly language is created. The core part of the suite
210 are small chunks of hand-written Panda Assembly covering corner cases, while the majority 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
226 Please find the specification [here](assembly_format.md).
228 Please find the implementation [here](../assembler).