Yet another keyed ops proposal.
Yet another keyed ops proposal[1] Given the Perl6 expression: @a[$i] = @b[1] + $k; This should translate to add P0[I0], P1[1], I2 But having multi-keyed variants of all relevant opcodes would burst our opcode count to #of-keyed-opcodes * #of-key-permutations. That's not feasable. So here is another proposal to implement these ops. 1) The assembler splits above PASM statement into two: keyed P0[I0], P1[1], 0 add Px, Py,I2 2) There is one keyed opcode with all possible key-permutations. 3) For keyed arguments get_pointer_keyed* is called on source operands, non-keyed operands are replaced by 0. get_pointer_keyed* return a PMC* ptr to the store inside the aggregate. 4) For a keyed destination the set_pointer_keyed* is called, preparing the aggregate store and returning that PMC*. 5) These returned pointers are stored in REG_PMC(x) .. REG_PMC(z) (x = 32, y = 33, z = 34) [2] struct PReg hasPMC *registers[NUM_REGISTERS + 3]; 6) The next (add) opcode is modified, so that for all keyed operands a plain PMC operand is emitted, the register number is x..z. Non-keyed operands are as is. This adds one opcode dispatch and increases code size a bit, but we we wouldn't need any additional keyed vtables. And all the checks for passed NULL keys (i.e. no key) aren't necessary. Comments welcome, leo [1] And I hear Dan groaning: ONNTA [2] we could of course reserve regs# 29..31 or 0..2 too for this purpose
RE: [CVS ci] object stuff
At 3:42 PM -0500 12/11/03, Melvin Smith wrote: At 03:05 PM 12/11/2003 -0500, Gordon Henriksen wrote: Melvin Smith [EMAIL PROTECTED] wrote: my $foo = Oracle::Instance::DEV1::db_block_buffers; The namespace lookup in Oracle::Init checks the Oracle config parameters which is external code. All sorts of neat possibilities. :) It is truly remarkable the lengths that Perl programmers seem to be willing go to in order to hide a function call or obscure the existence of an object. :) I'm not an advocate of the feature, but it is novel. Tying is a requirement of Perl, or so Dan has told me. I'm not sure if Larry'll mandate it for perl 6, but I don't care--we're going to be able to have tied namespaces for parrot. We *must*, since that's a very good way of maintaining method caches, handling debugger data watching, and a variety of other interesting tricks one might wish to play without the knowledge of the code you're spying on or interfering with. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Unexpected error...
Can anyone tell me why the following code: .sub _main .local PerlUndef val val = new PerlUndef _foo(bar, val) end .end .sub _foo .param string v1 .param pmc v2 .pcc_begin_return .return 1 .pcc_end_return .end Would produce the following output: cog:~/parrot test.imc wrong param count in file '(unknown file)' near line -1 It seems to be related to passing the PerlUndef as the seoncd parameter...
Re: Unexpected error...
At 02:00 PM 12/12/2003 -0700, Cory Spencer wrote: Can anyone tell me why the following code: .sub _main .local PerlUndef val val = new PerlUndef _foo(bar, val) end .end .sub _foo .param string v1 .param pmc v2 .pcc_begin_return .return 1 .pcc_end_return .end Would produce the following output: cog:~/parrot test.imc wrong param count in file '(unknown file)' near line -1 It seems to be related to passing the PerlUndef as the seoncd parameter... When using prototyped subs and mixing native types with PMC types as arguments, IMCC will get confused. Its because it isn't correctly checking the prototypes. The other problem is that when you use the shorthand version of sub calling (_foo(a,b)), IMCC assumes prototyped. It stems mainly from 2a below. I recommend: (1) Using non_prototyped subs and explicit .pcc_call directives, rather than the shorthand version for now. Until I get some fixes committed you have a couple of other options: (2) Don't mix PMCs and native types in argument lists if you use prototyped subs (2a) If you use PMCs, then IMCC won't coerce a constant argument into a PMC yet. _foo(bar, val) will pass bar as a plain string type, even if the prototype expects a PMC. This is a bug. I expect to have a large revision soon that will address lots of issues in IMCC, but it will most likely be in a new branch (imcc2) so as not to cause complete chaos with the semi-stable version. Then I will try to backpatch some of those fixes into the current IMCC. -Melvin
