Jeff Clites <[EMAIL PROTECTED]> wrote: > I was getting a failure under JIT on PPC for t/pmc/threads_8.pasm, and > the problem turned out to be that emitting a restart op takes 26 > instructions, or 104 bytes, and we were hitting the grow-the-arena > logic just shy of what would have triggered a resize, then running off > the end.
Duh. It's probably time to generate a JITted restart function. > The below patch fixes this; really that magic number (200, now) needs > to be bigger than the amount of space we'd ever need to emit the JIT > code for a single op (plus saving registers and such), but with the > possibility of dynamically loadable op libs (with JIT?), Not easily. Or it would be not too hard. Given a fairly complete implementation of core.jit, we have a function table (per platform) that has slots for every processor instruction (or almost: Parrot hasn't yet vector opcodes). So a new opcode could be written in terms of existing opcodes, which would easily allow the generation of JITted variants. If a new opcode is too complex, it could be written (partly) in C, which would need just one new JIT opcode call_c_func. And that is exactly what Parrot_jit_build_call_func on i386 is already doing. > ... it's hard to > say what number is guaranteed to be large enough. If we ever have loadable JIT code, will have an interface to set that magic number. Thanks, applied. > JEff leo
