On Aug 4, 2007, at 5:28 AM, Paul Cochrane wrote:
On 03/08/07, via RT Joshua Isom <[EMAIL PROTECTED]>
wrote:
# New Ticket Created by Joshua Isom
# Please include the string: [perl #44391]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44391 >
After a fair amount of headaches, I finally discovered some of my
trouble with my jit. It seems as though r19820 changed the API for
preserving and restoring parrot's registers to cpu registers. The
cause was to convert internal_exceptions(fatal) to
real_exceptions(maybe fatal), and since internal_exceptions need
interp, interp gets passed around. Only i386 was fixed to handle the
API change, and PPC's broken. In this case, real_exception could be
appropriate to prevent executing bad/incomplete machine code that
would
crash parrot. If you look at the exceptions used, in i386's
jit_emit.h, it's more a bad jit_emit.h than anything caused by a user.
Since I was unable to test the internal_exception() to
real_exception() change on anything other than i386, I didn't update
the jit_emit.h headers for other architectures in the repository. I'm
sorry that this has caused headaches. I did make a mention of the
fact that I couldn't update all architectures in RT#40392 which I'm
pretty sure made it to the list. Is there anything I can do to help
out?
Paul
Part of my what I was thinking was that many of those
internal_exceptions should probably stay internal_exceptions because it
means one of the macros or subs was used incorrectly and tried to
generate invalid code. The way I see it, internal_exceptions should
never be generated from PIR code, and most likely indicate improper
usage of some part of parrot, and real_exceptions can be generated from
PIR code and may wish to be caught.
