If memory serves me right, Paolo Molaro wrote:
> If you think you have novel ideas in the JIT (or in the intepreter) space,
> you're probably just deluding yourself.
Oh yes I said that "debuggable JIT" is one of my very own personal
ingienous ideas .
This list for people who are intereste
On 11/16/02 Gopal V wrote:
> > the above was a partial cut&paste with s/mono/parrot/ :-)
>
> But don't act like you invented it Kaffe had one before you thought
> about mono JIT ...
The idea probably predates kaffe, too. Anyway, I didn't say I had the
idea, but the implementation. Quoting w
Paolo Molaro wrote:
On 11/15/02 Gopal V wrote:
It is possible ... JIT generated code looks just like loaded code to
gcc ... Typically gdb should only need access to a symfile to correctly
allow debugging ... So an .o file of the JIT'd code should be correctly
generated with all the trimmings.
If memory serves me right, Paolo Molaro wrote:
> You can find the complete examples of how the jit debugging features
> work in the mono tarball (mono/doc directory):
Same old lupus I never realized I had a wolf pack hunting me :-)
> the above was a partial cut&paste with s/mono/parrot/ :-)
On 11/15/02 Gopal V wrote:
> It is possible ... JIT generated code looks just like loaded code to
> gcc ... Typically gdb should only need access to a symfile to correctly
> allow debugging ... So an .o file of the JIT'd code should be correctly
> generated with all the trimmings.
>
> $ gdb parr
If memory serves me right, Leopold Toetsch wrote:
> pusha/popa is overkill. The called functions always save bp and bx,di,si
> when used. ax is the return value, remaining is dx (cx is used by
> shifts) - i386 of course.
Ok ... push_necessary() ;-) ...
> > Speaking about debugging calls fro
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
Yep, you are right - I did miss this point sometimes. We have to do a
_save_registers before calling code, that might throw an exception.
Excuse me for butting in ... But how are the parameters to a C code being
passed .. I ass
If memory serves me right, Leopold Toetsch wrote:
> Yep, you are right - I did miss this point sometimes. We have to do a
> _save_registers before calling code, that might throw an exception.
Excuse me for butting in ... But how are the parameters to a C code being
passed .. I assume that would u
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 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
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
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
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
> >
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
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
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
22 matches
Mail list logo
