Comments on: Issues in Writing a VM – Part 2

By: avi

avi — Tue, 01 Apr 2008 04:57:56 +0000

I’ve just discovered your blog. Fantastic! Keep on writing.

By: lorg

lorg — Sat, 29 Mar 2008 19:59:21 +0000

Also, Arkon: the change to eip Erez suggested may be done by the VM manually. It doesn’t necessarily involve changing the expressions.

By: lorg

lorg — Sat, 29 Mar 2008 19:57:41 +0000

My solution was just checking if the IP register was *touched*.

The CPU class knows what is the IP register, and the VM can ask it about it.
Each time a register is modified, the VM-state holder checks if it’s the eip register, and if it is, it sets a flag to True. Before each instruction, the VM checks to see if the flag is false. If it is, it modifies the IP. If it isn’t it keeps the IP value, and resets the flag back to false.

In effect, this is a hook by the VM state on register changes. I know it special-cases the IP register, but I think that’s OK.

By: arkon

arkon — Sat, 29 Mar 2008 19:46:05 +0000

Ah I forgot to mention that you will have to change the expression trees so that all IP references as rvalues will use the shadowed IP..

By: arkon

arkon — Sat, 29 Mar 2008 19:44:37 +0000

Ahh Eres nice idea. But if we care about performance, I’m not sure whether inserting an expression all the times, where sometimes they won’t be used, is good enough. Though on the other hand, it depends on how quick you know if there was a change.

The easiest, ok not the easiest, but the best solution would be to have an IP register and a shadow IP register. The shadow register will contain the current IP, and will be used for rvalues only. The IP register will be reset to undefined every instruction. Then if the real IP register was set, you will know to use it. Otherwise continue to next instruction, and set the shadow one again.
This wasy even if an instruction jumps to itself it will keep on working…

By: lorg

lorg — Sat, 29 Mar 2008 01:36:50 +0000

You are right in regards to the real solution, this is a very good point. However, it might apply differently to other processors. It might still be workable there by changing the instructions’ expression trees. In any case I’ll probably have to work it in. Thanks!

As to appending the change to the IP:
This solution was workable, but more work, and it meant modifying the expressions. The third solution is more general, and it seems to me to be more elegant.

By: Erez

Erez — Sat, 29 Mar 2008 00:02:51 +0000

Regarding the 2nd 2:
Appending a change to the IP should work for all instructions, if you follow the IP to figure out what statement to execute next.

The real solution however (and you should know it), for Intel at least, is *prepending* the change to the IP for all instructions. It works for absolute jumps, and especially relative ones: jumps/calls are relative to the end of the instruction.