Two other items that ought to be taken into consideration:
- We need an implementation of the :lookahead flag for Rakudo.
(See discussion thread at [1].)
- Per a conversation with Allison and Jonathan at YAPC::EU, it might
be useful to have a :capture flag on parameters and return
valu
# New Ticket Created by Allison Randal
# Please include the string: [perl #58414]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58414 >
Briefly discussed in a phone call with Patrick, Jerry, and chromatic:
Our call
On Wed, 2008-08-20 at 22:20 +0200, Ron Blaschke wrote:
> I think we need a way to select the calling convention for a function,
> similar to, or maybe even part of, the signature. Also, it would be
> good to have a way to select a calling convention when loading a
> library, as a calling conventio
AFAICT, Parrot uses function pointers for NCI. This means NCI uses
whatever calling convention the compiler uses by default.
Unfortunately, there's More Than One Way To Do It.
On Windows, there's the C calling convention (__cdecl), which is usually
used by default by the Visual C++ compiler. The
ped with
the reason: "Using obsolete calling conventions".
The easiest way to fix this might be to change 'schemec' from generating
PASM to
generating PIR.
hello,
Some details of the Parrot calling conventions are a bit unclear. For
the languages/PIR parser implementation, I'd like to check on this
order, instead of postponing the check this in a later phase. My guess
is that the actual checking for mismatches is done in Parrot during
ru
# New Ticket Created by Will Coleda
# Please include the string: [perl #38167]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38167 >
Tests need to be written to verify that HLL mappings are properly
used for :slurpy syn
On Wed, Nov 30, 2005 at 10:57:26AM -0800, Jonathan Sillito wrote:
> What is the status of the todo's mentioned in the BUGS section, who
> is working on these -- I am looking for a place to jump in. Also
> what is the status of the exception subsystem you mentioned?
All those TODOs are for design,
On 11/29/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> I've reviewed pdd03 and brought it back from pdds/clip.
Thanks for reviving this document Chip. Way back when I implemented
some of the original lexical and calling code (like the scratchpad --
may it rest in peace). What is the status of t
Chip Salzenberg wrote:
> Most importantly, I've proposed (but not mandated) a get_params flag
> called "READONLY", which automatically creates a read-only wrapper
> around a PMC parameter.
I'd use READONLY if it existed, though I can get by without it.
Regards,
Roger Browne
I've reviewed pdd03 and brought it back from pdds/clip. Mostly it's
the same as before, albeit with clarifications and a few flag bits
renamed to match PIR. I have made a couple actual changes, though.
On the small side, there's a barest hint of named parameters.
Most importantly, I've proposed
> > >If so, why do we specify S0 here?)
> >
> > Just for convenience.
In most places, I don't use the string. I'd rather just get the PMC.
Regards,
Roger Browne
On Nov 25, 2005, at 23:45, Leopold Toetsch wrote:
The last (and never done correctly) relict of old calling
conventions...
... is gone now. Please consult docs/compiler_faq.pod or this thread
for using get_results instead.
From r10257
Exception handler code: P5 is gone
The compat code
On Tue, Nov 29, 2005 at 04:26:09PM +0100, Leopold Toetsch wrote:
> Coke:
> >If so, why do we specify S0 here?)
>
> Just for convenience.
I appreciate the convenience argument, but given the ease of keyed
access, $P0[0] is pretty darned convenient already. And someday we
may want to pass things t
On Nov 29, 2005, at 8:38 AM, Leopold Toetsch wrote:
Chip Salzenberg wrote:
On Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:
catch_label:
get_results "(...)", Pexcept, Smessage, ... # whatever
This part is now implemented (r10241). (Funnily it did work
immediately :
Leopold Toetsch wrote:
Syntactic sugar, ...
Done - r10243. Again exactly 2 arguments are supported for now:
handler:
.local pmc e
.local string mess
.get_results (e, mess)
Variable decls after the handler label aren't instructions and therefore ok.
See also t/pm
Will Coleda wrote:
On Nov 29, 2005, at 8:38 AM, Leopold Toetsch wrote:
handler:
get_results "(0,0)", P0, S0
Currently, partcl stores extra information in P5[9] - Would it be
available as P0[9] in your example? (If so, is the message still
available as P0[0] ?
Sure. Nothing has
On Nov 29, 2005, at 8:38 AM, Leopold Toetsch wrote:
Chip Salzenberg wrote:
On Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:
catch_label:
get_results "(...)", Pexcept, Smessage, ... # whatever
This part is now implemented (r10241). (Funnily it did work
immediately :
Chip Salzenberg wrote:
On Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:
catch_label:
get_results "(...)", Pexcept, Smessage, ... # whatever
This part is now implemented (r10241). (Funnily it did work immediately :)
Currently exactly these 2 arguments (exception, messag
On Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote:
> Technically an excpetion is kind of an object with some info (TODO) and
> the exception handler is a (limited) continuation:
>
> pmclass Exception_Handler extends Continuation ... # see classes/
Neat.
> catch_label:
>
The last (and never done correctly) relict of old calling conventions...
Technically an excpetion is kind of an object with some info (TODO) and
the exception handler is a (limited) continuation:
pmclass Exception_Handler extends Continuation ... # see classes/
Throwing an exception is
Roger Browne wrote:
in foo handler
in main handler
in main handler
Fixed. Now the main handler catches just once.
Regards,
Roger Browne
Thanks for testing,
leo
Roger Browne wrote:
Leo, did you change the handling of P5? I have some PIR code that works
differently under 0.2.3 and 0.3.0:
The exception object iss still P5 in the handler, no changes here yet.
If you agree that the 0.3.0 behaviour is wrong, I'll file a bug report.
But the MAIN_HANDLER
On 11 July, Leopold Toetsch wrote:
> In the old calling scheme the exception object arrived as P5 in the
> handler. This doesn't really fit into the new scheme.
Leo, did you change the handling of P5? I have some PIR code that works
differently under 0.2.3 and 0.3.0:
.sub "main" @MAIN
push_eh
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37246]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37246 >
* get rid of support for stack calling conventions (.param and friends)
in
On Mon, Jul 11, 2005 at 01:39:08PM +0200, Leopold Toetsch wrote:
> I can see two ways to go:
>
> a) e = interpinfo .INTERPINFO_EXCEPTION
>
> b) via the get_params opcode
>
> The latter would reflect the exception call being an internal
> continuation invocation:
>
>push_eh handler
>
In the old calling scheme the exception object arrived as P5 in the
handler. This doesn't really fit into the new scheme.
I can see two ways to go:
Store the exception (or an array of unhandled exceptions) in the
interpreter and make exceptions available as:
a) e = interpinfo .INTERPINFO_EXC
Jeff Horwitz wrote:
mod_parrot is running into a bit of trouble calling subs written in PIR
with the new calling conventions.
[ ... ]
this may all be premature, as leo's branch is still brand-spanking new,
Yep, very premature. I'd be glad to get some test cases, though.
-jef
mod_parrot is running into a bit of trouble calling subs written in PIR
with the new calling conventions. some initial observations:
* using Parrot_call_sub_* seems to require a get_params opcode (or a
.param), else it dies with "no get_params in sub". this is true
even when cal
On Jun 28, 2005, at 17:23, Klaas-Jan Stol wrote:
hi,
I've been playing a bit with the new set_*/get_* ops that implement
the new calling conventions, according to pdd03.
If the number of passed arguments is larger than the number of
parameters the function takes, an exception is t
hi,
I've been playing a bit with the new set_*/get_* ops that implement the
new calling conventions, according to pdd03.
If the number of passed arguments is larger than the number of
parameters the function takes, an exception is thrown (this is the
overflow case described in
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:04 PM -0500 1/18/05, Sam Ruby wrote:
>> f = "Parrot".find
>> print f("r")
>>
>>Note that I referenced the method as an attribute, and then called
>>it as a function.
> Mmm, syntax! :) Luckily it makes no difference to us at the parrot
> level
Sam Ruby wrote:
Now, what should the code for function f look like? The only
reasonable answer is something along the lines of:
getattribute $P0, P5, 'find'
I doubt that. All languages have different semantics, and we can't
implement them all, because they are conflicting. You, as a compiler
Sam Ruby writes:
> >Mmm, syntax! :) Luckily it makes no difference to us at the parrot
> >level. What that should translate to is something like:
> >
> >$P0 = find_method Parrot_string, "find"
> > # Elided check for failed lookup and fallback to attribute fetch
> >$P1 = make_bound_meth
Luke Palmer wrote:
Sam Ruby writes:
Mmm, syntax! :) Luckily it makes no difference to us at the parrot
level. What that should translate to is something like:
$P0 = find_method Parrot_string, "find"
# Elided check for failed lookup and fallback to attribute fetch
$P1 = make_bound_method(Pa
Dan Sugalski wrote:
At 5:04 PM -0500 1/18/05, Sam Ruby wrote:
Dan Sugalski wrote:
Hi folks.
Welcome back!
Parrot's got the interesting, and somewhat unfortunate, requirement
of having to allow all subroutines behave as methods and all methods
behave as subroutines. (This is a perl 5 thing, but we
At 5:04 PM -0500 1/18/05, Sam Ruby wrote:
Dan Sugalski wrote:
Hi folks.
Welcome back!
Parrot's got the interesting, and somewhat unfortunate, requirement
of having to allow all subroutines behave as methods and all
methods behave as subroutines. (This is a perl 5 thing, but we have
to make it wo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Hi folks.
The lost son is back, welcome.
> The easy one first -- why the object is out-of-band, rather than one
> of the parameters.
> Parrot's got the interesting, and somewhat unfortunate, requirement
> of having to allow all subroutines behave as meth
Dan Sugalski wrote:
Hi folks.
Welcome back!
Parrot's got the interesting, and somewhat unfortunate, requirement of
having to allow all subroutines behave as methods and all methods behave
as subroutines. (This is a perl 5 thing, but we have to make it work)
That is, an invokable PMC may be invok
Hi folks.
Sorry I've been gone so long. Non-p6i stuff's been well past
monopolizing my time. Not much of an excuse, I know, but the Real
World intrudes at the most inconvenient times. Things are, I hope,
easing up a little, though I apologize in advance if I get a little
cranky while I get back
Sam Ruby wrote:
Leopold Toetsch wrote:
class_self."__super"(args)
so again the invocant is the first argument after interpreter.
Believe it or not, I think we are agreeing.
*g*
To invoke a method on an object using Parrot Calling Conventions, P2
needs to be the object used fo
lf."__super"(args)
so again the invocant is the first argument after interpreter.
Believe it or not, I think we are agreeing.
To invoke a method on an object using Parrot Calling Conventions, P2
needs to be the object used for dispatch purposes, and P5 needs to be
the actual object. In man
Sam Ruby wrote:
A few observations, first from an Parrot Internal perspective... in
general, the code for the opcodes tend to do things like the following:
$1->vtable->get_string(interpreter, $1)
Note that the object tends to be repeated as the first argument. It
often the case that the first a
Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Leopold Toetsch writes:
Why do we have the special notion of current_object in the first place?
Why not just pass all in as P5, P6, ...?
I agree that this is the way to go. Especially if we have some marker
somewhere that tells us that
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>> Why do we have the special notion of current_object in the first place?
>> Why not just pass all in as P5, P6, ...?
> I agree that this is the way to go. Especially if we have some marker
> somewhere that tells us that we were ca
Leopold Toetsch writes:
> Why do we have the special notion of current_object in the first place?
> Why not just pass all in as P5, P6, ...?
I agree that this is the way to go. Especially if we have some marker
somewhere that tells us that we were called as a method.
Luke
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The note here is that Parrot's MMD function signature for binary ops
> doesn't match what Python needs. Parrot is:
> void binary_mmd_op(pmc left, pmc right, pmc dest)
> where Python is:
> pmc dest = left.add(pmc right)
Perl6 allows (according
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 7:45 AM +0100 12/11/04, Leopold Toetsch wrote:
>>Thinking more about that it seems that we don't have much chance to keep
>>the current scheme that the destination is passed in.
> I fully expected this to be an issue. Perl 5 and perl 6 are going to
> ha
At 7:45 AM +0100 12/11/04, Leopold Toetsch wrote:
Thinking more about that it seems that we don't have much chance to keep
the current scheme that the destination is passed in.
(This is probably out of order -- I've a lot of mail I'm backed up on
unfortunately, but since it was CC'd directly to me
Leopold Toetsch wrote:
Comments?
leo
As enjoyable as this discussion has been, I'd like to ask that it be put
on hold for a few days. I've nearly got all the previously defined
languages/python/t/basic tests running, and once they are running, I'd
like to do a bit of refactoring and documentat
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ fullquote ]
> A recent discussion with Sam has shown that the current calling
> conventions for overloaded operators don't match Python semantics (nor
> Perl6 when I interpret S06 and S13 correctly).
> The difference is that P
A recent discussion with Sam has shown that the current calling
conventions for overloaded operators don't match Python semantics (nor
Perl6 when I interpret S06 and S13 correctly).
The difference is that Parrot is passing in the destination argument
while these languages are returnin
On Wed, Nov 17, 2004 at 10:35:47PM +, Nicholas Clark wrote:
> On Wed, Nov 17, 2004 at 02:47:09PM -0700, Patrick R. Michaud wrote:
>
> > BTW, it may be very possible for me to write the p6ge generator so
> > that it can be switched between the PIR and bsr/ret calling conv
0500
1.988304
[EMAIL PROTECTED] pmichaud]$ parrot -Oc pmfact.imc
500500
0.933195
[EMAIL PROTECTED] pmichaud]$ parrot -Oc pmfactbsrtail.imc
500500
0.221527
[EMAIL PROTECTED] pmichaud]$ perl -e 'print 0.93 / 0.22, "\n"'
4.22727272727273
> What about calling back into PIR code
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> BTW, it may be very possible for me to write the p6ge generator so
> that it can be switched between the PIR and bsr/ret calling conventions,
> so we don't need to resolve this entirely now. And we could then benchmark
> the
On Wed, Nov 17, 2004 at 02:47:09PM -0700, Patrick R. Michaud wrote:
> BTW, it may be very possible for me to write the p6ge generator so
> that it can be switched between the PIR and bsr/ret calling conventions,
> so we don't need to resolve this entirely now. And we could then b
> calculated 1000 times:
>
> PIR 1.1 s
> bsr/ret 2.4 s
> PIR/tailcall 0.2s
>
> Unoptimized Parrot, default i.e. slow run core.
BTW, it may be very possible for me to write the p6ge generator so
that it can be switched between the PIR and bsr/ret calling convention
On Wed, Nov 17, 2004 at 10:03:14PM +0100, Leopold Toetsch wrote:
> As already stated, I don't consider these as either light-weight nor
> faster. Here is a benchmark.
>
> Below are 2 version of a recursive factorial program. fact(100) is
> calculated 1000 times:
>
> PIR 1.1 s
> bsr/re
At 5:08 PM -0500 11/17/04, Dan Sugalski wrote:
Chopping out the multiplication (since that's a not-insignificant
amount of the runtime for the bsr/ret version) gives:
PIR:
real0m3.016s
user0m2.990s
sys 0m0.030s
bsr/ret
real0m0.344s
user0m0.340s
sys 0m0.010s
and with -Oc, f
At 11:07 PM +0100 11/17/04, Leopold Toetsch wrote:
Please no premature optimizations.
It's important to note that
premature optimization == things Leo disapproves of
The bsr/ret version of things is fine. In the absolute best case
it'll be the same speed as tail calls, and in normal cases it'll
At 10:03 PM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
[ this came up WRT calling conventions ]
I assume he's doing bsr/ret to get into and out of the sub, which
is going to be significantly faster.
Who says that?
As already stated, I don't consider these as either li
Patrick R. Michaud wrote:
On Wed, Nov 17, 2004 at 10:03:14PM +0100, Leopold Toetsch wrote:
[EMAIL PROTECTED] pmichaud]$ parrot pmfact.imc #PIR
500500
5.819842
[EMAIL PROTECTED] pmichaud]$ parrot pmfactbsr.imc #bsr/ret
500500
2.010935
Ok:
$ parrot pmfactbsr.imc
500500
3.459947
$ parrot -Oc pmf
Dan Sugalski wrote:
[ this came up WRT calling conventions ]
I assume he's doing bsr/ret to get into and
out of the sub, which is going to be significantly faster.
Who says that?
As already stated, I don't consider these as either light-weight nor
faster. Here is a benchmark.
B
At 12:58 AM -0800 11/9/04, Jeff Clites wrote:
On Nov 8, 2004, at 11:15 AM, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that
[EMAIL PROTECTED] wrote:
On Nov 8, 2004, at 11:15 AM, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
On Nov 8, 2004, at 11:15 AM, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully specified and imple
At 9:39 PM +0100 11/8/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
That flaw is caused by the assymmetry of opcodes, or by indirect
register usage if opcodes like bare C
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, aesthetics and making up for a flaw in the implementation of
> how IMCC tracks opcodes and registers.
That flaw is caused by the assymmetry of opcodes, or by indirect
register usage if opcodes like bare C.
But as that shall not be fixed now, lets' k
At 2:15 PM -0500 11/8/04, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully specified and imple
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The calling conventions and code surrounding them will *not* change
> now. When all the sub stuff, and the things that depend on it, are
> fully specified and implemented... *then* we can consider c
and we have a working implementation is
premature optimization. And screwing around with stuff that works
when there's stuff that doesn't is misdirected effort.
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
> [calling convention change snippage]
> I've already said no changes to the calling conventions, quite a
> while ago.
This doesn't really change calling convention, it ch
Dan~
On Mon, 8 Nov 2004 13:23:36 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, aesthetics and making up for a flaw in the implementation of
> how IMCC tracks opcodes and registers.
>
> Neither of those are sufficient, individually or together.
It feels to me like you are dismissing Leo'
At 7:17 PM +0100 11/8/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
... Got a better reason?
And there is of course:
4) invoke's (and friends) register usage is assymmetrical and ugly.
[s
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
> [calling convention change snippage]
> ... Got a better reason?
And there is of course:
4) invoke's (and friends) register usage is assymmetrical and ugly. It's
like defining:
set 5 # set I0, 5
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
I've already said no changes to the calling conventions, quite a
while ago. I don't see inconvenience in the register allocation code
as a reason to change it. Got a better reason?
We now have dedicated PMC* pointers in the context that hold
current_cont, current_sub, and current_object. This is necessary to
create traceback information. But subroutine and return opcodes are not
adapted yet.
We have e.g.:
invoke # implicitely P0 and use P1 for return
If you have PASM programs or hand-crafted calls, be sure to set
registers I0 .. I4 for calls and returns according to
docs/pdds/pdd03_calling_conventions.pod.
Code that doesn't obey these rules will definitely break.
leo
Before going the big step of implementing the indirect register frame,
I'd like to clarify argument passing for calls and returns.
Now we are placing arguments or return values in registers according to
PDD03 and the other end has immediately access to the placed values,
because the register fi
Mattia Barbon <[EMAIL PROTECTED]> wrote:
> Hello,
> crrently argument count is passed in I3. A comment in untils.c
> near foldup says that:
> TODO - IMCC and PDD 3 aren't yet in conformance.
The TODO is obsolete. IMCC is fixed (at least until it comes to overflow
which isn't handled everywh
Hello,
crrently argument count is passed in I3. A comment in untils.c
near foldup says that:
TODO - IMCC and PDD 3 aren't yet in conformance. This uses the current
IMCC setup, but should be changed as soon as IMCC modified to the
correct calling conventions.
while pdd03
Will Coleda <[EMAIL PROTECTED]> wrote:
> bash-2.05a$ make exit
> ../../../parrot ../tcl.pbc exit.tcl
> branch_cs: illegal resume offsetmake: *** [exit] Error 1
This is very likely an undefined label. imcc tries to find that at
runtime (it could have come out from eval) and fails.
> So, I'm tryin
newsub foo_sub, .Sub, __foo
>
> .pcc_begin prototyped
> .arg $S1
> .pcc_call foo_sub
> tellmeagainwhyineedthislabel:
> .result $S1
> .pcc_end
>
>
> If I can't explicitly create foo_sub if I'm in the middle of __foo, how
> do I recurse using calling conv
eda writes:
If I can't explicitly create foo_sub if I'm in the middle of __foo,
how
do I recurse using calling conventions
You could use P0, which holds the subroutine object. Like using &_ in
Perl 6.
Luke
--
Will "Coke" Coledawill at coleda
dot com
ototyped
> .arg $S1
> .pcc_call foo_sub
> tellmeagainwhyineedthislabel:
> .result $S1
> .pcc_end
>
>
> If I can't explicitly create foo_sub if I'm in the middle of __foo, how
> do I recurse using calling conventions
You could use P0, which holds the subroutine object. Like using &_ in
Perl 6.
Luke
label:
.result $S1
.pcc_end
If I can't explicitly create foo_sub if I'm in the middle of __foo, how
do I recurse using calling conventions?
And, in my defense, all this code worked a few months ago. =-)
On Monday, January 19, 2004, at 01:54 PM, Leopold Toetsch wrote:
Will Coleda &l
Will Coleda <[EMAIL PROTECTED]> wrote:
> (has a .end) Yup.
> Managed to shrink it down to:
> .pcc_sub __interpret prototyped
>newsub P1, .Sub, __interpret
>.pcc_begin_return
>.return 0
>.pcc_end_return
> .end
Two problems: You are overriding the already existing Sub with that nam
Will Coleda <[EMAIL PROTECTED]> wrote:
> 1 .pcc_sub __interpret prototyped
> 2# An array of commands to interpret.
> 3.param PerlArray orig_commands
Please note that between .pcc_sub and .param nothing is allowed, not even
a comment.
leo
(has a .end) Yup.
Managed to shrink it down to:
.pcc_sub __interpret prototyped
newsub P1, .Sub, __interpret
.pcc_begin_return
.return 0
.pcc_end_return
.end
It appears that creating a Sub that refers to the sub you're currently
in is the trigger. If I change the sub name to "foo", it co
At 12:55 PM -0500 1/19/04, Will Coleda wrote:
Though the file contains:
1 .pcc_sub __interpret prototyped
2# An array of commands to interpret.
3.param PerlArray orig_commands
...
392 DONE:
393.debug("final retval is '")
394.debug(retval)
395.debug(
(Thanks for the quick response on the last email)
I have another problem. I have a 405-line file (containing a single
.pcc_sub) that is being included from my main .imc.
I get:
error:imcc:pcc_return not inside pcc subroutine
in file 'lib/interpret.imc' line 397
included from 'tcl.imc'
Sync up with CVS and read the changes in PDD03. I'll be addressing some
of the HLL issues (including validation and named parameter lists) soon,
since getting those nailed down would be reasonably useful.
Dan
--"it's like
On Sun, 16 Nov 2003, Melvin Smith wrote:
> The situation we have now is: Parrot is a VM, and technically we could
> just punt the whole calling convention issue to a high level languages forum
> (parrot-languages if there was one) or something, but sadly that wouldn't
> work, because currently the
My unanswered question below was legitimate, but if you insist...
Perhaps another register can hold the number of problems
with this calling convention.
>Dan Sugalski wrote:
>> 1) The changes I proposed are going in. We get arg counts for I/S/N
>> registers if they're used.
>
>What purpose
I'll admit I sometimes can't think that far ahead to see all of the
problems, but when I have problems sitting in front of me, I can
usually solve them.
The situation we have now is: Parrot is a VM, and technically we could
just punt the whole calling convention issue to a high level languages foru
when quoting. This bit, specifically:
Everyone can cope. (You may, if you choose, whine about it for a
bit--that's OK, if somewhat unbecoming)
Rather than whining, I'm reworking IMCC so we can support multiple
parallel calling conventions and select a specific one by a pragma.
We can
At 4:00 PM -0800 11/16/03, Joe Wilson wrote:
Dan Sugalski wrote:
1) The changes I proposed are going in. We get arg counts for I/S/N
registers if they're used.
What purpose do these individual I/S/N arg counts serve exactly?
You missed a bit when quoting. This bit, specifically:
Everyone can cop
Dan Sugalski wrote:
> 1) The changes I proposed are going in. We get arg counts for I/S/N
> registers if they're used.
What purpose do these individual I/S/N arg counts serve exactly?
To simply check how many arguments are passed to a function you would
need to get the sum of the number of I/S/N
Okay, I've lost any free time I might have and the discussion's
gotten to the point where it's obvious that we're not going to get
anywhere. So, this is what we're going to do:
1) The changes I proposed are going in. We get arg counts for I/S/N
registers if they're used. Everyone can cope. (You
At 11:57 AM -0500 11/14/03, Gordon Henriksen wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
The easy situation is when argument counts change, but the
hard situation is
when semantics have changed. In that case we have to have some
sort of version requirement in the bytecode.
Best practice I'v
1 - 100 of 175 matches
Mail list logo
