Re: [RFC] How are compound keys with a PerlHash intended to work?
At 9:03 AM +0200 9/16/02, Leopold Toetsch wrote:
>Ken Fox wrote:
>
>>Dan Sugalski wrote:
>
>>>On lookup. The aggregate being queried by key is responsible for
>>>complaining if the key its passed is something that it doesn't
>>>like.
>>
>>
>>If %h{"a"}[0][1] is a PASM P2["a";0;1], then what is %h{"a"}{0}{1}?
>>
>>It can't be the same thing, because then we lose the distinction
>>between hash and array lookups. (I think this is where the type
>>checking confusion is.)
>
>
>In PASM they look the same. But as Dan stated, and as tried to show
>in my answer to Graham, the lookup succeeds only if the nested PMCs
>are all of the correct type. This works now because an array doesn't
>support a string as key, while a perlhash doesn't support an int as
>key.
>
>So the wrong types will produce either "Not a string!" or "Not an integer!".
I've been thinking that we do need to have an extra flag to note
whether a key element should be taken as an array or hash lookup
element. The integer 1 isn't quite enough, since someone may have
done a %foo{1} and we only have that in as an integer key.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
pdd06_pasm, pdd08_keys: _keyed ops
Above docs state, that a gernal parrot op looks like this op dest[dkey], src1[skey1], src2[skey2] e.g. add P0[P1], P2, P3[P4] where P1 and P4 are keys and P0 and P3 are aggregates and P2 is a scalar. Several questions arise from these pdd's: 1) Are above pdd's valid, WRT this 3 key opcodes? 2) What PASM ops should above statement generate: a) add_p_k_p_p_k (i.e. all variations of /p(_k)?/ ) b) add_p_k_p_k_p_k if b) how to create a NULL key and how does it look like in PBC? Thanks, leo
Re: pdd06_pasm, pdd08_keys: _keyed ops
In message <[EMAIL PROTECTED]> Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Above docs state, that a gernal parrot op looks like this > > op dest[dkey], src1[skey1], src2[skey2] > > e.g. > > add P0[P1], P2, P3[P4] > > where P1 and P4 are keys and P0 and P3 are aggregates and P2 is a scalar. > > Several questions arise from these pdd's: > > 1) Are above pdd's valid, WRT this 3 key opcodes? As far as I know PDD 08 is up to date, at least if you ignore the lack of detail on how to generate keys dynamically, which I have a patch for that I need to finish off. There was however some discussion as to whether we wanted to limit keyed access to just the set/assign opcodes in order to avoid the explosion of ops that would occur if we supported keyed access directly on every op. > 2) What PASM ops should above statement generate: > a) add_p_k_p_p_k (i.e. all variations of /p(_k)?/ ) > b) add_p_k_p_k_p_k >if b) how to create a NULL key and how does it look like in PBC? As things stand it would have to be option a, or at least that is what the current assembler would generate. There isn't much else it can do really - how would it know when to generate a null key for an operand and when not to? I believe you could encode a key constant with zero components in the byte code if you wanted - the first word of the constant is the component count after all. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Re: [RFC] How are compound keys with a PerlHash intended to work?
Dan Sugalski wrote:
> At 9:03 AM +0200 9/16/02, Leopold Toetsch wrote:
>> In PASM they look the same. But as Dan stated, and as tried to show in
>> my answer to Graham, the lookup succeeds only if the nested PMCs are
>> all of the correct type. This works now because an array doesn't
>> support a string as key, while a perlhash doesn't support an int as key.
>>
>> So the wrong types will produce either "Not a string!" or "Not an
>> integer!".
>
>
> I've been thinking that we do need to have an extra flag to note whether
> a key element should be taken as an array or hash lookup element. The
> integer 1 isn't quite enough, since someone may have done a %foo{1} and
> we only have that in as an integer key.
There are IMHO 2 solutions for this:
- the HL takes care of this, so imcc sees: _HV_foo["1"]
- assembler/imcc takes care of this: P0[1] => array, P0{1} => hash and
generates a string key for the latter.
leo
Re: [RFC] How are compound keys with a PerlHash intended to work?
On Wed, Sep 18, 2002 at 10:15:20AM +0200, Dan Sugalski wrote:
> I've been thinking that we do need to have an extra flag to note
> whether a key element should be taken as an array or hash lookup
> element. The integer 1 isn't quite enough, since someone may have
> done a %foo{1} and we only have that in as an integer key.
I agree. Using integer key == array and string key == hash is not
enough imo. What about a hash that is index by object, not a string.
What about an array that is index by strings ? ie
my @array is indexed('a'..'z');
So if parrot wants to provide a method for compound keys, then the
HL should be able to specify what type it is expecting each level
to be.
But the question also exists how this flag should be used/checked.
For example, does the op use it to test the PMC type before calling
the method to fetch the contents, or does it just pass it to the
method and let the PMC do what it wants with it.
I would suggest it gets passed to the method as an argument. That
would allow a PMC to be written that does not care how it is accessed.
But it would also allow the PMC class to do something different
depending on how it is accessed.
Graham.
Re: pdd06_pasm, pdd08_keys: _keyed ops
Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>
>>op dest[dkey], src1[skey1], src2[skey2]
>>
>>e.g.
>>
>>add P0[P1], P2, P3[P4]
> There was however some discussion as to whether we wanted to limit
> keyed access to just the set/assign opcodes in order to avoid the
> explosion of ops that would occur if we supported keyed access
> directly on every op.
The first question is, does a HL need such operations? Or better,
does/will it produce such operations?
E.g. @a[$i] = $j + @b[$k] + 1 produces a sequence of PerlUndef's to hold
the intermediate operands of Binop('+'). Of course clever code
generation or an optimizer could take advantage of these _keyed operations.
If we really want _keyed operations for all ops (and even when not) I
would flag the _keyed ops and preprocess them in the run loop:
- op and op_keyed have the same (opcode & OP_FLAG_MASK)
if (op & OP_KEY1_FLAG)
arg1p = get_entry(arg1,key)
else
arg1p = P(arg1)
...
DO_OP(op & OP_FLAG_MASK, argp1...)
if (op & OP_KEY1_FLAG)
store_entry...
Very similar to predereferencing.
Actually, it could prederefernce all operands.
This would save a lot of opcodes and provide a smaller and more compact
core. Predereferncing is faster then other runmodes.
>>2) What PASM ops should above statement generate:
>>a) add_p_k_p_p_k (i.e. all variations of /p(_k)?/ )
>>b) add_p_k_p_k_p_k
>> if b) how to create a NULL key and how does it look like in PBC?
>>
>
> As things stand it would have to be option a, or at least that is what
> the current assembler would generate. There isn't much else it can do
> really - how would it know when to generate a null key for an operand
> and when not to?
If there is a plain P0 without [], the assembler hat to insert a NULL
key instead.
> I believe you could encode a key constant with zero components in the
> byte code if you wanted - the first word of the constant is the
> component count after all.
Yes, that seems to be working.
> Tom
leo
Re: pdd06_pasm, pdd08_keys: _keyed ops
In message <[EMAIL PROTECTED]> Leopold Toetsch <[EMAIL PROTECTED]> wrote: > >>2) What PASM ops should above statement generate: > >>a) add_p_k_p_p_k (i.e. all variations of /p(_k)?/ ) > >>b) add_p_k_p_k_p_k > >> if b) how to create a NULL key and how does it look like in PBC? > >> > > As things stand it would have to be option a, or at least that is > > what > > > the current assembler would generate. There isn't much else it can do > > really - how would it know when to generate a null key for an operand > > and when not to? > > If there is a plain P0 without [], the assembler hat to insert a NULL > key instead. In other words we assume all PMC arguments have a key, so you can never have a p in a opcode name with one of k/kc/ki/kic following it? You will still get horrible op explosion for a three argument op as even if you assume that all PMCs are keyed, there are four key types which, with three operands, gives you 64 ops in total. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
[perl #17402] [PATCH] Duplicate defined_keyed in array.pmc
# New Ticket Created by Leon Brocard
# Please include the string: [perl #17402]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17402 >
classes/array.pmc had a duplicate defined_keyed which gcc under
Jagwyre complained. Here is a patch to remove one of the
duplicates. The tests still pass.
Leon
--
Leon Brocard.http://www.astray.com/
scribot.http://www.scribot.com/
... Consciousness: that annoying time between naps
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/38003/30897/317896/array.pmc.patch
Index: classes/array.pmc
===
RCS file: /cvs/public/parrot/classes/array.pmc,v
retrieving revision 1.33
diff -u -r1.33 array.pmc
--- classes/array.pmc 18 Sep 2002 05:09:24 - 1.33
+++ classes/array.pmc 18 Sep 2002 11:54:04 -
@@ -575,24 +575,6 @@
return array[ix] != NULL;
}
-INTVAL defined_keyed (PMC* key) {
-INTVAL ix;
-PMC* nextkey;
-PMC* box;
-
-if (!key)
- return 0;
-ix = key_integer(INTERP, key);
-nextkey = key_next(INTERP, key);
-if (nextkey == NULL)
- return SELF.exists_keyed_int(&ix);
-
-box = SELF.get_pmc_keyed_int(&ix);
-if (box == NULL)
- return 0;
-return box->vtable->exists_keyed(INTERP, box, nextkey);
-}
-
/* == operation */
INTVAL is_equal (PMC* value) {
return 0;
Re: cvs commit: parrot/docs/pdds pdd03_calling_conventions.pod
Maybe I should wait for the entire picture here, but in cases like this (int $x, string $y) = some_function() it would be nice to pass in both type _and_ number of return values. Or, more generally, to consider the type of a list to be a list of the types of its members. This means that types can become arbitrarily complex, so it should probably be possible for a routine to say "here's a PMC holding the return type". /s On 18 Sep 2002 [EMAIL PROTECTED] wrote: > +=item Version 1.1 > + > +We now call with a frame, rather than pushing on the stack, and we > +return frames, rather than returning a stack. We also pass in context > +information for the return. > + >=item Version 1.0 > > +=item I3 > + > +The return type expected. This is the identifier number for the > +class. A return type of 0 is void context, -1 is unknown, and -2 and > +down are the number of expected return variables, negated, minus > +one. (So -2 means we expect 1 variable, -3 means we expect 2, -4 > +means we expect 3, and so forth)
Re: pdd06_pasm, pdd08_keys: _keyed ops
Tom Hughes wrote: >>If there is a plain P0 without [], the assembler hat to insert a NULL >>key instead. >> > > In other words we assume all PMC arguments have a key, so you can > never have a p in a opcode name with one of k/kc/ki/kic following it? No - only if there is any "p_k" not for _kc/_ki_kic. > You will still get horrible op explosion for a three argument op as > even if you assume that all PMCs are keyed, there are four key types > which, with three operands, gives you 64 ops in total. No. We would have set_p_kc set_p_ki set_p_kic ... special shortcut set/get, only one key per op allowed and op_p_k_p_k ... unary keyed, all k are KEYs op_p_k_p_k_p_k ... 3 keys bin op, all k are KEYs All 64 combinations would be a horror. But I really vote for a predereferencing like solution. > Tom leo
Re: [perl #17402] [PATCH] Duplicate defined_keyed in array.pmc
Leon Brocard (via RT) wrote:
> classes/array.pmc had a duplicate defined_keyed which gcc under
> Jagwyre complained. Here is a patch to remove one of the
> duplicates. The tests still pass.
>
> Leon
>
>
> -INTVAL defined_keyed (PMC* key) {
+INTVAL exists_keyed (PMC* key) {
The second "defined" should be an "exists" obviously.
leo
Re: pdd06_pasm, pdd08_keys: _keyed ops
On 18 Sep 2002, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > > [ add Px[Ix], Py, Pz[Iz] > > > > 2) What PASM ops should above statement generate: > > a) add_p_k_p_p_k (i.e. all variations of /p(_k)?/ ) > > b) add_p_k_p_k_p_k > >if b) how to create a NULL key and how does it look like in PBC? > > As things stand it would have to be option a, or at least that is what > the current assembler would generate. There isn't much else it can do > really - how would it know when to generate a null key for an operand > and when not to? Another possible option would be to extend the number of vtable methods that might end up taking NULL keys -- some of them do already. Then anything that had any keyed arguments could generate (possibly empty) keys for _all_ arguments. /s
Re: pdd06_pasm, pdd08_keys: _keyed ops
On Wed, 18 Sep 2002, Leopold Toetsch wrote:
> Tom Hughes wrote:
>
> > In message <[EMAIL PROTECTED]>
> > Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> >
> >
> >>op dest[dkey], src1[skey1], src2[skey2]
> >>
> >>e.g.
> >>
> >>add P0[P1], P2, P3[P4]
>
> > There was however some discussion as to whether we wanted to limit
> > keyed access to just the set/assign opcodes in order to avoid the
> > explosion of ops that would occur if we supported keyed access
> > directly on every op.
>
> The first question is, does a HL need such operations? Or better,
> does/will it produce such operations?
Actually, if scratchpads become proper PMC's these ops would be incredibly
useful and common. For example, "@a[0] = %b{1} + $c" might become
add P0["@a";0], P0["%b";"1"], P0["$c"]
This is rather speculative, but if many operations will be on lexicals as
opposed to registers/temporaries, such hoariness might be worth it.
/s
Re: [perl #17402] [PATCH] Duplicate defined_keyed in array.pmc
Thanks, applied. /s
Re: pdd06_pasm, pdd08_keys: _keyed ops
In message <[EMAIL PROTECTED]> Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Tom Hughes wrote: > > > You will still get horrible op explosion for a three argument op as > > even if you assume that all PMCs are keyed, there are four key types > > which, with three operands, gives you 64 ops in total. > > No. We would have > set_p_kc > set_p_ki > set_p_kic ... special shortcut set/get, only one key per op allowed > and > op_p_k_p_k ... unary keyed, all k are KEYs > op_p_k_p_k_p_k ... 3 keys bin op, all k are KEYs So now the assembler has to know that set is special and can have all four sorts of keys while the other ops only support dynamic keys? > All 64 combinations would be a horror. Indeed. > But I really vote for a predereferencing like solution. I didn't really understand that part of your previous message, but I don't see what relevance that has to how the assembler decides on the op name to use (and hence how to encode the arguments). Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Re: pdd06_pasm, pdd08_keys: _keyed ops
In message <[EMAIL PROTECTED]>
Sean O'Rourke <[EMAIL PROTECTED]> wrote:
> Actually, if scratchpads become proper PMC's these ops would be incredibly
> useful and common. For example, "@a[0] = %b{1} + $c" might become
>
> add P0["@a";0], P0["%b";"1"], P0["$c"]
>
> This is rather speculative, but if many operations will be on lexicals as
> opposed to registers/temporaries, such hoariness might be worth it.
Except those indexes are key constants which are type kc but Leopold
only wants to allow dynamically created keys of type k on the other ops.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
Re: pdd06_pasm, pdd08_keys: _keyed ops
On 18 Sep 2002, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Sean O'Rourke <[EMAIL PROTECTED]> wrote:
>
> > Actually, if scratchpads become proper PMC's these ops would be incredibly
> > useful and common. For example, "@a[0] = %b{1} + $c" might become
> >
> > add P0["@a";0], P0["%b";"1"], P0["$c"]
> >
> > This is rather speculative, but if many operations will be on lexicals as
> > opposed to registers/temporaries, such hoariness might be worth it.
>
> Except those indexes are key constants which are type kc but Leopold
> only wants to allow dynamically created keys of type k on the other ops.
Hm... maybe I'd rather have constant and run-time keys go through the same
op. An alternative would be to build up the lexical refs from constant
key-construction ops, then use the _k versions.
/s
how to use MultiArray?
I couldn't find any example of using a MultiArray PMC. I tried on my own, but failed miserably. from what I've seen, it seems that is impossible to properly initialize a multidimensional MultiArray. I've tried this: new P1, .MultiArray, 1000 set P1[0;0], 1 set P1[0;1], 2 set P1[0;2], 3 print "(0,0)=" set I0, P1[0;0] print I0 # prints: # (0,0)=3 end every assignment changes whe whole P1[0] array. it seems to lose the 2nd dimension somehow, probably because the "dimension" member of the PMC was never initialized. how do I go on using this? what do we need to make it work? cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: Hyperoperators and dimensional extension
At 12:04 AM -0700 9/18/02, Brent Dax wrote: >The Apocalypse on operators says that if one of the operands of a >hyperoperator is a scalar, then that scalar is (nominally) treated as an >array of copies of that scalar. In other words: > > my $foo=1; > my @bar=(2, 3, 4); > > my @baz=$foo ^+ @bar; # @baz=(3, 4, 5) > >Does that extend to multiple dimensions? Sort of, yes. Basically the behaviour of hyper-operated operators is delegated via multimethod dispatch to the hyper-operator functions. By default the base perl variables will expand themselves out, but the engine itself won't enforce this, as the classes can potentially overload the hyper-operators. So if the multiple-dimensional aggregate provides a proper "operate against a single scalar" method that goes multidimensionally, then we'll do that. If it doesn't, we won't. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: hotplug regexes, other misc regex questions
Steve Fink wrote:
> What should this do:
>
> my $x = "the letter x";
> print "yes" if $x =~ /the { $x .= "!" } .* !/;
>
> Does this print "yes"?
If it's allowed at all, I think the match should succeed.
> print "yes" if "helo" =~ /hel { .pos-- } lo/;
This definitely has to work. But remember the call to C is on
the "match object" (i.e. $0), not the string.
> Would it be correct for this to print 0? Would it be correct for this
> to print 2?
>
> my $n = 0;
> "aargh" =~ /a* { $n++ } aargh/;
> print $n;
Yes. ;-)
> What possible outputs are legal for this:
>
> "aaa" =~ /( a { print 1 } | a { print 2 })* { print "\n" } x/
Unless Larry specifies a required semantics, there are potentially very
many acceptable outputs from this, depending on implementation.
Therefore, your implementation must print the superposition of all possible
outputs. ;-)
Actually, I would expect that *any* pattern with closures in it should act as
though it were trying each branch and loop in the normal sequence (even if
it optimizes that sequence away (which probably means it can't do that
optimization in the first place (which means it should act as though it were
trying each branch and loop in the normal sequence %-))).
Of course, LMMV.
Damian
[perl #17405] [PATCH] correct make pdb on Win32
# New Ticket Created by "Aldo Calpini" # Please include the string: [perl #17405] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17405 > this one patches the Makefile to correctly build a "pdb.exe" on Win32 (it should also do the Right Thing on each platform that has an extension for executables). the Makefile was producing a file named "pdb" which could not be executed on Windows (I had to rename it "pdb.exe" after the make). cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; -- attachment 1 -- url: http://rt.perl.org/rt2/attach/38013/30904/7e2db4/pdb_exe.patch pdb_exe.patch Description: pdb_exe.patch
Re: [RFC] How are compound keys with a PerlHash intended to work?
At 11:25 AM +0100 9/18/02, Graham Barr wrote:
>On Wed, Sep 18, 2002 at 10:15:20AM +0200, Dan Sugalski wrote:
>> I've been thinking that we do need to have an extra flag to note
>> whether a key element should be taken as an array or hash lookup
>> element. The integer 1 isn't quite enough, since someone may have
>> done a %foo{1} and we only have that in as an integer key.
>
>I agree. Using integer key == array and string key == hash is not
>enough imo. What about a hash that is index by object, not a string.
>What about an array that is index by strings ? ie
>
> my @array is indexed('a'..'z');
>
>So if parrot wants to provide a method for compound keys, then the
>HL should be able to specify what type it is expecting each level
>to be.
>
>But the question also exists how this flag should be used/checked.
The variable itself is responsible for checking at runtime, though we
can and will do compile-time checking when we can. Since it's a flag
in the key, it's passed into the variable's vtable method, and there
to check if it chooses. (Which it ought, in most cases)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [perl #17358] [PATCH] default.pmc #2
At 8:37 AM -0700 9/16/02, Sean O'Rourke wrote: >It seems to me that by making everything an exception, this patch goes too >far in a couple of ways. First, some fallback behaviors make sense. For >example, if a class implements set_bignum() but not set_int(), it makes >sense for default.pmc to wrap the int up as a bignum and send it on, >rather than complaining. Nope, that's not for default.pmc to do. That's something that we should weld more smarts into the pmc preprocessor for, rather than having fallbacks in default.pmc. I'd rather default.pmc pitch errors unconditionally. We can, and should, have some other method of indicating default methods should be built from other methods, but default.pmc should be dead-boring and stupid. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: hotplug regexes, other misc regex questions
On Wed, 18 Sep 2002, Damian Conway wrote:
> > Would it be correct for this to print 0? Would it be correct for this
> > to print 2?
> >
> > my $n = 0;
> > "aargh" =~ /a* { $n++ } aargh/;
> > print $n;
>
> Yes. ;-)
Wouldn't that print 2 if $n is lexical and 0 if it's localized? Or are
lexicals localized now?
> > What possible outputs are legal for this:
> >
> > "aaa" =~ /( a { print 1 } | a { print 2 })* { print "\n" } x/
I take it that what I've learned from _Mastering_Regular_Expressions_
doesn't quite apply here? From that interpretation I'd think it'd print
"111\n" since the second part of the alternation wouldn't be tried.
Joshua b. Jore
http://www.greentechnologist.org
Re: Perl 6 Summary for week ending 2002-09-15
On Wed, 2002-09-18 at 11:42, Piers Cawley wrote: > The Perl 6 Summary for the Week Ending 20020915 > Happy birthday to me! Indeed! And thank you so much for this. You have a way of taking a tangled mess of discussion that's even confusing the participants and making it easy to digest (no pun intended). I even come out of it with a smile at the end. Thanks again! -- Aaron Sherman <[EMAIL PROTECTED]> http://www.ajs.com/~ajs
Re: pdd06_pasm, pdd08_keys: _keyed ops
Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>>All 64 combinations would be a horror.
> Indeed.
>>But I really vote for a predereferencing like solution.
> I didn't really understand that part of your previous message, but I
> don't see what relevance that has to how the assembler decides on the
> op name to use (and hence how to encode the arguments).
Predereferencing now generates changed bytecode on the fly by
1) putting the absolute address of operands into the opcode stream, so
2) e.g. set_i_ic and set_i_i have the same C-source, actually, since my
patch the former is omitted at all.
For _keyed operands I would propose:
The used keys are not coded into the opcode name (so no 64 variations),
but the opcode-number holds this information.
add_p_p_p (op #297)
app_p_k_p_p => #297 + (KEY1_FLAGS << 16)
add_p_p_k_p => #297 + (KEY2_FLAGS << 16)
where KEY1_FLAGS are e.g.
_k 0b0001
_ki 0b0011
_kic 0b0111
_kc 0b0101
KEY2_FLAGS same << 3 ...
Now the current run loop look's like this:
while (pc) {
DO_OP(pc, interpreter);
}
#define DO_OP(PC,INTERP) (PC = (INTERP->op_func_table)[*PC])(PC,INTERP))
I would change the run loop like so:
while (pc) {
argp1 = ...pmc_reg.registers[cur_opcode[1]];
if (*pc & KEY1_MASK) {
key1 = ...pmc_reg.registers[cur_opcode[2]]; /* for p_k */
argp1 = get_keyed_entry(argp1, key1, flags);
}
...
PC = (INTERP->op_func_table)[*PC & KEY_MASK]( ... );
PC += n_keys; /* account for additonal keys in bytecode */
}
which would call add_p_p_p(argp1, argp2, argp3).
"argp" points either directly to the PMC register, or for keys, into the
bucket, where the PMC is stored in the aggregate. Of course, argp
shouldn't move due to GC while processing one op.
This would allow all 64 variations of keyed ops w/o opcode bloat, if
I didn't ignore some essential part ;-)
LHS keys and autovivification, e.g. but this we don't have now either.
> Tom
leo
Re: pdd06_pasm, pdd08_keys: _keyed ops
In message <[EMAIL PROTECTED]>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> For _keyed operands I would propose:
>
> The used keys are not coded into the opcode name (so no 64 variations),
> but the opcode-number holds this information.
>
> add_p_p_p (op #297)
> app_p_k_p_p => #297 + (KEY1_FLAGS << 16)
> add_p_p_k_p => #297 + (KEY2_FLAGS << 16)
> ...
> where KEY1_FLAGS are e.g.
> _k 0b0001
> _ki 0b0011
> _kic 0b0111
> _kc 0b0101
> KEY2_FLAGS same << 3 ...
>
> Now the current run loop look's like this:
> while (pc) {
> DO_OP(pc, interpreter);
> }
>
> #define DO_OP(PC,INTERP) (PC = (INTERP->op_func_table)[*PC])(PC,INTERP))
>
> I would change the run loop like so:
>
>while (pc) {
> argp1 = ...pmc_reg.registers[cur_opcode[1]];
> if (*pc & KEY1_MASK) {
> key1 = ...pmc_reg.registers[cur_opcode[2]]; /* for p_k */
> argp1 = get_keyed_entry(argp1, key1, flags);
> }
> ...
> PC = (INTERP->op_func_table)[*PC & KEY_MASK]( ... );
> PC += n_keys; /* account for additonal keys in bytecode */
> }
>
> which would call add_p_p_p(argp1, argp2, argp3).
>
> "argp" points either directly to the PMC register, or for keys, into
> the bucket, where the PMC is stored in the aggregate. Of course, argp
> shouldn't move due to GC while processing one op.
This may be all fine and dandy for the prederef case but it's going to
force the opcode functions to do a lot more work working out where to
get the key from in all the other cases.
It also prevents you using the optimised _int vtable methods for keyed
access using integer keys...
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
Re: languages/perl6/t/compiler/2.t factorial issue
On Fri, 13 Sep 2002, Sean O'Rourke wrote: > On Fri, 13 Sep 2002, Andy Dougherty wrote: > > > This test tests for > > > > 12! = 479001600 > > 14! = 1278945280 > > > > However, 14! is really 87178291200. > > > > Is the test deliberately trying to test for some 32-bit-specific > > integer overflow behavior? > > No, it's just testing recursive functions. 14! % 2^32 happens to be > 1278945280. The test could use some other function (like making the mod > explicit, for example). That's what I would have thought, but it seems that 12! is already testing recursive functions. Unless there's an objection, I'll just delete the 14! test. -- Andy Dougherty [EMAIL PROTECTED]
Re: languages/perl6/t/compiler/2.t factorial issue
On Wed, 18 Sep 2002, Andy Dougherty wrote: > That's what I would have thought, but it seems that 12! is already testing > recursive functions. Unless there's an objection, I'll just delete the > 14! test. Sure. /s
Re: pdd06_pasm, pdd08_keys: _keyed ops
Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> while (pc) {
>> argp1 = ...pmc_reg.registers[cur_opcode[1]];
>> if (*pc & KEY1_MASK) {
>>key1 = ...pmc_reg.registers[cur_opcode[2]]; /* for p_k */
>>argp1 = get_keyed_entry(argp1, key1, flags);
>> }
>> ...
>> PC = (INTERP->op_func_table)[*PC & KEY_MASK]( ... );
>> PC += n_keys; /* account for additonal keys in bytecode */
>>}
>>
>> which would call add_p_p_p(argp1, argp2, argp3).
>>
>>"argp" points either directly to the PMC register, or for keys, into
>>the bucket, where the PMC is stored in the aggregate. Of course, argp
>>shouldn't move due to GC while processing one op.
>>
>
> This may be all fine and dandy for the prederef case but it's going to
> force the opcode functions to do a lot more work working out where to
> get the key from in all the other cases.
No, this would be the run loop for _all_ cores. So _all_ keyed access is
taken out of the vtable function and done in the run loop.
> It also prevents you using the optimised _int vtable methods for keyed
> access using integer keys...
I don't see that. Were we now have op_keyed and op_keyed_int, we could
still use this optimization by calling op_p and op_i.
> Tom
leo
Perl 6 Summary for week ending 2002-09-15
The Perl 6 Summary for the Week Ending 20020915 Happy birthday to me! Happy birthday to me! Happy birthday dear me! Happy birthday to me! And, with a single breech of copyright, Piers was free. The production of this summary was delayed by my turning 35 on the 15th and then spending the Monday train journey reading one of my birthday presents (*Dead Air* by Iain Banks, it's jolly good) instead of writing a summary. So this morning I left the book at home. So, what's been going on with Perl 6. We'll start, as usual with perl6-internals. Goal call for 0.0.9 The week before, Dan had asked for some suggestions as to what should be the priorities for the 0.0.9 release of Parrot. One of Nicholas Clark's goals from last week was the `Careful elimination of all compiler warnings, particularly on non x86 platforms, and for builds with non-default INTVAL size', and discussions of how to go about doing this (and indeed some doing) carried on into this week. There was also some discussion about whether IMCC and the Perl 6 compiler should be built by default. On the one hand, it would mean that the tinderboxes were testing those important subsystems, on the other hand, it was thought that there were some people who wouldn't be interested in testing those things. Consensus seemed to be that we should just build and test them anyway. http://makeashorterlink.com/?M2E0225D1 Scheme Implementation Details Jürgen Bömmels and Piers Cawley continued their discussion of how to go about implementing a scheme interpreter, and "lambda" in particular. Piers made noises about a proof of concept implementation of Scheme that he'd made using Perl objects, but didn't show code. (And, I can exclusively reveal, will not be showing (the original) code owing to badness with backups and lackadaisical use of CVS). Jürgen, who had actually made the effort of writing some code, listened politely and agreed that Piers' suggestions looked like they might be a way forward. Jürgen went away and implemented a first cut at "quote", "define" and "set!". http://makeashorterlink.com/?O2F0325D1 http://makeashorterlink.com/?K101255D1 "chr", "ord" etc. Clinton A Pierce restarted this thread and discussed what he'd like to see (apart from a pony) from Parrot's equivalent of Perl 5's "pack". Clint wondered whether Parrot "pack" should use a template, or if it should be implemented as a horde of smaller ops, each handling a different conversion, so that a single, Perl level call to pack would become lots of op calls at the parrot level. Clint also drools at the thought of doing "sprintf" at the parrot level. Aaron Sherman agreed with most (all?) of Clint's proposals, and also wants a pony. (Who doesn't?). Peter Gibbs went so far as to offer a patch which implemented a subset of pack functionality, and was applauded. Graham Barr wondered if pack should also allow for packing to 'native' types, which wouldn't have to worry about endian issues. Peter thought that would be a good idea. Nicholas Clark pointed out that extending the code to cope with unsigned integers would be a good idea too. http://makeashorterlink.com/?A311215D1 Lexicals Jürgen Bömmels asked a pile of questions about the implementation of lexical variables and how one could use them to make a closure. Jonathan Sillito provided a mixture of answers and guesses. It seems that we're waiting on Dan to firm some things up about lexicals. http://makeashorterlink.com/?E221215D1 IMCC 0.0.9 Runs 100% Perl 6 Tests + Various Results Leopold Toetsch has been working on getting IMCC to generate parrot bytecode directly rather than going through a stage of generating an intermediate ".pasm" file, and had been having some problems with `writing out the .pbc, especially Const_Table, type PFC_KEY / PARROT_ARG_SC'. Two hours later he announced that he had all the perl6 tests running successfully within IMCC, but only if GC was turned off (there are problems with the longer running tests when GC is turned on). Things get progressively worse as first JIT, and then Predereferencing are turned on. Dan wondered what the GC bug could be. Leo wasn't sure but posted some possible pointers. Peter Gibbs thought that at least one of the bugs was in continuation.pmc and posted a patch which fixed one of the problems when running under parrot. Meanwhile Leo tracked down the bug to a bit of code that he'd appropriated from debug.c, so he fixed his IMCC and sent in a patch to fix debug.c as well. Applying both patches meant that the tests all passed under both IMCC and parrot. Dan applied both patches. Leo later fixed his problem with writing out a .pbc file directly from IMCC, and offered a patch to pa
Re: hotplug regexes, other misc regex questions
On Wed, 18 Sep 2002, Josh Jore wrote:
> On Wed, 18 Sep 2002, Damian Conway wrote:
>
> > > Would it be correct for this to print 0? Would it be correct for this
> > > to print 2?
> > >
> > > my $n = 0;
> > > "aargh" =~ /a* { $n++ } aargh/;
> > > print $n;
> >
> > Yes. ;-)
>
> Wouldn't that print 2 if $n is lexical and 0 if it's localized? Or are
> lexicals localized now?
Well, { $n++ } is within the lexical scope of $n, so it doesn't matter.
What matters is whether $n++ was hypotheticalized like so:
"aargh" =~ /a* { let $n++ } aargh/ # can it work that way?
Then it would either print 1 or 0, because if it backtracked, the ++ would
be undone. If the change is adopted that you can't optimize when there's
a closure in the middle of the optimization, it would print 1.
> > > What possible outputs are legal for this:
> > >
> > > "aaa" =~ /( a { print 1 } | a { print 2 })* { print "\n" } x/
>
> I take it that what I've learned from _Mastering_Regular_Expressions_
> doesn't quite apply here? From that interpretation I'd think it'd print
> "111\n" since the second part of the alternation wouldn't be tried.
The first time through, yes. But then it tries to match the "x", and says
"oops, that's not what I have" and backtracks. That tries the second of
the alternation, which doesn't work either. So it backtracks so the * is
only getting two of the first one, et cetera...
Or are you talking about something else from Mastering Regular
Expressions? Like some kind of optimization that happens?
Luke
Re: Perl 6 Summary for week ending 2002-09-15
Aaron Sherman <[EMAIL PROTECTED]> writes: > On Wed, 2002-09-18 at 11:42, Piers Cawley wrote: >> The Perl 6 Summary for the Week Ending 20020915 >> Happy birthday to me! > > Indeed! > > And thank you so much for this. You have a way of taking a tangled mess > of discussion that's even confusing the participants and making it easy > to digest (no pun intended). I even come out of it with a smile at the > end. Someone just pointed out that I called Tim Bunce "Tim Bunch" in the summary. I really should resist the temptation to post it before at least one extra pair of eyes has looked over it, but I was running my deadline pretty close. The typo makes me, at least, smile, but in a rueful kind of way. > Thanks again! No problem. It's fun, in a weird kind of way. And it definitely keeps me abreast of what's going on. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
perlnum: bitwise_xx
Should these be implemented: - machine dependent, like now: (INTVAL)SELF->cache.num_val | ... - SELF.get_integer() | ... - or just throw an exception leo
