<p>What are the pros and cons of ways to implement the <code>LOAD</code> command in a statically typed VM?</p>
<p>There is two ways to implement <code>LOAD</code> command:</p>
<p>For example to load the number <code>5</code> of the <code>int32</code> type:</p>
<ol>
<li><p>To create a one command LOAD with type as argument. Like this:</p>
<pre><code>LOAD int32 5
</code></pre>
</li>
<li><p>To сreate a custom command for all types. Like this:</p>
<pre><code>LOAD_INT32 5
</code></pre>
</li>
</ol>
<p><strong>What are the pros and cons of this two ways?</strong></p>

<implementation><virtual-machine><bytecode>
What are the pros and cons of ways to implement the LOAD command in a statically typed VM?
CC BY-SA 4.0
2023-05-28T15:23:23.930Z
The JVM has both actually, the former for classes and the latter for primitive types.
Seggan
<p>The main reason you might want to have a single &quot;load&quot; opcode with an argument controlling the type of value loaded, is to reduce the number of distinct opcodes in your bytecode language. If each opcode must fit in one byte, then you can only support 256 different opcodes, so if you need lots of other opcodes then perhaps you could consider replacing all of the different &quot;load&quot; opcodes with a single one that takes an additional argument.</p>
<p>On the other hand, 256 is actually quite a lot, and even if you are running out of 8-bit opcodes, it probably makes sense to look for savings elsewhere, because the &quot;load&quot; opcodes are some of the most-used ones.</p>
<p>There are several disadvantages of having a single &quot;load&quot; opcode which takes the loaded type as an argument:</p>
<ul>
<li><code>LOAD_INT32 5</code> takes five bytes (one for the opcode, four for the value), whereas <code>LOAD int32 5</code> takes six (one for the opcode, one for the type, four for the value). So the size of a compiled program will be a bit bigger in the latter case.</li>
<li><code>LOAD int32 5</code> and <code>LOAD int64 5</code> will take up different numbers of bytes for the second argument, so upon seeing the <code>LOAD</code> opcode you don't know how many more bytes are part of this instruction until you've read the first argument. This can significantly increase the complexity of &quot;parsing&quot; the bytecode language.</li>
<li>A bytecode interpreter will typically have a big <code>switch</code> statement which branches on the opcode. If the <code>LOAD</code> opcode has a &quot;type&quot; argument, then you will need a second <code>switch</code> on that argument, meaning more opportunities for the <a href="https://en.wikipedia.org/wiki/Branch_predictor" rel="nofollow noreferrer">branch predictor</a> to miss.</li>
<li>If you have a bytecode verifier (i.e. a static checker which ensures that a bytecode program is correct according to certain rules, including some form of type-checking) then it will be simpler to implement if you don't need to look at the arguments to determine the types or stack effects of an instruction. If the effects of each instruction only depend on the opcode, you can implement this as a simple lookup table from opcodes to their effects. (For example, the effects of an <code>ADD_INT32</code> opcode would be something like <code>pop int32, pop int32, push int32</code>.)</li>
</ul>

CC BY-SA 4.0
2023-05-29T13:30:52.370Z
2023-05-29T13:30:52.370Z
kaya3
# What are the pros and cons of ways to implement the LOAD command in a statically typed VM?
Posted by: username_0 on 2023-05-28
What are the pros and cons of ways to implement the LOAD command in a statically typed VM?
There is two ways to implement LOAD command:
For example to load the number 5 of the int32 type:

To create a one command LOAD with type as argument. Like this:
LOAD int32 5


To сreate a custom command for all types. Like this:
LOAD_INT32 5



What are the pros and cons of this two ways?
**Tags:** implementation virtual-machine bytecode
> **Comments:**
> **username_1**: The JVM has both actually, the former for classes and the latter for primitive types.  
---
## 1 answers
### Answer by username_2 on 2023-05-29. Score: 3 | Accepted answer
The main reason you might want to have a single "load" opcode with an argument controlling the type of value loaded, is to reduce the number of distinct opcodes in your bytecode language. If each opcode must fit in one byte, then you can only support 256 different opcodes, so if you need lots of other opcodes then perhaps you could consider replacing all of the different "load" opcodes with a single one that takes an additional argument.

On the other hand, 256 is actually quite a lot, and even if you are running out of 8-bit opcodes, it probably makes sense to look for savings elsewhere, because the "load" opcodes are some of the most-used ones.

There are several disadvantages of having a single "load" opcode which takes the loaded type as an argument:

* `LOAD_INT32 5` takes five bytes (one for the opcode, four for the value), whereas `LOAD int32 5` takes six (one for the opcode, one for the type, four for the value). So the size of a compiled program will be a bit bigger in the latter case.
* `LOAD int32 5` and `LOAD int64 5` will take up different numbers of bytes for the second argument, so upon seeing the `LOAD` opcode you don't know how many more bytes are part of this instruction until you've read the first argument. This can significantly increase the complexity of "parsing" the bytecode language.
* A bytecode interpreter will typically have a big `switch` statement which branches on the opcode. If the `LOAD` opcode has a "type" argument, then you will need a second `switch` on that argument, meaning more opportunities for the [branch predictor](https://en.wikipedia.org/wiki/Branch_predictor) to miss.
* If you have a bytecode verifier (i.e. a static checker which ensures that a bytecode program is correct according to certain rules, including some form of type-checking) then it will be simpler to implement if you don't need to look at the arguments to determine the types or stack effects of an instruction. If the effects of each instruction only depend on the opcode, you can implement this as a simple lookup table from opcodes to their effects. (For example, the effects of an `ADD_INT32` opcode would be something like `pop int32, pop int32, push int32`.)
---
