Dynamic Recompilation Article Index for
Dynamic
Website Links For
Dynamic
 

Information About

Dynamic Recompilation




representation such as Java , Corn or CLR bytecodes. Full-speed debuggers could also utilize it to reduce the space overhead incurred in most Deoptimization techniques, and many other features such as dynamic Thread Migration .


EXAMPLE

Suppose a program is being run in an emulator and needs to copy a String .

The program is compiled originally for a very simple processor. This processor can only copy a Byte at a time, and must do so by first reading it from the source string into a Register , then writing it from that register into the destination string.

The original program might look something like this:

beginning:
mov A, string pointer ;Put location of first character of source string in register A
mov B, string pointer ;Put location of first character of destination string in register B
loop:
mov C, {Link without Title} ;Copy byte at address in register A to register C
mov {Link without Title} ,C ;Copy byte in register C to the address in register B
cmp {Link without Title} ,#0 ;Compare the data we just copied to 0
inc A ;Increment the address in register A to point to the next byte
inc B ;Increment the address in register B to point to the next byte
jnz loop ;If it wasn't 0 then we have more to copy, so go back and copy the next byte
end: ;If we didn't loop then we must have finished, so carry on with something else.

The emulator might be running on a processor which is similar, but extremely good at copying strings, and the emulator knows it can take advantage of this.
It might recognise the string copy sequence of instructions and decide to rewrite them more efficiently just before execution, to speed up the emulation.


Say there is an instruction on our new processor called ''movs'', specifically designed to copy strings efficiently. Our theoretical movs instruction copies 16 bytes at a time, without having to load them into register C in between,
but will stop if it copies a 0 byte (which marks the end of a string) and set the zero flag. It also knows that the addresses of the strings will be in registers A and B, so it increments A and B by 16 every time it executes, ready for the next copy.
Our new recompiled code might look something like this:



beginning:
mov A, string pointer ;Put location of first character of source string in register A
mov B, string pointer ;Put location of first character of destination string in register B
loop:
movs {Link without Title} , {Link without Title} ;Copy 16 bytes at address in register A to address in register B,
then increment A and B by 16
jnz loop ;If the zero flag isn't set then we haven't reached the end of the string,
so go back and copy some more.
end: ;If we didn't loop then we must have finished, so carry on with something else.

There is an immediate speed benefit simply because the processor doesn't have to load so many instructions to do the same task, but also because the movs instruction is likely to be optimised by the processor designer to be more efficient than the sequence used in the first example (for example it may make better use of Parallel Execution in the processor to increment A and B while it is still copying bytes).

In an ironic twist in real world usage, the first sequence of instructions (RISC) is generally preferred over the next (CISC). The reasons provided are slow CISC processor execution, prevention of pipeline stalls, and lower hardware overheads.


PRODUCTS USING DYNAMIC RECOMPILATION



EXTERNAL LINKS