Dan Sugalski wrote:
At 12:05 PM +0200 6/22/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
*) Global namespace pointer
We don't so much need a hash of hashes as a linked list of hashes. And
yeah, it'll definitely have a performance impact on global lookups.
Fine. Then we just need to save the lin
At 12:05 PM +0200 6/22/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
*) Global namespace pointer
This would require a new opcode e.g. B to be
useful. Also the global table handling as of pdd06 is missing. This
global table stuff in pdd06 looks like we need a hash of hashes for
the globals. Savi
Dan Sugalski wrote:
At 8:25 PM +0200 6/19/03, Leopold Toetsch wrote:
The primary question is: Why do we save and restore what part of context.
Very good question:
Thanks for the detailed list.
*) System stack
*) User stack and register stacks
*) Lexical pad pointer
Ok, these we already ha
At 8:25 PM +0200 6/19/03, Leopold Toetsch wrote:
The primary question is: Why do we save and restore what part of context.
Very good question:
*) System stack gets saved since we have important info on it.
(Exception handlers when they're done, along with other control
information)
*) User stack
Jonathan Sillito wrote:
-Original Message-
From: Melvin Smith [mailto:[EMAIL PROTECTED]
I tried this, and there was a distinct slowdown on accessing the regs
through the dereference.
However now the registers are no longer in the Parrot_Context struct, so it
may be worth revisiting this .
Dan Sugalski wrote:
Reusing these things should be considered OK, though they couldn't be
reused without being reinitialized after any sort of stack manipulation
on return, since COW will make pointers change.
Thinking some time about this (and looking at the last sub.t [1]), IMHO
best will be
> -Original Message-
> From: Melvin Smith [mailto:[EMAIL PROTECTED]
>
> I tried this, and there was a distinct slowdown on accessing the regs
> through the dereference. Dan and I debated this because I had the same
> idea, but after profiling I proved Dan right. I think it is best
> optimiz
Dan Sugalski wrote:
At 5:07 PM +0200 6/18/03, Leopold Toetsch wrote:
2) performance of CPS sucks
Are you sure? Tell us what you *really* think... :)
Exactly that, what I've outlined. But, when its ok, to generate the
Continuation outside of a possible loop, then its as fast as using the
contro
At 10:23 PM -0400 6/18/03, Melvin Smith wrote:
At 02:34 AM 6/19/2003 +0200, Leopold Toetsch wrote:
Jonathan Sillito wrote:
(3) One other efficiency thought: I wonder if the interpreter's context
could be changed to a pointer to struct Parrot_Context? This would make
accessing the stacks slightly sl
At 5:07 PM +0200 6/18/03, Leopold Toetsch wrote:
[my last 2 f'ups didn't arrive at perl.perl6.internals, so I try again]
The patch is fine with two exceptions:
1) still breaks existing P6C tests WRT exceptions & rules
Yeah, that needs fixing.
2) performance of CPS sucks
Are you sure? Tell us what
At 02:34 AM 6/19/2003 +0200, Leopold Toetsch wrote:
Jonathan Sillito wrote:
(3) One other efficiency thought: I wonder if the interpreter's context
could be changed to a pointer to struct Parrot_Context? This would make
accessing the stacks slightly slower but would of course make restoring the
con
Jonathan Sillito wrote:
-Original Message-
From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
Ok then we need a new opcode:
newsub Px, .Class, jump_or_ret_addr
Sounds fine to me. At one point the following worked:
new Px, .Class, address
Extending the C opcode or doing a new one isn'
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
>
> Jonathan Sillito wrote:
>
> >>-Original Message-
> >>From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
> >>
> >>The patch is fine with two exceptions:
> >>1) still breaks existing P6C tests WRT exceptions & rul
Jonathan Sillito wrote:
-Original Message-
From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
The patch is fine with two exceptions:
1) still breaks existing P6C tests WRT exceptions & rules
You didn't mention this point. It might be only a small change in P6C
code, I didn't look at (4 tes
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
>
> The patch is fine with two exceptions:
> 1) still breaks existing P6C tests WRT exceptions & rules
> 2) performance of CPS sucks
>
> ad 1) I'd like to preserve the old style invoke/ret scheme too. incokecc
> and frie
[my last 2 f'ups didn't arrive at perl.perl6.internals, so I try again]
The patch is fine with two exceptions:
1) still breaks existing P6C tests WRT exceptions & rules
2) performance of CPS sucks
ad 1) I'd like to preserve the old style invoke/ret scheme too. incokecc
and friends could call a new
16 matches
Mail list logo
