On 08/16/07 Ron Blaschke wrote: > > This optimization reaches likely back to times, when the opcode engine was > > designed. It's saving one interpreter push statement [1] per JIT calling > > one > > external function, and I've always thought of it as a very cool (and valid) > > thingy, when I first realized, why the interpreter is the second argument > > in > > opcode functions ;) > > I think it's a really cool idea, too. I'd like to have a way to disable > it, though, to measure its effect, and maybe to "work around" compilers > like VC (at least until a better solution comes around).
The optimization done by the parrot jit is invalid for the x86 C calling convention: the area of memory containing the passed arguments can be used as scratch space by the called function. If you can make sure it's not harmful that way you could still use it when calling parrot's own jitted functions which could use a different calling convention, but it is wrong when interoperating with other code (gcc can generate the same issues, so it's not just VC). lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
