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
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
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
Leopold Toetsch wrote:
[snip]
> - When will we check, it there are events in the event queue?
If we check too often (between each two ops), it will slow things down.
If we don't check often enough, the code might manage to avoid checking
for events entirely.
I would suggest that every flow contr
More fun to play with.
This is t/op/hacks_5.pasm:
newsub P0, .Exception_Handler, _handler
set_eh P0
div I10, 0
print "not reached\n"
end
_handler:
.include "signal.pasm"
print "catched it\n"
set I0, P5["_type"]
neg I0, I0
ne I0, .SIGFPE, nok
print "ok\n"
nok
16 matches
Mail list logo
