I've been trying to make sense of the current status of keyed access
at all levels, from the assembler through the ops to the vtables and
it has to be said that the harder I look the more confused I seem to
become...
It all seems to be a bit of a mess at the moment, and I'd like to have
a go at c
At 03:54 PM 7/14/2002 +0100, Tom Hughes wrote:
>I've been trying to make sense of the current status of keyed access
>at all levels, from the assembler through the ops to the vtables and
>it has to be said that the harder I look the more confused I seem to
>become...
I think we all have...
FWIW,
In message <[EMAIL PROTECTED]>
Melvin Smith <[EMAIL PROTECTED]> wrote:
> At 03:54 PM 7/14/2002 +0100, Tom Hughes wrote:
> >I've been trying to make sense of the current status of keyed access
> >at all levels, from the assembler through the ops to the vtables and
> >it has to be said th
Dan,
As it stands, KEY * is a win when:
1) All of the array indices are constants and hardcoded into the instruction
stream
2) The PMC handling the index does not have to recurse.
In all other cases, as it currently stands, it is a loose. I hate to come out
and be so blunt, but I thin
On Sunday 21 July 2002 06:46 pm, Scott Walters wrote:
> 2. PMCs return iterators allocated on a stack that allow them to function
> as KEY *s allocating a single fixed size peice of memory rather than all of
> the parts of a linked list. In other words, factor out the part of PMCs
> that index a g
At 11:46 AM -0700 7/21/02, Scott Walters wrote:
>In all other cases, as it currently stands, it is a loose. I hate to come out
>and be so blunt, but I think this is the culmination of what I've found, and a
>lot of people are saying. This approach is penny wise, pound foolish.
Being blunt since I
At 5:44 PM +0100 7/21/02, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Mike Lambert <[EMAIL PROTECTED]> wrote:
>
>> Does anyone who is more familiar with the keyed stuff than I am, want to
>> write two parrot examples, one that uses three-level keys, and one that
>> dereference
Ashley Winters sent the following bits through the ether:
> Err, is this a bad time to ask where ParrotTuple is? :)
I think ParrotTuple would make a great first project for anyone who
wants to learn more about PMCs. It will also be fairly simple and
small, so if lots of docs were also included i
Leon Brocard wrote:
> I think ParrotTuple would make a great first project for anyone
> who wants to learn more about PMCs. It will also be fairly simple
> and small, so if lots of docs were also included it would make
> an ideal PMC to learn from in future. Any takers? ;-)
me, time permitting :-
--- Leon Brocard <[EMAIL PROTECTED]> wrote:
> Ashley Winters sent the following bits through the
> ether:
>
> > Err, is this a bad time to ask where ParrotTuple
> is? :)
>
> I think ParrotTuple would make a great first project
> for anyone who wants to learn more about PMCs.
>Any takers? ;-)
At 10:26 AM -0700 7/21/02, Scott Walters wrote:
>It is pretty clear that no one is happy with the keyed system. It
>doesn't do what people want (eg, let you use arrays as keys).
>While keys are supposed to be fast, constructing them takes a series
>of instructions.
>
>Perspective:
>
>Keys are not
At 7:06 PM +0100 7/21/02, Tom Hughes wrote:
>In message <20020721174150$[EMAIL PROTECTED]>
> Scott Walters <[EMAIL PROTECTED]> wrote:
>
>> I propose that keyed access do exactly eight things:
>>
>> * fetch a PMC using a key
>> * fetch a integer using a key
>> * fetch a number using a
Dan,
Thanks for being a good sport. I'm not in a hurry here - don't feel like you
need to be.
> >> I propose that keyed access do exactly eight things:
> >>
> >> * fetch a PMC using a key
> >> * fetch a integer using a key
> >> * fetch a number using a key
> >> * fetch a string using a k
Sunday 21 July 2002 21:34, Dan Sugalski wrote:
>
> No. They are not. You're missing the important case where the data
> structure is inherently and intrinsically multidimensional.
>
>my int Array @foo : dimensions(3);
>@foo[1;2;3] = 12;
>
> Or whatever the syntax is in perl to declare a 3
On Mon, 22 Jul 2002, Angel Faus wrote:
> In my opinion, there are actually two different things to dicuss:
>
> - keyed opcodes
> - keyed methods on the PMC vtable
>
...
>
> Keyed opcodes can stay in the interest of code density.
>
> >
> > No. Keyed access for all methods stays. You're for
> This would only automate the generation of large amounts of code, not get rid
> of the large amount of code being generated. Once again, my complaint here is that
> the L2 cache would buckle under the weight of a dozen PMCs each defining a few dozen
> recursive accessors. The performance gain of
In message
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Keys are either constant key structs, constant integers, string
> registers, or integer registers. Encoding shouldn't be any different
> than any other constant or register. Jeff's got an opcode
On Sun, Jul 21, 2002 at 11:46:34AM -0700, Scott Walters wrote:
> Perl 5 runs *awesome* on a 486/25. Java (Kaffe) is completely unusable.
> AWT windows come up in a matter of *days*, whereas a Tk window comes up
> in about 45 seconds. On a fast computer, these things are blurred. The point
> is,
Nicholas Clark:
# On Sun, Jul 21, 2002 at 11:46:34AM -0700, Scott Walters wrote:
# > Perl 5 runs *awesome* on a 486/25. Java (Kaffe) is completely
# > unusable.
# > AWT windows come up in a matter of *days*, whereas a Tk
# window comes up
# > in about 45 seconds. On a fast computer, these thing
At 09:58 PM 7/22/2002 +0100, Nicholas Clark wrote:
>On Sun, Jul 21, 2002 at 11:46:34AM -0700, Scott Walters wrote:
> > Perl 5 runs *awesome* on a 486/25. Java (Kaffe) is completely unusable.
> > AWT windows come up in a matter of *days*, whereas a Tk window comes up
> > in about 45 seconds. On a f
20 matches
Mail list logo