# New Ticket Created by Audrey Tang
# Please include the string: [perl #39716]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39716 >
The IMCC operating in .pir->.pbc mode has a special feature of
running arbitrary Parrot
Joseph F. Ryan <[EMAIL PROTECTED]> wrote:
> I think you should try to implement lamda through .Sub's. Take a look
> at parrot/t/pmc/sub.t for some examples. However, you might not be
> able to rely on IMCC to handle arguments and results so much, since I
> don't think IMCC uses the new cps callin
Michal Wallace <[EMAIL PROTECTED]> wrote:
> Hey all,
> I've got lambda (single-expression anonymous subroutine)
> working in pirate now, but I wasn't sure how to get it
> to do the correct calling convention with IMCC's "call".
I'm pretty sure, th
#x27;t know which invoke op exactly
Correct me if I'm wrong, but IMCC's "call" is translated to a "bsr" op, so
it's just a jump.
I don't know if IMCC already has support for invoke and the like...(I'm not
the expert ;-)
Well, I used this solution, don
t;[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC:
Subject: imcc's "call" vs first class functions
Hey all,
I've got lambda (single-expression anonymous subroutine)
working in pirate now, but I wasn't sure how to get it
to do the correct calling convention with IMCC
Hey all,
I've got lambda (single-expression anonymous subroutine)
working in pirate now, but I wasn't sure how to get it
to do the correct calling convention with IMCC's "call".
For example, pirate turns this:
print (lambda x: x+1)(0) # prints "1\n"
in
Steve Fink wrote:
[Apologies if you receive this twice,
No problemm, the duplicate filter in procmail takes care of it.
On Sat, Feb 08, 2003 at 12:19:35PM +0100, Leopold Toetsch wrote:
When we want these kind of branches, then they must be more high level,
defining all possible branch targe
[Apologies if you receive this twice, but my messages from work
haven't been going through, so I'm resending everything now that I
have my home net connection back.]
On Sat, Feb 08, 2003 at 12:19:35PM +0100, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> > bsr $I0
> >
> >It will complain that
Steve Fink wrote:
bsr $I0
It will complain that it can't fixup the label '$I0'.
I can't imagine, how to get a correct CFG with these kind of register
jump instructions. They are too low level, lacking any hint where they
might jump to.
When we want these kind of branches, then they mus
Steve Fink wrote:
In tracking this down, I also noticed that imcc seems to assume that
you will do a saveall/restoreall pair around bsr calls.
I have now a partial fix for this committed. When imcc sees a bsr *and*
knows the label (all is in one compilation unit) *and* when there is no
save
Steve Fink wrote:
IMCC doesn't handle bsr with non-constant args. A test program would
be something like
L: $I0 = addr L
bsr $I0
It will complain that it can't fixup the label '$I0'.
Yep. That's missing. I'll hvae a look at it. (But you could invoke a
Sub, which is ok IIRC).
In tr
I have lost my network connection from home (hopefully only for
another week or so), and I keep my work/hobby lives separate.
Actually, that's closer to paid/unpaid work, isn't it? :-) So you
won't hear much from me for a while. And my bug reports will be poor.
Like this one:
IMCC doesn't handle b
Simon Cozens (via RT) wrote:
> # New Ticket Created by Simon Cozens
> # Please include the string: [perl #17560]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17560 >
>
>
> It's used by stat.h on Darwin, at least.
A
# New Ticket Created by Simon Cozens
# Please include the string: [perl #17560]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17560 >
It's used by stat.h on Darwin, at least.
diff -d -u -r1.13 imc.h
--- imc.h 22 Se
Dan Sugalski wrote:
> The intent ultimately
> is that you hand an AST, and potentially some rules, to IMCC and it
> creates bytecode for you from it.
That's different, then. Then the whole issue of syntax goes away.
Unless the data interchange format is textual; but even then, you'd
want a syn
'John Porter' wrote:
> Brent Dax wrote:
> No; but statements like "imcc MUST provide access to ALL of parrot's
> (still very dynamic) feature set" and discussions of imcc syntax
> naturally lead to questions of imcc's role in the parrot project.
&
On Jeudi 22 Août 2002 04:59, 'John Porter' wrote :
> And no one
> has suggested that HLL compiler writers shoudl emit befunge.
> Yet. :-)
Since we're talking about this, I have a suggestion... :o)
Jerome
--
[EMAIL PROTECTED]
On Thursday 22 August 2002 01:24, Melvin Smith wrote:
> >for HLL compilers targeting parrot. If y'all want to consider imcc
> >as just another member of that class, fine! But if we tell compiler
> >writers "You should target imcc, not parrot directly", then imcc
> >is clearly in a class by itsel
At 11:02 PM -0400 8/21/02, 'John Porter' wrote:
>Melvin Smith wrote:
>> Good question. The problem is, there is no one but us to answer
>> that question. Or who are we waiting for?
>
>I'd like to think that Dan would just declare on the matter
>and put it to rest. But what I *really* think is t
At 10:59 PM 8/21/2002 -0400, 'John Porter' wrote:
>Sean O'Rourke wrote:
> > However, if we already have a working register
> > allocator and peephole optimizer, I see little reason to write another.
>
>Maybe you're taking a very perl6-centric view. (I don't know.)
>But as someone who's writing an
t know.)
I usually tend to do so, but I'm not sure that I did in this case. My
impression was that IMCC would mostly do low-level things for which
there's basically one right way. Hopefully most language-dependent things
would happen at a higher level. Unless IMCC's quality/ti
Melvin Smith wrote:
> Good question. The problem is, there is no one but us to answer
> that question. Or who are we waiting for?
I'd like to think that Dan would just declare on the matter
and put it to rest. But what I *really* think is that Larry,
or at least Damian, might have something very
Sean O'Rourke wrote:
> However, if we already have a working register
> allocator and peephole optimizer, I see little reason to write another.
Maybe you're taking a very perl6-centric view. (I don't know.)
But as someone who's writing an Tcl-to-parrot compiler
(for (hypothetical) example), I mig
On Wed, 21 Aug 2002, Melvin Smith wrote:
> At 07:00 PM 8/21/2002 -0400, 'John Porter' wrote:
> >No; but statements like "imcc MUST provide access to ALL of parrot's
> >(still very dynamic) feature set" and discussions of imcc syntax
> >naturally
At 07:00 PM 8/21/2002 -0400, 'John Porter' wrote:
>No; but statements like "imcc MUST provide access to ALL of parrot's
>(still very dynamic) feature set" and discussions of imcc syntax
>naturally lead to questions of imcc's role in the parrot project.
>
At 05:44 PM 8/21/2002 -0400, John Porter wrote:
>The outstanding question is, "Is imcc a part of the parrot system?"
>When compiler writers target parrot, do we really want them to target imcc?
>I have a feeling some of you would answer "yes" to that question all too
My answer is "yes", not becau
till very dynamic) feature set" and discussions of imcc syntax
naturally lead to questions of imcc's role in the parrot project.
E.g. "will the perl6 compiler target imcc?"
While imcc is cool and worthy, it probably oughtn't be discussed on
this list untless/until it is a "blessed" member of the parrot suite.
--
John Douglas Porter
John Porter:
# languages. Seems to me that to say that every feature of parrot
# must be exposed in imcc is to imply that all upper-level
# languages must go through imcc -- and that's something I
Let me see if I can follow your logic: IMCC gives access to all Parrot
features, therefore IMCC
eneration, but - as always - there is a but, it should
> supply the infrastructure to generate _all_ possible .pasm code.
If the point is that every feature of parrot should be exposed in
imcc's ui, then that sounds reasonable, since the converse would be
that some features of parrot are hidde
29 matches
Mail list logo