[perl #16085] [PATCH] perlundef.pmc
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16085]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16085 >
Hi,
this one was left over.
Please apply.
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/33289/27409/dce116/perlundef.pmc.diff
--- perlundef.pmc Sun Jul 28 13:33:34 2002
+++ /home/lt/src/parrot-007/classes/perlundef.pmc Thu Aug 8 20:11:49 2002
@@ -127,16 +127,6 @@
pmc->vtable->set_string_native(interpreter, pmc, value);
}
-void set_string_unicode (STRING* value) {
- CHANGE_TYPE(pmc, PerlString);
-pmc->vtable->set_string_unicode(interpreter, pmc, value);
-}
-
-void set_string_other (STRING* value) {
- CHANGE_TYPE(pmc, PerlString);
-pmc->vtable->set_string_other(interpreter, pmc, value);
-}
-
void set_string_same (PMC* value) {
/* Do nothing; Can't happen? */
}
Re: Array vs. PerlArray
Wow, this thread is looking bad -- I'm replying to my own reply to my own message. Sorry; I accidentally hit reply instead of reply to list, and from the resulting off-list discussion with Sean O'Rourke I have updated the patch. I won't resend it, because it may require more changes and it's gotten even bigger. The patch now also: - Puts back all of the flawed but still necessary math ops in PerlArray (actually, I moved them from the original Array to the new PerlArray, because the new Array is very basic and doesn't do things like that.) - Removes the _unicode and _other string ops from all PMCs (the patched pmc2c.pl throws a fatal error if you try to implement vtable methods not in vtable.tbl.) - Uses the new DYNSELF.method(...) syntax all over the place. One point of discussion: Sean thinks that default.pmc should throw "operation not supported" exceptions for most operations, so that PMCs that do not define the operations don't do something mysterious and seg fault-prone when they're called. Which makes an awful lot of sense to me, but when I went to default.pmc to do that, I saw that they all have code that tries very hard to do something sensible in many cases. I'm loath to just rip out that much code (especially since I'm not sure how many things are successfully using it), so I left it in. I'm now thinking that we ought to have a default.pmc that throws "not supported" for everything, but move all of the current fallback implementations into a new class and reparent a bunch of the existing PMCs (probably all of the non-aggregates?). The hard part will be coming up with a name for it... Anyway, that would be a separate patch. Anyone have a problem with what my current patch does, before I commit it? [Just say no to Warnock's Dilemma!]
Re: Array vs. PerlArray
At 11:00 AM -0700 8/8/02, Steve Fink wrote: >Oh, yeah. The perl6 summary reminded me: I forgot to mention that this >would also make $a[-6] (or @a[-6] if you're writing perl6) on a >4-element array throw an exception instead of autoextending the array, >wrapping around to a valid element, or exploding in flames. That goes >for both Array and PerlArray. I don't remember what the currently >checked-in version does. Array and PerlArray shouldn't autoextend that way, I think. I'm not 100% sure that Array should auto-extend at all--I think I'd rather it didn't. We need to check with Larry as to whether PerlArrays should autoextend when using excess negative indices. >The other array-related thing in the perl6 summary was about a fetch >of $a[1] triggering autoextension to 10001 elements -- that >doesn't happen anymore with this patch. That's a good thing, though. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PMC assignment stuff
At 10:13 AM +0100 8/8/02, Nicholas Clark wrote: >On Thu, Aug 08, 2002 at 10:21:54AM +0200, Peter Gibbs wrote: > > Should a PerlScalar have its own vtable which acts as appropriate >> depending on current content, or should it switch vtables as the >> content changes? If the latter, do we have separate vtables for >> e.g. PerlInt versus PerlScalarContainingAnInt, or do we use the >> same PerlInt vtable, but have a separate 'real type' somewhere in >> the PMC, for use by set_pmc (and anybody else that needs to >> behave differently) ? > >Is it possible for any parrot code to spot the difference between these >three? I think the middle suggestion (switching to the PerlInt vtable >when an int is assigned) isn't going to work, as the next time a floating >point (or string) value is assigned to that PMC, the PerlInt vtable will >coerce the incoming value to an int. Which isn't correct. >I think the other two are (or should be) indistinguishable in behaviour, so >then it comes down to speed and maintainability. But I could be wrong. We can do one of two things: 1) Either have separate PerlInt/Num/String classes that differ from the PerlScalar class or 2) Have a flag that governs whether a PMC should upgrade or not. Both make sense--there are times when PMCs should be of fixed type and times when they shouldn't. I think we'll eat up one of the PMC flags for this. We need to differentiate between PMCs that are a type because of declaration and PMCs that are that type because of sheer happenstance, if nothing else. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Array vs. PerlArray
At 12:43 PM -0700 8/8/02, Steve Fink wrote: >Wow, this thread is looking bad -- I'm replying to my own reply to my >own message. Sorry; I accidentally hit reply instead of reply to list, >and from the resulting off-list discussion with Sean O'Rourke I have >updated the patch. I won't resend it, because it may require more >changes and it's gotten even bigger. > >The patch now also: > >- Puts back all of the flawed but still necessary math ops in PerlArray > (actually, I moved them from the original Array to the new > PerlArray, because the new Array is very basic and doesn't do things > like that.) > >- Removes the _unicode and _other string ops from all PMCs (the > patched pmc2c.pl throws a fatal error if you try to implement vtable > methods not in vtable.tbl.) > >- Uses the new DYNSELF.method(...) syntax all over the place. Cool, go commit it. >One point of discussion: Sean thinks that default.pmc should throw >"operation not supported" exceptions for most operations, so that PMCs >that do not define the operations don't do something mysterious and >seg fault-prone when they're called. Which makes an awful lot of sense >to me, but when I went to default.pmc to do that, I saw that they all >have code that tries very hard to do something sensible in many cases. >I'm loath to just rip out that much code (especially since I'm not >sure how many things are successfully using it), so I left it in. Go ahead and rip it all out. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #16085] [PATCH] perlundef.pmc
Leopold Toetsch wrote: (via RT) > this one was left over. > Please apply. > > --- perlundef.pmc Sun Jul 28 13:33:34 2002 > +++ /home/lt/src/parrot-007/classes/perlundef.pmc Thu Aug 8 20:11:49 2002 Thanks Leopold; I have applied this, along with the changes to perlint, perlnum and perlstring that I also left out originally. -- Peter Gibbs EmKel Systems
[perl #16087] [PATCH] Scratchpad pmc
# New Ticket Created by Jonathan Sillito
# Please include the string: [perl #16087]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16087 >
The main purpose of this patch is to give scratchpads a pointer to their
parent pad. In the process I added a Scratchpad pmc that uses its data
pointer to point to a PerlHash (temporarily) and uses its cache pointer
to point to its parent. I am not sure about this use of the cache
pointer, but it is only used internally so it should be easy to change.
The scratchpad.pmc file is attached, the important bits (so far) are the
init(), mark(), set_pmc_keyed() and get_pmc_keyed() vtable methods.
The attached patch has the following effects:
- changes lexical ops in core.ops to use Scratchpad pmc.
- adds Scratchpad to enum in include/parrot/pmc.h
- adds Parrot_Scratchpad_class_init(enum_class_Scratchpad); to
global_setup.c
- adds additional test to t/op/lexicals.t
- fixes examples/assembly/lexicals.pasm (reverses PMC and string
arguments to store_lex op).
MISSING
---
Access by integer index, I am waiting for a way to pass a pad descriptor
(or at least the number of lexicals to go in the pad) to the init vtable
method.
There is no integration with subs/coroutines/continuations. I will add
this if people think this approach is reasonable.
Comments?
--
Jonathan Sillito
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/33293/27417/874baa/lexicals.patch
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/33293/27418/a51da2/scratchpad.pmc
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.195
diff -u -r1.195 core.ops
--- core.ops 7 Aug 2002 04:01:24 - 1.195
+++ core.ops 8 Aug 2002 20:19:54 -
@@ -3662,8 +3662,8 @@
=cut
op new_pad() {
-PMC* hash = pmc_new(interpreter, enum_class_PerlHash);
-stack_push(interpreter, &interpreter->ctx.pad_stack, hash, STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
+PMC * pad = pmc_new(interpreter, enum_class_Scratchpad);
+stack_push(interpreter, &interpreter->ctx.pad_stack, pad, STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
goto NEXT();
}
@@ -3674,24 +3674,22 @@
}
op store_lex(in STR, in PMC) {
-PMC * hash = NULL;
+PMC * pad;
KEY key;
Stack_entry_type type = 0;
MAKE_KEY(key, $1, enum_key_string, struct_val);
-hash = (PMC *)stack_peek(interpreter, interpreter->ctx.pad_stack, &type);
-hash->vtable->set_pmc_keyed(interpreter, hash, NULL, $2, &key);
+pad = (PMC *)stack_peek(interpreter, interpreter->ctx.pad_stack, &type);
+pad->vtable->set_pmc_keyed(interpreter, pad, NULL, $2, &key);
goto NEXT();
}
op find_lex(out PMC, in STR) {
-PMC * hash = NULL;
+PMC * pad;
KEY key;
Stack_entry_type type = 0;
MAKE_KEY(key, $2, enum_key_string, struct_val);
-hash = (PMC *)stack_peek(interpreter, interpreter->ctx.pad_stack, &type);
-$1 = hash->vtable->get_pmc_keyed(interpreter, hash, &key);
-
-/* FIXME: should the not found case be an internal_exception ? */
+pad = (PMC *)stack_peek(interpreter, interpreter->ctx.pad_stack, &type);
+$1 = pad->vtable->get_pmc_keyed(interpreter, pad, &key);
goto NEXT();
}
Index: global_setup.c
===
RCS file: /cvs/public/parrot/global_setup.c,v
retrieving revision 1.31
diff -u -r1.31 global_setup.c
--- global_setup.c 4 Aug 2002 22:54:31 - 1.31
+++ global_setup.c 8 Aug 2002 20:19:54 -
@@ -34,6 +34,7 @@
Parrot_Coroutine_class_init(enum_class_Coroutine);
Parrot_CSub_class_init(enum_class_CSub);
Parrot_Continuation_class_init(enum_class_Continuation);
+Parrot_Scratchpad_class_init(enum_class_Scratchpad);
/* Now register the names of the PMCs */
Index: include/parrot/pmc.h
===
RCS file: /cvs/public/parrot/include/parrot/pmc.h,v
retrieving revision 1.34
diff -u -r1.34 pmc.h
--- include/parrot/pmc.h 4 Aug 2002 22:56:06 - 1.34
+++ include/parrot/pmc.h 8 Aug 2002 20:19:54 -
@@ -27,6 +27,7 @@
enum_class_Coroutine,
enum_class_Continuation,
enum_class_CSub,
+enum_class_Scratchpad,
enum_class_max = 100
};
VAR_SCOPE VTABLE Parrot_base_vtables[enum_class_max];
Index: t/op/lexicals.t
===
RCS file: /cvs/public/parrot/t/op/lexicals.t,v
retrieving revision 1.2
diff -u -r1.2 lexicals.t
--- t/op/lexicals.t 6 Aug 2002 22:42:35 - 1.2
+++ t/op/lexicals.t 8 Aug 2002 20:19:54 -
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 2;
+use Parrot::Test tests => 3;
output_is(<
/* Scratchpad.pmc
* Copyright: (When this is determined...it will go here)
* CVS Info
*
Re: Array vs. PerlArray
On Thu, Aug 08, 2002 at 03:28:18PM -0400, Dan Sugalski wrote: > At 11:00 AM -0700 8/8/02, Steve Fink wrote: > >Oh, yeah. The perl6 summary reminded me: I forgot to mention that this > >would also make $a[-6] (or @a[-6] if you're writing perl6) on a > >4-element array throw an exception instead of autoextending the array, > >wrapping around to a valid element, or exploding in flames. That goes > >for both Array and PerlArray. I don't remember what the currently > >checked-in version does. > > Array and PerlArray shouldn't autoextend that way, I think. I'm not > 100% sure that Array should auto-extend at all--I think I'd rather it > didn't. We need to check with Larry as to whether PerlArrays should > autoextend when using excess negative indices. I don't think I was explaining myself very clearly. The patch implements exactly what you want. No autoextension of any kind for Array. Both Array and PerlArray throw an exception for the @a[-6] case (I'll change it again if Larry says it should do something else, but it's clearly better than the current behavior, which is to dump core.) Personally, I think if it runs out of elements because of a too-negative index, it should pick another array to walk through next. If the magnitude is still too large, keep scanning through more until you run out of arrays. If you're *still* going, scan the process table to find other instances of perl that you can look through. Either that, or autoextend the size of the array to be negative -- if the size is -N, you just ignore the next N values pushed.
Re: never ending story Keyes
In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 6:58 PM +0100 8/8/02, Tom Hughes wrote: > > >Presumably with all keys being PMCs we will just encode the key > >arguments in the opcode name as a k, and kc for constant keys. > > Yep. > > >Likewise, the constant keys will presumably be encoded in the byte > >code much as specified in the PDD and then turned into PMC structures > >in the constant table when the byte code is loaded. > > Yep. One thing I just realised is that we still have a problem of how to tell what a P register used as an key means - it can either mean that the register contains a key, or that it contains an integer or string that is to be used as a key. If we're going to say that a P register is always taken to be a key then does that mean that you can't do this: set P0, "foo" set P2, P1[P0] Obviously that is manufactured, as you could do it with a constant index or an S register but in general terms if you have perl indexing an array or hash by a scalar then then it is likely to be indexing one PMC by another. If the above code was banned then you would have to build the key dynamically instead: new_key P0 size_key P0, 1 ke_set_value P0, 1, "foo" set P2, P1[P0] Or some such, depending on how the key ops wind op working, which is something else we need to think about as the old spec I have here has no way to set any values in the key... Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
A quick reminder to those with commit privs
The dependencies are a bit whacked, still, so... *Please* do a make clean, make, and make test before comitting a patch. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: never ending story Keyes
At 10:33 PM +0100 8/8/02, Tom Hughes wrote: >In message > Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> At 6:58 PM +0100 8/8/02, Tom Hughes wrote: >> >> >Presumably with all keys being PMCs we will just encode the key >> >arguments in the opcode name as a k, and kc for constant keys. >> >> Yep. >> >> >Likewise, the constant keys will presumably be encoded in the byte >> >code much as specified in the PDD and then turned into PMC structures >> >in the constant table when the byte code is loaded. >> >> Yep. > >One thing I just realised is that we still have a problem of how to >tell what a P register used as an key means - it can either mean that >the register contains a key, or that it contains an integer or string >that is to be used as a key. Nope. That's easy. P regs as keys mean they are real keys. Period. Integer lookups need I registers, string lookups aren't done--they need keys. >If we're going to say that a P register is always taken to be a key >then does that mean that you can't do this: > > set P0, "foo" > set P2, P1[P0] Right, you can't do that. >Obviously that is manufactured, as you could do it with a constant >index or an S register but in general terms if you have perl indexing >an array or hash by a scalar then then it is likely to be indexing >one PMC by another. > >If the above code was banned then you would have to build the key >dynamically instead: > > new_key P0 > size_key P0, 1 > ke_set_value P0, 1, "foo" > set P2, P1[P0] Yup. or set the key value to be a PMC which you can then manipulate outside the key struct. (Since we're just storing pointers, and thus can twiddle things without having to store them back in things again) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[COMMIT] PPC JIT
OK, now we have the JIT working on PPC. More opcodes coming. It's not currently using a constant pool but it should. Thanks to Sean for the sync cache code and helping me. Daniel Grunblatt.
[perl #16095] [PATCH] pbc2.pl
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16095]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16095 >
Hi,
actually, this is the 2. attempt to get this in.
It resolves tickets #15712 which seems to be closed to early.
Anyway this patch makes e.g.
$ perl6 -C mops.p6
compile and run natively C.
[ Above command might need a newer perl6, or at least adaption of linked
parrot .o files - patch will follow after bigger rediffs. ]
..
/home/lt/src/parrot-007/languages/perl6/mops.c: In function `main':
/home/lt/src/parrot-007/languages/perl6/mops.c:216: warning: passing arg
2 of `run_compiled' from incompatible pointer type
/home/lt/src/parrot-007/languages/perl6/mops.c:216: warning: passing arg
3 of `run_compiled' from incompatible pointer type
..
M op/s:2.966409
I didn't remove these warnings, because I actually don't know, what
parameters really should be there.
Please apply,
TIA,
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/33373/27460/c23f51/pbc2c.pl.diff
--- pbc2c.plMon Aug 5 08:49:15 2002
+++ /home/lt/src/parrot-007/pbc2c.plMon Aug 5 10:23:07 2002
@@ -235,8 +235,8 @@
return 1;
}
interpreter->code = pf;
-runops(interpreter, pf, 0);
-exit(1);
+run_compiled(interpreter, program_code, program_code);
+exit(0);
}
static opcode_t* run_compiled(struct Parrot_Interp *interpreter, opcode_t
*cur_opcode, opcode_t *start_code){
Request for behaviour definition for assignment to PerlScalar
How should the PerlScalar PMC behave in the following situation? new P0, .PerlScalar new P1, .PerlArray assign P0, P1 The assign opcode will call PerlScalar's set_pmc function, which needs to get a value from P1, so it calls PerlArray's X function?? The two obvious options seem to be: vtable method get_scalar(pmc) vtable method get_value(pmc, context) I would prefer the latter, because it is less Perl-centric, and keeps the sizeof the vtable smaller once other contexts are introduced; however, this is slightly slower, as get_value will need to check its context and act accordingly. If context was an enumeration, a simple switch statement would suffice. In this case, it might be interesting to benchmark the consequences of replacing some of the other get_X vtable functions. e.g. get_integer(pmc) -> get_value(pmc, CONTEXT_INTEGER) Comments, anyone? -- Peter Gibbs EmKel Systems
Re: [perl #16095] [PATCH] pbc2.pl
At 6:32 AM + 8/9/02, Leopold Toetsch (via RT) wrote: >actually, this is the 2. attempt to get this in. >It resolves tickets #15712 which seems to be closed to early. >Anyway this patch makes e.g. > >$ perl6 -C mops.p6 > >compile and run natively C. Whups, sorry. Patch applied. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
