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 we do it
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
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
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 with
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 executed
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 offset
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
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 the
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
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 pointers
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:
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 a block
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
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
14 matches
Mail list logo
