[perl #39716] [TODO] Document IMCC's :immediate feature

2006-07-05 Thread via RT
# 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

Re: imcc's

2003-08-01 Thread Leopold Toetsch
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

Re: imcc's "call" vs first class functions

2003-08-01 Thread Leopold Toetsch
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

Re: imcc's "call" vs first class functions

2003-08-01 Thread K Stol
#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&#

RE: imcc's

2003-08-01 Thread Joseph F. Ryan
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&#

imcc's "call" vs first class functions

2003-08-01 Thread Michal Wallace
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

Re: IMCC's bsr handling

2003-02-22 Thread Leopold Toetsch
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

Re: IMCC's bsr handling

2003-02-21 Thread Steve Fink
[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

Re: IMCC's bsr handling

2003-02-08 Thread Leopold Toetsch
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

Re: IMCC's bsr handling

2003-02-07 Thread Leopold Toetsch
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

Re: IMCC's bsr handling

2003-02-07 Thread Leopold Toetsch
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

IMCC's bsr handling

2003-02-06 Thread Steve Fink
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

Re: [perl #17560] [PATCH] imcc's "struct ostat" insufficiently unique

2002-09-24 Thread Leopold Toetsch
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

[perl #17560] [PATCH] imcc's "struct ostat" insufficiently unique

2002-09-24 Thread via RT
# 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

Re: INP ("imcc's not parrot")

2002-08-22 Thread 'John Porter'
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

Re: INP ("imcc's not parrot") (was: Re: imcc hack for perl6 regexes)

2002-08-22 Thread Leopold Toetsch
'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. &

Re: INP ("imcc's not parrot")

2002-08-21 Thread Jerome Quelin
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]

Re: INP ("imcc's not parrot")

2002-08-21 Thread Steve Mosher
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

Re: INP ("imcc's not parrot")

2002-08-21 Thread Dan Sugalski
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

Re: INP ("imcc's not parrot")

2002-08-21 Thread Melvin Smith
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

Re: INP ("imcc's not parrot")

2002-08-21 Thread Sean O'Rourke
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

Re: INP ("imcc's not parrot")

2002-08-21 Thread 'John Porter'
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

Re: INP ("imcc's not parrot")

2002-08-21 Thread 'John Porter'
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

Re: INP ("imcc's not parrot")

2002-08-21 Thread Sean O'Rourke
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

Re: INP ("imcc's not parrot")

2002-08-21 Thread Melvin Smith
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. >

Re: INP ("imcc's not parrot")

2002-08-21 Thread Melvin Smith
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

Re: INP ("imcc's not parrot") (was: Re: imcc hack for perl6 regexes)

2002-08-21 Thread 'John Porter'
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

RE: INP ("imcc's not parrot") (was: Re: imcc hack for perl6 regexes)

2002-08-21 Thread Brent Dax
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

INP ("imcc's not parrot") (was: Re: imcc hack for perl6 regexes)

2002-08-21 Thread John Porter
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