# What the numbers mean in vm_min.cpp!

/I finally freaking figured out some cryptic part of Tamarin. What the numbers in vm_min.cpp mean! Well kind of mean, or at least how they are generated. Let's take a quick look at the following:

`VM_Min.cpp`

// OP_getslot offset=6346

NEST, /* npck -6288 */ 112, 231, IMM, LIT8, 1, ISUB, NEST, /* getslot -4840 */ 24, 237, NEXT,

The op_getslot refers to the JavaScript opcode getslot. The offset 6346 is the index of the code_pool to the Forth words that execute getSlot. Now what the heck does 112, 231 with an npck of -6288 mean? It means, to jump to the Forth word npck, we have to go back -6288 from our current position. How did we get this number?Well 6346 is the getslot offset, 59 is the npck offset. So we have the equation:

6346(getslot offset) + 1(NEST) - 59(npck offset) = 6288 difference.

The +1 is because we are one position PAST getslot, which is due to the NEST. So what do these numbers 112, 231 mean? Time for some binary fun! The most significant bit is defined by the furthest right number. Therefore, 231 is the MSB, and 112 is the LSB here. Convert these two numbers to binary individually, and then concatenate them:

But what about positive offsets. Simple! Attach a 0 to the MSB:`231 = 0b11100111`

112 = 0b1110000Concatenated:

// 231 // 112

11100111 01110000 // -6288 in 2s complementConvert to a positive number to verify and we get:

0001100010010000

`Which is:`

6288 = 0b1100010010000

`/* delmultiprop_subarray 159 */ 159, 0,`

Ahh the convolution only Tamarin can provide!* Update provided by Adobe:

the primitives NEST and JUMP take a signed 16-bit offset, which is stored as two unsigned 8-bit bytes in the code_pool array.