Pre-Grant Publication Number: 20070130448
Collaborate on the process of community review for this application. Posting will not be forwarded to the USPTO.
Flagging a post as an ACTION ITEM signals further research. Flagging SPAM and ABUSE helps to manage discussion.
Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original
ex. [[claim 1]] and [[prior art 2]].
Please review the Community Code of Conduct prior to posting
Facilitator's Comment 
Action Item Show without Noise
0 days left
So my question is, other than being done at runtime, how is this different from what peephole optimizers have been doing forever?
The online article is a scan, not converted to text, so I'll hand type some snippets...
"Redundant instructions may be discarded during the final stage of compilation by using asimple optimizing technique called peephole optimization. The method is described and examples are given.
...
Example 1. Source code:
x := y;
z = x + z;
Complied Code:
LDA Y -- load the accuulatro from y
STA X -- store the accumulator in X
LDA X -- load the accumulator from X
ADD Z -- add teh contents of Z
STA Z -- store teh accumulator in Z
If the store instruction is nondesctructuve, the third instruction is reduncant and may be discarded.
...
[he descusses a case where the load and store are would not, originally, be adjacent]
but straightforward translation leads to less than optimum code. When teh optimizing code imitter produces a commutative operator (addition, multiplication...) it must first check the preceding instruction, If that instruction was LDA, then the optimizer may chosse, if the instruction preceding the LDA was STA to reorder the commutatitve operation so as to avoid the LDA, as in Example 1. Having avoided the LDA, the optimizer may check to see if the SATA was in fact a store to a temporary location in which case the STA may also be discarded."
And the conclusion:
" These tehcniques have been used in GOGOL , a translator written byt eh authro for the PDP-1 time sharing system at Stanford. The optimizing code emitting routine consistes fo about 400 or the 2000 instructions required for the compiler. We have found that the code emitter can see, throug a very narrow peephole, enough to make considerable improvement in the object code. The limitation on how well the optimizer will work seems to depend primarily on how much time and space are available for recognizing redunant sequences of instructions."