Re: Missing branch instructions?
Pete Lomax <[EMAIL PROTECTED]> wrote: > There is an eq_p_i_ic and an eq_p_ic_ic, but not an eq_i_p_ic or an > eq_ic_p_ic. So, I swapped the operands and it worked, but of course > not on an lt statement, so I switched the operands and inverted the > sense, only to find there are no such equivalents for ne, gt, and ge. Yep, you are right, these are missing. I'll add it. > There are also eq_ic_ic_ic, eq_nc_nc_ic, eq_sc_sc_ic instructions and > similar for ne, lt, le, gt, and ge. Surely those should automatically > be replaced with branch or no_op/omitted, so what are they for? The optimizer handles these (not default for now). They are just products of the automatic argument permutation. > Pete leo
Re: Missing branch instructions?
Pete Lomax <[EMAIL PROTECTED]> wrote: > ... only to find there are no such equivalents for ne, gt, and ge. I've added these missing ops now. *But* there are a lot more missing: * all _p_nc?_ic # := eq, ne, lt, le, gt, ge * all _p_sc?_ic * cmp_i_p_nc? * cmp_i_p_sc? And we don't support Perl's '==' vs 'eq' opcodes. All current ops try to do the right thing, but this is mainly a numeric comparison, except for the obvious _sc?_sc?_ic case. So we probably need more: * _str_p_* * cmp_str_i_p_* * _int_p_* * cmp_int_p_* A Perl compiler will probably emit only the _str or _int variants. The opcode replacement inside imcc can emit an error or warning, if the opcodes have the wrong operands, and can replace the opcodes with the plain variants without _str or _int suffix, if there is no matching opcode. Comments welcome leo
Re: Sorry 'bout the object delay
Dan Sugalski <[EMAIL PROTECTED]> wrote: > I got mugged by the flu, [ ... ] > [ ... ] Objects'll be the death of me, I swear... I don't hope, that this is anyhow related to my checkins, 'cause: "... IS PROVIDED "AS IS" ... IN NO EVENT ... BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING ..." Get well soon, leo
Re: Segfault on Win32, the
Some time ago I mentioned I'd been gettin' one more segfault while the Parrot debug mode was on. In fact, it proved to be an effect of the same cause -- we have global resources sharable among interpreters, that we try to free more than once. This time it's encoding_array. If you're going to disable the encoding_array freeing for now, just make sure you disable the chartype_array one either. 0x4C56
