I'm really surprised at SquirrelFish's simplicity. I was expecting some kind of register allocator, even a linear scan. Linear scan register allocation is fast because you only have to iterate over all the code once instead of building an interference graph. An interference graph has nodes which represents each physical register on the machine. If two registers are needed at the same time, the two nodes are connected in the graph. Then you color the graph with however many physical registers you have to assign registers. If you can't color the graph, you remove a node by "spilling" it and removing the node from the graph. A spilled node means that the value is stored in memory instead of a register. However, SquirrelFish says forget that! Let's just store everything in memory. Doing an operation involves loading something from memory, the operation, then storing it back. Primitive bytecode operations are done in direct x86. Addition for example, are done with an actual x86 addition. More complex opcodes such as resolv_func have C functions. Here's some sample x86 code for the bytecode resolve_func:

010E01CE  mov         dword ptr [edi+8],0Ah
010E01D5  mov         eax,0Ah
010E01DA  mov         dword ptr [edi+18h],eax
010E01DD  mov         dword ptr [esp+4],0BAFB10h
010E01E5  mov         ecx,esp
010E01E7  mov         dword ptr [esp+38h],edi
010E01EB  call        JSC::Interpreter::cti_op_resolve_func (4A1340h)