[Vm-dev] Changing CogSimulator abi

Lars lars.wassermann at googlemail.com
Sat Jan 26 21:16:10 UTC 2013

Hello Eliot, hello vm-dev,

@vm-dev: I'm still sometimes working on cog ARM, but due to my studies I 
have little time. The problem I'm working on is that IA32 has a 
different function call ABI than ARM. While on IA32, you need to push 
the return address, on ARM, you load it into the LR-register.

A design decision to accommodate this difference in the ARM JIT was to 
use IA32 ABI within all cog code, even when running on ARM. Only when 
calling the (compiled) interpreter, we use ARM ABI. The hope was, that 
this way we need to change little of the existing code.

@all: In the last days of working (spread across several months), I 
implemented the Call opcode (which is used by cogit whenever a function 
is called) by pushing the return address before branching to the target 
(IA32 ABI).
Also, I changed the trampoline generation to ask the compiler for the 
appropriate call opcode for the ABI (so far not committed), which is 
either Call in case of IA32 or BL in case of ARM. I'm not happy with 
that location for this behavior, but I don't know whether there exists a 
better place. Also, #hasLinkRegister is implemented on the compiler.

Now, that calling the interpreter has changed, I run into the problem, 
that the simulator is expecting the stack pointer to point to the return 
address. The simulator is assuming IA32 ABI.

How best to attribute for the changed ABI in the simulator?
     Subclass the simulator? On which level, VMSimulator or 
VMSimulatorLSB? That change would be orthogonal to the LSB subclass (if 
there ever will be a MSB subclass).
     Or introduce two classes which do know the ABI and are responsible 
for all places where ABI is used? Also the eventual changes to 
trampoline and enilopmart generation? Which problems might arise from 
this design decision with respect to the C-translation?

All the best,

More information about the Vm-dev mailing list