Thomas Seiler <[EMAIL PROTECTED]> wrote:
Dan Sugalski wrote:
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
[...]
Then there are changes that need more thought: * replacing *_i_n with *_n_n uses a N-register and might put stress on the register allocator in case of heavy "floating" code. Doing these now smells in fact a bit like premature optimisation...
No, because it introduces exactly one reusable temporary. The mixed _n_i variants were almost all not supported by the JIT core. A mapped INT register had first to store the INT back into the Parrot register before the float can be used.
You are right about execution time of the two ops compared to the old op, but I think the one reusable temporary can cause N-register spilling, an that can hurt performance. On the other hand, those ops might not be *that* frequent.
This will need some real life (PDL?) code to benchmark with, IMHO.
Another change that need more thought: * (is)?g[t,e] N, P variants are *not* redundant think of NaN's, custom vtables,... order is important there, I have a feeling like replacing gt with lt might influence the program flow in some egde cases.
tom
