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". >>> > >> [...] > >> >> Could you undo this please? Now is not the time to be trimming ops out.
When is the time? After another 1000 opcodes are in, which all ought to be functions? > OTOH, it won't hurt anyone and it is already in. That's my point. Minus 226 opcodes and all works (modulo the 3 documented incompatible changes like the lcm cruft) > So why bother, unless of course there is a technical reason... > In any case, there is some stuff worth keeping, IMHO: > * (is)?l[t,e]_i_i_i and (is)?g[t,e]_i_i_i *are* redundant > * rand* should not be ops > * lcm_n_i_i doesnt make any sense as the result is an integer > * constant folding (no need for opvariants with two constant args) > now is as good as ever for those Yep, thanks for the summary. > 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. > So I would like to propose salami-tactic and try to find the offending > slices (the ones with the pepper) instead of rejecting the whole salami. > just my 2 cents though > tom leo
