Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
>> When there are no events queued, for any thread, then we change "branch
>> e_handler_foo" back into "branch label_foo", for speed.
> Do we need to do this last bit explicitly? Or can
Nicholas Clark wrote:
On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
Actually, I'm thinking of something like the following... suppose the
original code is like:
label_foo:
loop body
branch_address:
branch label_foo
Add in the following:
e_handler_foo:
.local Perl
On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
> Actually, I'm thinking of something like the following... suppose the
> original code is like:
>
>label_foo:
>loop body
>branch_address:
>branch label_foo
>
> Add in the following:
>
>e_handler_foo:
>.l
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Not "the next instruction" ... the next *branch* instruction. And only
> replace those branch instructions which could be loops.
Works. Many thanks for the input.
I have now running this:
1) Initialization:
- normal core: build op_func_table wi
Sean O'Rourke wrote:
>
> On Thu, 17 Jul 2003, Leopold Toetsch wrote:
> > PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions
> >
> > To be able to switch function tables, this then should become:
> >
> > PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
> >
> > Thus prederefernc
On Thu, Jul 17, 2003 at 09:52:35PM +0200, Leopold Toetsch wrote:
> Remaining is:
> 1) save & fill the byte_code with event handler ops.
> 2) use address relative to op_func_table
> 3) Or the "official" way: do regular checks.
> I estimate 2) to be best for prederefed code.
I'm not sure about this.
Sean O'Rourke wrote:
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
Replacing the next instruction with a branch to the signal handler
(like adding a breakpoint) out of the question?
I don't know, how to get the address of the next instruction i.e. the
"PC" above.
Thinking more of this: There is no
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
> > Replacing the next instruction with a branch to the signal handler
> > (like adding a breakpoint) out of the question?
>
> I don't know, how to get the address of the next instruction i.e. the
> "PC" above. Going this way would either mean:
> - fill t
Sean O'Rourke wrote:
To be able to switch function tables, this then should become:
PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
Or is there a better way to do it?
Replacing the next instruction with a branch to the signal handler
(like adding a breakpoint) out of the question?
I don
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
> PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions
>
> To be able to switch function tables, this then should become:
>
> PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
>
> Thus predereferncing the function pointer would place an of
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> ... Switching the whole op_func_table() or
> ops_addr[] (for CG cores) is simpler,
If have it running now for the slow and the computed goto core.
The signal handler (interrupt code) switches the op_func_table (ops_addr)
and returns.
Then the next execu
Jason Gloudon <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 15, 2003 at 10:15:57AM +0200, Leopold Toetsch wrote:
> How is the described scheme supposed to work with JIT generated code ?
JIT code would be intersparsed with (JITted) CHECK_EVENTS() opcodes.
They would get emitted e.g. at backward branche
On Tue, Jul 15, 2003 at 10:15:57AM +0200, Leopold Toetsch wrote:
How is the described scheme supposed to work with JIT generated code ?
--
Jason
Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> #define DO_OP(PC,INTERP) \
> (PC = ((INTERP->op_func_table)[*PC])(PC,INTERP))
> The easiest way to intercept this flow with minimal cost is to
> have the mechanism that wants to take over replace the interpreter's
> op_func_table with a block of po
Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> Benjamin --
> #define DO_OP(PC,INTERP) \
> (PC = ((INTERP->op_func_table)[*PC])(PC,INTERP))
> The easiest way to intercept this flow with minimal cost is to
> have the mechanism that wants to take over replace the interpreter's
> op_func_table with
Benjamin --
The trick is to find the cheapest possible way to get conditional
processing to occur if and only if there are events in the event
queue.
I'll only be considering the fast core here for simplicity. But,
if you look at include/parrot/interp_guts.h, the only thing of
interest there is t
16 matches
Mail list logo
