Next: Register Machines, Previous: Superinstructions, Up: Input File Format [Contents][Index]
This minor optimization (0.6%–0.8% reduction in executed instructions for Gforth) puts additional requirements on the instruction descriptions and is therefore disabled by default.
What does it do? Consider an instruction like
dup ( n -- n n )
For simplicity, also assume that we are not caching the top-of-stack in a
register. Now, the C code for dup first loads n
from the stack, and
then stores it twice to the stack, one time to the address where it came
from; that time is unnecessary, but gcc does not optimize it away, so vmgen
can do it instead (if you turn on the store optimization).
Vmgen uses the stack item’s name to determine if the stack item contains the same value as it did at the start. Therefore, if you use the store optimization, you have to ensure that stack items that have the same name on input and output also have the same value, and are not changed in the C code you supply. I.e., the following code could fail if you turn on the store optimization:
add1 ( n -- n ) n++;
Instead, you have to use different names, i.e.:
add1 ( n1 -- n2 ) n2=n1+1;
Similarly, the store optimization assumes that the stack pointer is only changed by Vmgen-erated code. If your C code changes the stack pointer, use different names in input and output stack items to avoid a (probably wrong) store optimization, or turn the store optimization off for this VM instruction.
To turn on the store optimization, write
\E store-optimization on
at the start of the file. You can turn this optimization on or off between any two VM instruction descriptions. For turning it off again, you can use
\E store-optimization off
Next: Register Machines, Previous: Superinstructions, Up: Input File Format [Contents][Index]