Leopold Toetsch <[EMAIL PROTECTED]> wrote: > 3) Function-like opcodes
> Stat, gmtime, seek, tell, send, poll, recv, gcd, lcm, pack, rand, > split, sleep, and what not are all functions in C or perl and any > other language I know. These are *not* opcodes in any hardware CPU I > know (maybe VAXens have it ;) Mumbling to myself: there is of course another argument, why these opcodes shouldn't be opcodes. It's called JIT. You could of course say, ok, JIT core is an optimization. We have currently: $ perl build_tools/list_unjitted.pl i386 # [1] ... Not jitted: 1316 Jitted: 217 Total ops: 1533 While some of these non-JITted opcodes can and will be done (e.g. the is_<cmp>_i_x_x non-branching compare ops) the vast majority of opcodes will never be JITed. Each function call opcode would need work. It's a PITA. OTOH, when I've a table of builtin functions with function signatures and a methodcall syntax, just that one method call opcode has to be done. That's all. The JIT runcore is only fast for a *sequence* of JITted opcodes. One or two integer operations interrupted by a non-JITted function call don't speedup at all, because the JIT core has first to load CPU registers from Parrot registers and then store CPU register back before the function call. Having so many un-JITtable opcodes prohibits an efficient JIT core. leo [1] this tool should be in tools/dev and it's inaccurate, as ops not included in ops/ops.num aren't listed and JITted vtable functions are missing too, but anyway the magnitude of the counts are ok.
