Paolo Molaro wrote: > 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).
Many thanks for your help. I couldn't find detailed descriptions of the x86 C calling convention, which also talk about this. But as nobody explicitly says you can reuse it, I guess it's undefined and should be avoided. Thanks, Ron
