Re: This week's summary
Rhys Weatherley wrote: Have a look at the Portable.NET FAQ, which describes some of the difficulties in targetting stack machines with gcc. http://www.southern-storm.com.au/pnet_faq.html#q4_7 Cheers, Rhys. Yeah...I've read that before. But it doesn't mention the possibility of emulating a more traditional CPU that could be targeted by gcc. -Tupshin
[perl #23005] [PATCH] Parrot_sprintf not recognizing 7 in precision
# New Ticket Created by mrnobo1024 # Please include the string: [perl #23005] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=23005 > Parrot_sprintf isn't recognizing 7 as a number in the precision field, so trying to use that results in a "'7' is not a valid sprintf format" error. __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com -- attachment 1 -- url: http://rt.perl.org/rt2/attach/60977/45050/ad4841/spf.diff --- parrot/spf_render.c.origSat Jun 14 05:40:36 2003 +++ parrot/spf_render.c Tue Jul 15 14:00:26 2003 @@ -426,6 +426,7 @@ case '4': case '5': case '6': +case '7': case '8': case '9': info.flags |= FLAG_PREC;
Re: [perl #23006] FLOATVAL_FMT
Simon Glover (via RT) wrote: # New Ticket Created by Simon Glover # Please include the string: [perl #23006] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=23006 > At the moment, if you build Parrot with long doubles on Linux/x86, then Configure defines FLOATVAL_FMT as: #define FLOATVAL_FMT "%Lf" Unfortunately, Parrot_eprintf etc. don't understand this format - if you try to use it, you get the error message: 'L' is not a valid sprintf format Is this a bug in Configure, or a bug in the printf routines (or neither)? Configure is ok (man sprintf). The attached patch seems to cure the problem. pdb is working then. But the patch isn't complete. I think, we should also have support for "%lld" and friends. PIO_eprintf can fallback to vfprintf(3), when no interpreter is supplied, which means that we should have compatible format chars for basic data types. A src test for these data types would also be fine. Simon leo --- parrot/debug.c Wed Jul 16 06:13:43 2003 +++ parrot-leo/debug.c Wed Jul 16 06:53:37 2003 @@ -1220,7 +1220,7 @@ case PARROT_ARG_NC: /* Convert the float to a string */ f = interpreter->code->const_table->constants[op[j]]->u.number; -Parrot_snprintf(interpreter, buf, sizeof(buf), "%f", (double)f); +Parrot_snprintf(interpreter, buf, sizeof(buf), FLOATVAL_FMT, f); strcpy(&dest[size], buf); size += strlen(buf); break; --- parrot/spf_render.c Wed Jul 16 06:13:43 2003 +++ parrot-leo/spf_render.c Wed Jul 16 06:54:53 2003 @@ -454,6 +454,7 @@ info.type = SIZE_LONG; continue; +case 'L': case 'H': info.type = SIZE_HUGE; continue;
Re: This week's summary
On Wednesday 16 July 2003 09:23 am, Tupshin Harper wrote: > At one point, Tupshin suggested emulating a 'more > >traditional stack-oriented processor' and I don't think he was > > joking... > > Indeed, I wasn't, but I wish somebody would at least have the decency to > tell me how insane this is. ;-) Have a look at the Portable.NET FAQ, which describes some of the difficulties in targetting stack machines with gcc. http://www.southern-storm.com.au/pnet_faq.html#q4_7 Cheers, Rhys.
[perl #23006] FLOATVAL_FMT
# New Ticket Created by Simon Glover # Please include the string: [perl #23006] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=23006 > At the moment, if you build Parrot with long doubles on Linux/x86, then Configure defines FLOATVAL_FMT as: #define FLOATVAL_FMT "%Lf" Unfortunately, Parrot_eprintf etc. don't understand this format - if you try to use it, you get the error message: 'L' is not a valid sprintf format Is this a bug in Configure, or a bug in the printf routines (or neither)? Simon
Re: This week's summary
Piers Cawley wrote: Targeting Parrot from GCC Discussion in the thread entitled 'WxWindows Support / Interfacing Libraries' centred on writing a Parrot backend to GCC. (No, I have no idea what that has to do with the thread subject.) Tupshin Harper, Leo Tötsch and Benjamin Goldberg discussed possibilities and potential pit/pratfalls. At one point, Tupshin suggested emulating a 'more traditional stack-oriented processor' and I don't think he was joking... Indeed, I wasn't, but I wish somebody would at least have the decency to tell me how insane this is. ;-) -Tupshin
Re: ad Timer
Nicholas Clark wrote:
On Tue, Jul 15, 2003 at 04:48:56PM +0200, Leopold Toetsch wrote:
Attached is a test program, showing an implementations for multiple
It didn't arrive. Did you attach it, or did its name end .t ?
No extension was .c. Attachment was there:
$ mailq
-Queue ID- --Size-- Arrival Time -Sender/Recipient---
8CDB611802A 6908 Tue Jul 15 16:48:56 [EMAIL PROTECTED]
(deferred
transport)
[EMAIL PROTECTED]
-- 6 Kbytes in 1 Request.
so it must have been stripped elsewhere.
Anyway - renamed to timer_c.txt
Nicholas Clark
leo
/*
* itimer test
*/
#include
#include
#include
#include
#include
volatile sig_atomic_t got_alarm = 0;
typedef struct timer_t {
int ticks;
int value;
int repeat;
int run;
int nr;
struct timer_t *next;
struct timer_t *prev;
} timer;
timer *rtimer = 0;
void add_timer(timer *t) {
timer *next = rtimer;
rtimer = t;
t->next = next;
if (next) {
t->nr = next->nr + 1;
next->prev = t;
}
else
t->nr = 1;
}
void del_timer(timer *t) {
timer *next = t->next;
timer *prev = t->prev;
if (prev)
prev->next = next;
else
rtimer = next;
if (next)
next->prev = prev;
free(t);
}
timer * new_timer(void) {
timer *t = calloc(1, sizeof(timer));
add_timer(t);
return t;
}
typedef unsigned int UINTVAL;
typedef double FLOATVAL;
UINTVAL gcd(UINTVAL a, UINTVAL b) {
UINTVAL q = 0;
UINTVAL c = 0;
while (b != 0) {
q = (UINTVAL)floor( (FLOATVAL)a/b );
c = a - b*q;
a = b;
b = c;
}
return a;
}
void
sig_alarm_handler(int i) {
got_alarm = 1;
}
/* platform interface */
void start_sys_timer_ms(void *handle, int ms) {
struct itimerval its;
memset(&its, 0, sizeof(its));
if (ms) {
its.it_interval.tv_sec = its.it_value.tv_sec = ms/1000;
its.it_interval.tv_usec = its.it_value.tv_usec = 1000 *(ms%1000);
}
setitimer(ITIMER_REAL, &its, NULL);
printf("new val = %ld:%ld ms = %d\n",
its.it_value.tv_sec, its.it_value.tv_usec, ms);
}
void stop_sys_timer_ms(void *handle) {
start_sys_timer_ms(handle, 0);
}
int get_sys_timer_ms(void *handle) {
struct itimerval ots;
getitimer(ITIMER_REAL, &ots);
return ots.it_interval.tv_sec * 1000 + ots.it_interval.tv_usec/1000;
}
void * new_sys_timer_ms() {return 0; }
/* end platform interface */
void recalc_ticks(void);
void *handle;
void
do_alarm_handler() {
timer *t;
UINTVAL ms;
int recalc = 0;
ms = get_sys_timer_ms(handle);
for (t = rtimer; t; t= t->next) {
if (!--t->ticks) {
t->run = 1;
if (t->repeat) {
t->ticks = t->value/ms;
if (t->repeat != -1)
t->repeat--;
}
}
}
again:
for (t = rtimer; t; t= t->next) {
if (t->run == 1) {
t->run = 0;
printf("alarm %d\n", t->nr);
/* code run here may add timers, these have t->run = 2 */
goto again;
}
if (!t->ticks && !t->repeat) {
printf("del_timer %d\n", t->nr);
del_timer(t);
recalc = 1;
goto again;
}
}
if (recalc)
recalc_ticks();
}
void p_add_timer(UINTVAL msecs, int repeat)
{
timer *t;
if (!msecs)
return;
t = new_timer();
t->repeat = repeat;
t->value = msecs;
t->run = 2;
recalc_ticks();
}
void p_del_timer(timer *t) {
del_timer(t);
recalc_ticks();
}
void recalc_ticks() {
UINTVAL ms, oms;
timer *t;
oms = get_sys_timer_ms(handle);
printf("gettimer oms = %d\n", oms);
t = rtimer;
if (t) {
t->run = 0;
if (oms && t->ticks)
ms = oms*t->ticks; /* time left */
else
ms = t->value;
if (t->next) {
for (t = t->next; t; t = t->next) {
t->run = 0;
if (oms && t->ticks) {
ms = gcd(oms*t->ticks, ms);
}
else
ms = gcd(t->value, ms);
}
}
printf("new ms %d\n", ms);
again:
for (t = rtimer; t; t= t->next) {
int ot = t->ticks;
printf("t%d oticks %d => ", t->nr, t->ticks);
if (oms && ot)
t->ticks = t->ticks * ((double)oms / (double)ms);
else
t->ticks = t->value / ms;
if (!t->ticks) {
ms = oms;
t->ticks = ot;
goto again;
}
printf("ticks %d value %d\n", t->ticks, t->value);
}
}
else
ms = 0;
if (ms)
start_sys_timer_ms(handle, ms);
else
stop_sys_timer_ms(handle);
}
int main(int argc, char **argv) {
handle = new_sys_timer_ms();
signa
Re: ad Timer
On Tue, Jul 15, 2003 at 04:48:56PM +0200, Leopold Toetsch wrote: > Attached is a test program, showing an implementations for multiple It didn't arrive. Did you attach it, or did its name end .t ? Nicholas Clark
Re: OT: Will the State of the Onion be posted online?
> Really? I can't find anything about TPC7 in this page.. Sorry, had to take it down. It'll be back up in a few days.
This week's summary
Perl 6 Summary for the week ending 20030713 Welcome once again to the Perl 6 Summary, in a week of major developments and tantalizing hints. Starting, as usual, with what's happening in perl6-internals Targeting Parrot from GCC Discussion in the thread entitled 'WxWindows Support / Interfacing Libraries' centred on writing a Parrot backend to GCC. (No, I have no idea what that has to do with the thread subject.) Tupshin Harper, Leo Tötsch and Benjamin Goldberg discussed possibilities and potential pit/pratfalls. At one point, Tupshin suggested emulating a 'more traditional stack-oriented processor' and I don't think he was joking... http://xrl.us/l6b Timely destruction and "TRACE_SYSTEM_AREAS" Jürgen Bömmels' rewrite of Parrot IO is causing some problems with the garbage collection (IO handles are the canonical examples of resources that need timely destruction). Leo tracked down the source of resource leak to a problem with handles being found on the C stack. Jürgen wasn't happy about this (he's not keen on the stack walking approach to garbage collection). He proposed that we get rid of the stack walk in favour of some other solution to the infant mortality problem and offered a few candidates. Leo said that he didn't like walking the C stack, going so far as to state that "Timely destruction and solving infant mortality don't play together or are mutually exclusive - in the current approach." Dan hasn't commented on this yet. http://xrl.us/l6c Parrot is not feature frozen There was a certain amount of confusion as some old email with the subject 'Parrot is feature-frozen until Wednesday' made its way into a small number of inboxes sowing confusion as it went. Suffice to say, Parrot is not currently feature frozen, though Steve Fink did say that he was considering a point release once the imcc/parrot integration was complete. If Dan gets objects and exceptions finished, then it might even warrant a 0.1.0 version number rather than 0.0.11 http://xrl.us/l6d Perl* Abstraction Luke Palmer has "finally" started to implement his Infinity PMC and has noticed a lot of redundant code in the Perl* classes. He also noticed that Parrot doesn't seem to have the distinction between container and value that has been confusing people on the language list. http://xrl.us/l6e Fun with ParrotIO First, Jürgen Bömmels sent in a patch to excise integer file descriptors from Parrot except when they are managed via ParrotIO PMCs. Leo applied this. Clinton Pierce thought that this patch meant that a Win32 bug could be closed in the Parrot bug database. This sparked a discussion with Leo, and Jürgen, but I'm not entirely sure of the status of the bug... http://xrl.us/l6f http://xrl.us/l6g Jako groks basic PMCs Gregor N Purdy seems to have started working on Jako again, and checked in some changes allowing Jako to manipulate PMCs. People agreed that this was cool. http://xrl.us/l6h I want a Ponie! The [EMAIL PROTECTED] mailing list was announced and I'll be summarizing it as of next week when I've joined, caught up, and generally recovered from America. What's Ponie? Ponie is 'Perl On New Internal Architecture' or, as Thomas Klausner put it, "A version of Perl 5 that will run on Parrot", which was announced by Larry at his OSCON 'State of the Onion' address. Discussion of Ponie on the perl6-internals list centred on the "What is ponie?" question, with a certain amount of "Why ponie-dev, not perl6-ponie?" thrown in for good measure. Brian Ingerson announced that he'd set up a Ponie Wiki, Leon Brocard pointed at the use.perl story announcing Ponie, and your summarizer punted on writing a description of the project himself. http://xrl.us/l6i http://www.poniecode.org/ -- More on Ponie http://ponie.kwiki.org/ -- Ingy's Ponie Wiki http://xrl.us/lib -- use.perl announcement Exceptions! Leo Tötsch checked in the beginnings of an exceptions system. Then he checked in the beginnings of an events system. http://xrl.us/l6j http://xrl.us/l6k Meanwhile, in perl6-language There were all of 6 messages, all of them discussing the effects of aliasing an array slice. http://xrl.us/l6l Perl 6 Rules at OSCON No, wait, that should be Perl6::Rules. For his last talk at OSCON, Damian spoke about Perl6::Rules, his implementation of Perl 6's rules system in pure Perl 5. And oh boy was it tantalizing. He showed us something actually running a large chunk of Perl 6 matching semantics, complete with handy debugging information, diagnostic dumping and all the other useful stuff. When we were all gagging for him to release it to CPAN immediately, he told us that it wasn't finished yet; that he'd impleme
ad Timer
Attached is a test program, showing an implementations for multiple timers. GNU/linux only, but implementing the platform interface (and the sighandler/message queue) shouldn't be too hard. I'm using milli seconds resolution, which seems IMHO reasonable. The Kernel only has HZ (1s/100 on many systems). Perl/Tk has it too. Comments welcome, leo
Re: [perl #22998] [PATCH] minor pod nit in core_ops.pod
On Tue, 15 Jul 2003, Will Coleda wrote: > # New Ticket Created by Will Coleda > # Please include the string: [perl #22998] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=22998 > > > Supresses a perldoc warning on core_ops.pod > Thanks, applied. Simon
[perl #22998] [PATCH] minor pod nit in core_ops.pod
# New Ticket Created by Will Coleda # Please include the string: [perl #22998] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=22998 > Supresses a perldoc warning on core_ops.pod -- attachment 1 -- url: http://rt.perl.org/rt2/attach/60943/45025/a0561b/the.patch the.patch Description: the.patch -- Will "Coke" Coledawill at coleda dot com
Re: Event handling
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 branches like proposed by Benjamin. leo
Re: newsub imcc compilation issue.
Will Coleda <[EMAIL PROTECTED]> wrote:
> But, why did it compile one way and not the other? And why would the
> program with the subs switched print out whee indefinitely? I would
> expect it to print whee once, then create a sub object, then die.
It did compile, because the label was known.
And:
$ parrot -t t.imc
PC=0; OP=960 (print_sc); ARGS=("whee\n")
whee
PC=2; OP=225 (newsub_p_ic_ic); ARGS=(P0, 31, -2)
PC=6; OP=
Error: Control left bounds of byte-code block (now at location 6)!
So it just depends, what you happened to have at that memory location.
Could have been a branch opcode starting again at PC=0.
leo
Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)
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
Re: newsub imcc compilation issue.
On Tuesday, Jul 15, 2003, at 06:36 America/New_York, Leopold Toetsch wrote: Will Coleda <[EMAIL PROTECTED]> wrote: Given the following example: % cat test.imc .sub _MAIN .local sub command_sub newsub command_sub, .Sub, __cmd_puts .end .sub __cmd_puts print "whee\n" .end %../../../parrot -o test.pbc test.imc error:imcc:store_labels: inter_cs label '__cmd_puts' not found make: *** [test.pbc] Error 1 I presume I'm missing something obvious? Yep, a thread started by Luke Palmer a minute ago ;-) No kidding. How annoyed was I to have sent the message *5 hours* before it showed up on the list, only to come back and find that someone else had started the same thread between the time I sent the message and the time it arrived. ^_^ On the other hand, how odd that both of us would have pretty much the same problem at the pretty much the same time. And: .sub _MAIN .local Sub command_sub $P0 = new PerlString $P0 ="back\n" $P1 = new PerlString $P1 ="again\n" newsub command_sub, .Sub, __cmd_puts invokecc command_sub # $P0 = P1 is globbered above print $P0 print $P1 end .end .sub __cmd_puts print "whee\n" invoke P1 .end This seems to work (mostly) after your fix: % ../../../parrot leo.imc whee get_string() not implemented in class 'Continuation' imcc doesn't currently know about calling convetions and side effects of e.g. invokecc. (Please also note the "Sub" in .local and the "end" op) My previous example works fine after your fix. (without changing either of these issues. the case of the pmc name doesn't appear to matter. and, yes, it prints "whee" once as the cmd_puts sub is compiled, but the lack of compilation was my main problem =-) Apparently in my desire to generate the shortest test case possible, I erred on the side of obfuscation. =-) Please ignore my other response, since your recent patch makes it moot. In any case, thanks for the quick turnaround. Now I can actually hack on tcl a bit during my lunch today! =-) (And man, am I not looking forward to your code review when I release that puppy. =-) Regards. -- Will "Coke" Coledawill at coleda dot com
Re: OT: Will the State of the Onion be posted online?
Monday 14 July 2003 05:56, Robert Spier wrote: > > Sorry for a slightly off-topic post, but will Larry's State of > > the Onion be posted online soon? > > Yes. > > http://dev.perl.org/perl6/talks/ > > -R Really? I can't find anything about TPC7 in this page.. -angel
Re: newsub imcc compilation issue.
On Tuesday, Jul 15, 2003, at 06:38 America/New_York, Leopold Toetsch wrote: Will Coleda <[EMAIL PROTECTED]> wrote: Hurm. I tried switching the order of the .subs, which allows it to compile, Execution doesn't start in _main or something. It starts at the first fully parsed .sub. leo Sorry if I gave the impression that I thought it did. I tried it because I thought having the other sub compiled first might give IMCC enough information to deal with the newsub. On Tuesday, Jul 15, 2003, at 01:14 America/New_York, Will Coleda wrote: Hurm. I tried switching the order of the .subs, which allows it to compile, but then running it seems to print "whee" forever. This doesn't seem right. I'd have expected this program to not actually output anything - I just create the .Sub, not invoke it... But, why did it compile one way and not the other? And why would the program with the subs switched print out whee indefinitely? I would expect it to print whee once, then create a sub object, then die. -- Will "Coke" Coledawill at coleda dot com
Re: newsub imcc compilation issue.
Will Coleda <[EMAIL PROTECTED]> wrote: > Hurm. I tried switching the order of the .subs, which allows it to > compile, Execution doesn't start in _main or something. It starts at the first fully parsed .sub. leo
Re: newsub imcc compilation issue.
Will Coleda <[EMAIL PROTECTED]> wrote: > Given the following example: > % cat test.imc > .sub _MAIN >.local sub command_sub >newsub command_sub, .Sub, __cmd_puts > .end > .sub __cmd_puts >print "whee\n" > .end > %../../../parrot -o test.pbc test.imc > error:imcc:store_labels: inter_cs label '__cmd_puts' not found > make: *** [test.pbc] Error 1 > I presume I'm missing something obvious? Yep, a thread started by Luke Palmer a minute ago ;-) And: .sub _MAIN .local Sub command_sub $P0 = new PerlString $P0 ="back\n" $P1 = new PerlString $P1 ="again\n" newsub command_sub, .Sub, __cmd_puts invokecc command_sub # $P0 = P1 is globbered above print $P0 print $P1 end .end .sub __cmd_puts print "whee\n" invoke P1 .end imcc doesn't currently know about calling convetions and side effects of e.g. invokecc. (Please also note the "Sub" in .local and the "end" op) leo
Re: IMCC bug: Sub names are not labels?
Luke Palmer <[EMAIL PROTECTED]> wrote: > The following doesn't work: [ snip ] > Indeed, it can be done by using C and C, but shouldn't sub > names be considered global labels, too? Of course. But newsub and the whole calling convention stuff isn't finished yet. Meaning the newsub opcode doesn't work yet in PIR code, global fixup is missing ... > Luke leo
Re: IMCC bug: Sub names are not labels?
Luke Palmer <[EMAIL PROTECTED]> wrote: [ bug ] I've fixed it somehow - still calling conventions stuff is missing. (the register allocator will happily globber the return continuation in the sub if not written explictely as P1). This works now: .sub _main newsub P0, .Sub, _foo # note the dot invokecc P0 end .end .sub _foo print "foo\n" invoke P1 .end > Luke leo
Re: newsub imcc compilation issue.
Hurm. I tried switching the order of the .subs, which allows it to compile, but then running it seems to print "whee" forever. This doesn't seem right. I'd have expected this program to not actually output anything - I just create the .Sub, not invoke it... On Tuesday, Jul 15, 2003, at 00:54 America/New_York, Will Coleda wrote: Given the following example: % cat test.imc .sub _MAIN .local sub command_sub newsub command_sub, .Sub, __cmd_puts .end .sub __cmd_puts print "whee\n" .end %../../../parrot -o test.pbc test.imc error:imcc:store_labels: inter_cs label '__cmd_puts' not found make: *** [test.pbc] Error 1 I presume I'm missing something obvious? -- Will "Coke" Coledawill at coleda dot com -- Will "Coke" Coledawill at coleda dot com
newsub imcc compilation issue.
Given the following example: % cat test.imc .sub _MAIN .local sub command_sub newsub command_sub, .Sub, __cmd_puts .end .sub __cmd_puts print "whee\n" .end %../../../parrot -o test.pbc test.imc error:imcc:store_labels: inter_cs label '__cmd_puts' not found make: *** [test.pbc] Error 1 I presume I'm missing something obvious? -- Will "Coke" Coledawill at coleda dot com
[CVS ci] event handling-1: some opcodes
The plan is to follow Gregors idea to swap op_func_table/op_addr array, if events got enqueued. The internal check_events__ will get filled into a second op_func_table which will then take over. There are still some questions: - How does the actual event structure look like? - Is this a QUEUE_ENTRY? - And when yes, how to construct an entry in a sig_handler? - Malloc seems to be dangerous there. leo
IMCC bug: Sub names are not labels?
The following doesn't work: .sub _main newsub $P0, Sub, _foo invokecc $P0 end .end .sub _foo # ... .end Indeed, it can be done by using C and C, but shouldn't sub names be considered global labels, too? Luke
Re: OT: Will the State of the Onion be posted online?
Robert Spier wrote: >> Sorry for a slightly off-topic post, but will Larry's State of the Onion >> be posted online soon? > > Yes. sorry to reiterate the argument, but will also a text transcript of the talk be posted online? the slides are beautiful, but without a few words of explanation they are "scary" at least :-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)
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 to some Parrot_hijack() > function that conforms to the opfunc prototype. Enqueueing an > event would set the appropriate interpreter's op_func_table to > hijack_op_func_table. Thinking more about this: Switching the whole op_func_table() or ops_addr[] (for CG cores) is simpler, then e.g. replacing backward branch ops. Only the switched core doesn't play nicely here. Having neither a op_func_table nor an ops_addr[], it would need an explicit CHECK_EVENTS() in the loop. Now I have done a very similar thing some time ago: Subject: [RfC] a scheme for core.ops extending Date: Wed, 05 Feb 2003 12:28:21 +0100 On the enqueueing of an event, the op_lib is told to switch the jump_table/ops_addr via a special op_lib->init call. (If the event check func_table doesn't exist yet, its constructed on the fly, by filling the check_event opcode into the func_table. The check_event opcode now restores the func_table/ops_addr, saves the context (generates a return continuation) and branches to the event handler (if any) or handles the event internally. Then it executes the same opcode again, like its done in the prederef function, which resumes normal opcode flow. leo
Re: [CVS ci] interpreter->iglobals: a list of some interpreter internal PMCs
Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 12:31 PM +0200 7/14/03, Leopold Toetsch wrote: >>I have moved some interpreter variables (classname_hash, >>compreg_hash, Argv, Env) into one (SArray) list: >>interpreter->iglobals. >>There access isn't time critical, so the extra indirection wont harm. > This is fine, though many of those things should actually be global > globals rather than interpreter globals, but that's a separate issue. Yep. I think new interpreters should just use the iglobal pointer of the previous interpreter (or pointers to items, depending on what is global). This would need the old interpreter as parameter, when constructing a new one in make_interpreter(). leo
