Jason Gloudon wrote:
If the JIT allocates any parrot register contents to callee-save registers
(which we use strictly as such), and calls an external function that raises an
exception, you cannot restore the contents of those registers to Parrot
registers after the external function raises an e
On Nov-08, Leopold Toetsch wrote:
> Andy Dougherty (via RT) wrote:
>
> ># New Ticket Created by Andy Dougherty
> ># Please include the string: [perl #18189]
> ># in the subject line of all future correspondence about this issue.
> ># http://rt.perl.org/rt2/Ticket/Display.html?id=18189 >
> >
>
On Nov-01, Andy Dougherty wrote:
> # New Ticket Created by Andy Dougherty
> # Please include the string: [perl #18189]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=18189 >
>
>
> Not OK: This is a failure report for pa
Applied, finally. Thanks.
I replied to ticket #16941 a while back but I don't think I had RT
actually send any mail to anybody. Anyone have an opinion on the patch
I put in it? (I'm trying to clean out some local changes so I can
apply other people's patches more easily.)
Thanks.
http://bugs6.perl.org/rt2/Ticket/Display.h
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
> The question is "without knowing". I think the resume address is known
> (somewhere at least) because the exception handler has to be set up.
If I understand it correctly, the way recent Linux handles page faulting in
the kernel
On Thu, Nov 14, 2002 at 05:55:21PM +0100, Leopold Toetsch wrote:
> But above is only needed, if there are callee saved registers around
> which hold parrot register values not already saved. So currently not,
> because there are no unsaved registers, when calling external code and
> jitted OPs
Jason Gloudon wrote:
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
I didn't finish my response...
The way I have thought this would be done (given C opcode functions raising
exceptions) is to spill parrot registers back into the interpreter structure
from hardware registers
> -Original Message-
> From: Dan Sugalski [mailto:dan@;sidhe.org]
>
> At 2:07 PM + 11/14/02, "Jürgen" "Bömmels" (via RT) wrote:
> >This patch obsoletes #17109 (which isn't applied yet).
>
> Does it obsolete 18170?
No, it seems to depend on it.
> -Original Message-
> From: Jürg
Jason Gloudon wrote:
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
But I have a proposal:
- Normal runloops don't have a problem with longjmp
- JIT could have it's own low level exception handler:
What happens when C code called from the JIT generated code generates an
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
> - JIT could have it's own low level exception handler:
> * gets jumped to, so registers are still ok
> * saves processor registers to parrots
> * then longjmps to parrot handler
I didn't finish my response...
The way I have thoug
At 2:07 PM + 11/14/02, "Jürgen" "Bömmels" (via RT) wrote:
This patch obsoletes #17109 (which isn't applied yet).
Does it obsolete 18170?
--
Dan
--"it's like this"---
Dan Sugalski
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
> But I have a proposal:
>
> - Normal runloops don't have a problem with longjmp
>
> - JIT could have it's own low level exception handler:
What happens when C code called from the JIT generated code generates an
exception ?
> *
On Thu, Nov 14, 2002 at 04:28:00PM +0100, Leopold Toetsch wrote:
> - Normal runloops don't have a problem with longjmp
>
> - JIT could have it's own low level exception handler:
> * gets jumped to, so registers are still ok
I am not clear how this works if the exception is triggered in a C funct
At 3:09 PM +0530 11/14/02, Gopal V wrote:
If the Parrot team can provide a current and working perl6c.pbc for the
compiler written in perl6 , it's cool with me ... But I've seen that idea
fail quite a few times when the published binary falls out of sync with
the runtime ... Well that's just anoth
Nicholas Clark wrote:
On Thu, Nov 14, 2002 at 11:23:04AM -0300, Daniel Grunblatt wrote:
Can any opcode be a resume target without knowing that it is a resume target?
If yes, we have a nasty time being a JIT.
The question is "without knowing". I think the resume address is known
(somewhere
On Thu, Nov 14, 2002 at 11:23:04AM -0300, Daniel Grunblatt wrote:
> On Thursday 14 November 2002 10:32, Leopold Toetsch wrote:
> > Daniel Grunblatt wrote:
> > > On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
> > >>What JIT needs to know is the location of the resume opcode, to mark it
>
On Thursday 14 November 2002 10:32, Leopold Toetsch wrote:
> Daniel Grunblatt wrote:
> > On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
> >>What JIT needs to know is the location of the resume opcode, to mark it
> >>as a jump target properly, so that processor registers can be setup
> >
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18379]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18379 >
Hello,
I used Jonathan Sillito's patch [#18170] to implement functions in
scheme. It
Daniel Grunblatt wrote:
On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
What JIT needs to know is the location of the resume opcode, to mark it
as a jump target properly, so that processor registers can be setup
correctly.
Well, any opcode could be a target, so I suggest to buil
--- sub.c.orig
+++ sub.c Thu Nov 7 23:15:06 2002
@@ -139,7 +139,13 @@
PMC * pad_pmc = pmc_new(interp, enum_class_Scratchpad);
pad_pmc->cache.int_val = 0;
-if ((base && depth > base->cache.int_val) || (!base && depth != 0)) {
+if (base && depth < 0) {
+depth = base->cach
Jonathan Sillito <[EMAIL PROTECTED]> writes:
> On 2 Nov 2002, Juergen Boemmels wrote:
>
> > Ok, I tested the patch (I tried to use this scratchpads for the scheme
> > compiler)
> > One thing I missed (or at least didn't find): How can I generate a new
> > scope? new_pad generates a new one one th
On Thursday 14 November 2002 05:14, Leopold Toetsch wrote:
> Dan Sugalski wrote:
> > I'm about to do exceptions, and as such I wanted to give a quick warning
> > to everyone who does Odd Things. (Which would be in the JIT, mainly :)
> >
> > Because of the way exceptions are going to work, we need t
On Thu, Nov 14, 2002 at 03:09:54PM +0530, Gopal V wrote:
> Also perl6c.pbc shouldn't really worry about trojaned stuff in it as you're
> not using an external bootstrapper (unlike gcc using cc)
I don't think you're totally correct. You are still relying on an external
bootstrapper, although it
If memory serves me right, Nicholas Clark wrote:
> I believe that it can be done with just a C compiler. (no make tool or shell
> needed). If we use an equipped machine to unroll the makefile into the correct
> steps (in the correct order), and turn that into C code that runs each in
> turn, then w
Dan Sugalski wrote:
I'm about to do exceptions, and as such I wanted to give a quick warning
to everyone who does Odd Things. (Which would be in the JIT, mainly :)
Because of the way exceptions are going to work, we need to make sure
that the code emitted for each individual opcode is self-con
26 matches
Mail list logo
