Lines Matching +full:- +full:1
10 | ------------------------------- | ---------------------------------------------------------- |
23 1. The platform should scale from microcontrollers to hi-end mobile phones:
24 1. It should fit into 50Kb of ROM.
25 1. It should be able to run consuming 64Kb of RAM.
26 1. Program execution via bytecode interpretation should be enabled on all targets.
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.
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,
42 1. There is a dedicated register called accumulator, which is addressed implicitly by some
44 1. Bytecode's instruction set architecture is machine-readable with a dedicated API for
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
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.
61 Besides, the machine-readable form naturally sets up the framework for self-testing (e.g.
73 1. All entities in the executable file should be encoded and stored compactly to avoid bloating
75 1. Format should enforce as "flat" layout as possible: referencing metadata from other metadata
77 1. Runtime memory footprint of executable files should be low.
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)
86 in the offset. Additionally, 4-byte alignment is enforced for the most of data structures for
89 1. The format uses raw offsets as the main access method to the actual data and doesn't
105 `zstd-19` algorithm. According to our research, it decreases file size by 21% and
116 1. Interpreter should run no slower than state of the art interpreters.
117 1. Interpreter should be portable enough to run on targets from IoT devices
118 to hi-end mobile phones.
119 1. Interpreter should not create extra pressure on the host system.
123 1. Interpreter uses indirect threaded dispatch technique
125 1. Interpreter does not depend on C++ standard library. All necessary classes, containers, etc.
127 1. Interpreter is stackless (from the host stack perspective): Whenever a call from managed code
132 1. Interpreters are by nature slower than native code execution. Slowdown can be explained by:
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
139 1. An ideal target would be 5x-10x slowdown factor (compared to native execution)
140 for statically typed languages that run on the platform natively, and 15x-20x for L2 languages.
141 1. Panda should scale onto a wide range of devices, including IoT devices. Although more and
146 1. According to our experiments, a stackless interpreter for a stack-based bytecode (which is by
147 nature slower) can even beat sometimes a non-stackless interpreter for a register-based
158 1. All virtual registers should explicitly and precisely distinct between garbage collectable
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
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,
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
180 1. Although tagged virtual registers occupy more memory (especially on 64-bit architectures),
182 trying to distinguish between objects from non-objects on an "imprecise" stack.
183 1. Where does 128 comes from? It is `128 = 64 + 64`. The first 64 is either `sizeof(long int)`
184 or `sizeof(double)` or `sizeof(void *)` on a 64-bit architecture (i.e. theoretical maximum
188 1. Enforcing a virtual stack to mapped to the host stack faces us with some unpleasant constraints
202 1. Interpreter should allow testing without involving front-ends of concrete languages.
203 1. Interpreter should allow early testing.
204 1. Interpreter should allow early benchmarking.
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.
216 A general overview of managed assembly languages can be found [here](overview-of-managed-assemblers…
218 Lots of things are being created in parallel, and currently there is no stable front-end for Panda
219 for any high-level language. However, once they appear, front-end engineer will obviously want a