In message a05111b09b960bd6a030f@[63.120.19.221]
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
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
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 3D array
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 forgetting one
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
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.
SNIP
Any takers? ;-)
Sure,
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 things
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 fast
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
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
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'm
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 needed.
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
dereferences the key
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 key
* fetch 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 key
* store PMC
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
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, I
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 that the
20 matches
Mail list logo
