Lines Matching full:of

10 Before discussing bytecode per se, let's take a look at an over-simplified picture of a real
16 directly on the CPU) or _memory_ (some locations in computer's RAM). An important subset of memory
21 In real world, different CPU manufacturers provide different sets of commands for their devices –
23 that the number and purpose of registers differs, too. Some nuances of working with stack may also
26 Here comes the bytecode. Simply said, it is an attempt to build an abstract CPU on top of real
27 ones. A program written for such abstract CPU can be run on any real hardware with the help of a
28 special program called _interpreter_. The goal of the interpreter is to read our unified _virtual_
29 commands (or bytecode) and execute them. Of course, this implies additional performance overhead
40 Just as real CPUs can expose different instruction set architectures, there is no universal way of
41 building bytecode. Following sections explain advantages and disadvantages of various approaches.
52     push_arg1 ; copy the first argument to the top of the stack
53     push_arg2 ; copy the second argument to the top of stack
55     ; at this point, the top of the stack contains arg1 + arg2
85 Since bytecode interpretation is a required program execution mode for Panda, performance of the
89 However, to address the issue of compactness, two main tweaks are used:
92 * Variable size of instructions with frequent instructions are encoded to be smaller.
94 According to our research, these tweaks will allow to reduce the size of uncompressed bytecode by
115 In an ideal case, accumulator register may safe us ~25% of size. But it needs to be used carefully:
119   body forming a separate def-use chain, i.e. in the majority of loops.
125 To address the risk of producing inefficient bytecode with redundant moves from and to
126 accumulator, a simple optimizer will be introduced as a part of the toolchain.
128 Finally, using accumulator allows getting rid of the instructions for writing the result to the reg…
131 ### Variable size of instructions
157 to the stack-based approach. Of course, if virtual registers have large numbers that do no fit
165 How to make sure that we benefit from the shorter encoding most of the time? An observation shows
166 that most of operations inside a function happen on local and/or temporary variables, while
167 function arguments participate as operands in a fewer number of cases. With that in mind, let's map
176 be beneficial. For example, we have three types of instructions for integer-sized arithmetic
179 overloads are calls (different number of operands) and calls are the most popular instructions in
185 `adda ...` instruction, what are types of its operands?
192 all kinds of addition (for short and long integers, for signed and unsigned integers, for
195 The first approach bloats the instruction set, but keeps the semantics of each instruction simple
196 and compact. The second approach keeps the instruction set small, but bloats the semantics of
201 Consider a simple example: what is the result of the expression `4 + "2"` in JavaScript and, say,
219 no, they must not, virtual registers may hold value of different types (just as hardware registers,
221 that once a value of a certain type is store into a virtual register, all operations on that value
222 must be of this very type, unless the virtual register is redefined. Language compilers and