Patch applied to trunk in r20879.
On Aug 25, 2007, at 10:47 PM, James Keenan via RT wrote:
On Sun Aug 19 08:55:30 2007, coke wrote:
This was part of the gmake extensions that we (can) support during
makefile-generation time; added because there was there no cross-
platform syntax that I knew of that we could use in all of the
va
$ ack addprefix | wc -l
2
$ ack -a addprefix | wc -l
3
ack, by default, searches a subset of files.
On Aug 20, 2007, at 9:24 PM, James E Keenan wrote:
Will Coleda wrote:
That said, I don't see '$(basename ...)' used anywhere in the code
base. The other three (addprefix, wildcard, and notdir)
Will Coleda wrote:
That said, I don't see '$(basename ...)' used anywhere in the code base.
The other three (addprefix, wildcard, and notdir), are all used by Tcl
(and only by Tcl)
I don't see where 'addprefix' or 'notdir' is used outside of where
they're defined in Parrot::Configure::Ste
This was part of the gmake extensions that we (can) support during
makefile-generation time; added because there was there no cross-
platform syntax that I knew of that we could use in all of the
various makes we have to support.
See perldoc lib/Parrot/Configure/Step.pm look for
'expand_gm
I have been writing tests for previously untested statements in
Parrot::Configure::Step. In genfile(), there is the following block:
# documented as removing any .-based suffix
if (
$line =~ s{\$ \( basename \s+ ([^)]+) \)}{
join (' ',
conditions in various subroutines: file_checksum();
genfile(); run_command(); cc_build(); cc_run(); cc_run_capture();
check_progs(); slurp(). As with item (1), each subroutine should be
checked for current instances of usage during configuration.
3. There has been talk in other RT threads
y any unit tests. Whoever works
on this should see whether this subroutine is called anywhere in
the lib/ or config/ hierarchies.
2. Branches and conditions in various subroutines: file_checksum
(); genfile(); run_command(); cc_build(); cc_run(); cc_run_capture
(); check_progs(); slurp()
chromatic wrote:
On Tuesday 21 November 2006 18:36, James E Keenan wrote:
3 identically named subroutines: 2 in modules and 1 in a script. And
all 3 will be in modules as I'm planning to refactor much of pmc2c.pl
into a module called Parrot::Pmc2c::Utils. (For drafts of these
revi
On Tuesday 21 November 2006 18:36, James E Keenan wrote:
> 3 identically named subroutines: 2 in modules and 1 in a script. And
> all 3 will be in modules as I'm planning to refactor much of pmc2c.pl
> into a module called Parrot::Pmc2c::Utils. (For drafts of these
> re
Note the results:
[parrot] 502 $ ack 'sub gen_c'
lib/Parrot/Pmc2c.pm
1221:sub gen_c {
lib/Parrot/Pmc2c/Library.pm
134:sub gen_c {
tools/build/pmc2c.pl
821:sub gen_c {
3 identically named subroutines: 2 in modules and 1 in a script. And
all 3 will be in modules as I'm plann
On Oct 18, 2006, at 4:27 PM, Jerry Gay (via RT) wrote:
currently, this policy does not ignore subs which exit or die... it
forces the addition of a return statement in these subs. yuck. this
policy will be disabled until this is fixed.
~jerry
Fixed in Perl::Critic svn r737. This will appear i
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40564]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40564 >
currently, this policy does not ignore subs which exit or die... it
forces the addition of
William Coleda <[EMAIL PROTECTED]> wrote:
> After the returncc, is it possible to indicate what routine we are
> returning into?
Good idea. Implemented (location printing needs cleanup, so just a
current hack).
leo
Huh. That's annoying. attached trace for readability.
William Coleda wrote:
0 set P16, PMC_C[2]- P16=PMCNULL,
3 set I0, 1- I0=0,
6 set I1, 0- I1=0,
9 set I2, 0- I2=0,
12 set I3, 0- I3=1,
15 set I4, 0- I4=0,
18 s
Given IMC like:
.sub main @MAIN
$P1 = whee()
print $P1
.end
.sub whee
$P2 = new PerlString
$P2 = "leo\n"
.return ($P2)
.end
We get a trace like:
0 set P16, PMC_C[2]- P16=PMCNULL,
3 set I0, 1- I0=0,
6 set I1, 0- I1=0,
9 set I2, 0- I2=0,
1
btw, thanks to whoever fixed macros so that they could be defined outside of .sub's.
Very handy.
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 says:
.
On Dec 28, 2003, at 1:42 AM, Leopold Toetsch wrote:
Joe Wilson <[EMAIL PROTECTED]> wrote:
Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on
Joe Wilson <[EMAIL PROTECTED]> wrote:
> I implemented the same variable argument function "varargs_adder"
> in both Perl 5 (addit.pl) and Parrot (f4.pasm).
I've put in the addit benchmarks and some variations of it:
- addit.pl ... as of Joe Wilson
- addit.pasm .. ditto but use PerlArray
- addit.im
Joe Wilson <[EMAIL PROTECTED]> wrote:
> Perl's arrays do indeed accept mixed data types (see example below).
Perl's Arrays take SV's. Please use a PerlArray instead of SArray.
Parrot (still built unoptimized) is significantly faster then perl5 on this
test.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> SArray and Array PMCs, in addition to being sparse (which has some
> overhead), allow you to really store PMC *, STRING *, INTVAL, and
> NUMVAL entries, which means that each slot in an SArray and Array
> needs to have a flag on it that says what data type
Joe Wilson <[EMAIL PROTECTED]> wrote:
> $ time parrot -j f6.pasm
> 21001094.10 (note: wrong result and slower with jit)
I don't get a slow down nor a wrong result (i386/linux). On what
platform do you test?
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Interesting. However... the two programs aren't equivalent. You're
> using constant values and putting results onto an existing data
> structure in perl, so true 'equivalence' requires a few changes to
> the source. With those in place, I get the following:
At 6:34 PM -0800 12/27/03, Joe Wilson wrote:
I used the default ./configure options (no idea what they were).
The default's no optimization. At this point we're in development, so
having a build that can be meaningfully thrown into a debugger's more
important than the ultimate speed. (Besides, if
I used the default ./configure options (no idea what they were).
But more to the point - no one explained why the Parrot JIT ran
the code 3 times slower and arrived at the wrong result.
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 27, 2003 at 06:17:34PM -0500, Dan Sugalski wrote:
On Sat, Dec 27, 2003 at 06:17:34PM -0500, Dan Sugalski wrote:
> Also, you might want to make sure you've built Parrot with
> optimizations on. By default we don't enable GCC's -O to do any
> optimization, and that does slow things down a bunch. On the other
> hand, it makes debugging a whole lot
At 6:17 PM -0500 12/27/03, Dan Sugalski wrote:
[reasons and some excuses for slowdowns snipped]
None of this, I should point out, in any way means we don't have a
problem, because we do. Things are *not* as fast as they should be,
and we need to address it. (And I'm glad you've brought it up, too
At 2:38 PM -0800 12/27/03, Joe Wilson wrote:
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
Joe Wilson writes:
> Dan Sugalski:
> > 2) Parrot's Array and SArray values all accept mixed-type data, which
> > perl's arrays do *not* do, and as such have some extra speed hits
> > that perl arrays don't.
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Joe Wilson writes:
> > Dan Sugalski:
> > > 2) Parrot's Array and SArray values all accept mixed-type data, which
> > > perl's arrays do *not* do, and as such have some extra speed hits
> > > that perl arrays don't.
> >
> > What do you mean?
> > Perl'
Joe Wilson writes:
> Dan Sugalski:
> > 2) Parrot's Array and SArray values all accept mixed-type data, which
> > perl's arrays do *not* do, and as such have some extra speed hits
> > that perl arrays don't.
>
> What do you mean?
> Perl's arrays do indeed accept mixed data types (see example belo
Dan Sugalski:
> 2) Parrot's Array and SArray values all accept mixed-type data, which
> perl's arrays do *not* do, and as such have some extra speed hits
> that perl arrays don't.
What do you mean?
Perl's arrays do indeed accept mixed data types (see example below).
$ cat addit2.pl
#!/usr/bin/p
At 4:16 PM -0500 12/27/03, Dan Sugalski wrote:
1) Perl's data structures (the equivalent of PMCs) been heavily
optimized, to date Parrot's haven't been
2) Parrot's Array and SArray values all accept mixed-type data,
which perl's arrays do *not* do, and as such have some extra speed
hits that per
At 12:19 PM -0800 12/27/03, Joe Wilson wrote:
I implemented the same variable argument function "varargs_adder"
in both Perl 5 (addit.pl) and Parrot (f4.pasm).
The variable arguments can be strings, integers or floats
(I wanted to excercise dynamic variable behavior).
I called the function 50 t
I implemented the same variable argument function "varargs_adder"
in both Perl 5 (addit.pl) and Parrot (f4.pasm).
The variable arguments can be strings, integers or floats
(I wanted to excercise dynamic variable behavior).
I called the function 50 times in a loop to benchmark it.
The results
On Thu, 7 Aug 2003, Dan Sugalski wrote:
> > haskell_parser -> ast -> pirate -> parrot_code --> imcc -> pbc
> > ^
> > |
> > parrot_code__templates
> >
> >
> >S
At 1:35 PM -0400 8/5/03, Michal Wallace wrote:
On Tue, 5 Aug 2003, Joseph Ryan wrote:
>Okay, I don't have a good syntax in mind yet,
>the point is it's a template language and you
>can subclass/override/extend the template.
>Maybe there's no syntax and it just uses
>cleanly coded classes in s
On Tue, 5 Aug 2003, Joseph Ryan wrote:
> >Okay, I don't have a good syntax in mind yet,
> >the point is it's a template language and you
> >can subclass/override/extend the template.
> >Maybe there's no syntax and it just uses
> >cleanly coded classes in some oo language.
> >Or perl6 with it's g
- Original Message -
From: "Joseph Ryan" <[EMAIL PROTECTED]>
To: "Michal Wallace" <[EMAIL PROTECTED]>
Cc: "K Stol" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, August 05, 2003 12:24 AM
Subject: Re: generic code generator? [
On Tue, 5 Aug 2003, Dan Sugalski wrote:
> The original thought was to use the new perl 6 grammar engine/code
> to do this, but I think it'll be a while before that's ready to go.
I think perl6 is definitely the way to go, once it's ready.
BTW, what's the deal with Bundle::Perl6? I tried installi
On Tue, 5 Aug 2003 12:48, Michal Wallace wrote:
> It does seem like there are some snags getting
> languages to talk to each other, even with the
> calling conventions, but even so, I'm even more
> convinced now that a generic, overridable
> code-generator is the way to go.
>
> It seems to me that
Michal Wallace wrote:
On Sun, 3 Aug 2003, K Stol wrote:
What do you think? Want to try squishing pirate/python
and pirate/lua together? :)
Yeah, I like the idea. Let's try this out.
Well, I finished reading your report[1] and
posted some of my (rather unorganized) thoughts
up at
At 11:09 PM -0400 8/4/03, Michal Wallace wrote:
On Tue, 5 Aug 2003, Stephen Thorne wrote:
Thus the code generator is best suited to be in a language that can
be run from within the parrot machine, otherwise statements like
'eval()' would not be possible without binding parrot to a
non-portable
On Tue, 5 Aug 2003, Stephen Thorne wrote:
> > It seems to me that if we want to maximize the
> > number of languages using it, the generic
> > compiler shouldn't depend on anything but
> > C and parrot... But until we get it working,
> > I'd like to stick to a dynamic language like
> > python/perl
On Sun, 3 Aug 2003, K Stol wrote:
> > What do you think? Want to try squishing pirate/python
> > and pirate/lua together? :)
>
> Yeah, I like the idea. Let's try this out.
Well, I finished reading your report[1] and
posted some of my (rather unorganized) thoughts
up at [2]
It does seem like t
On Sun, 3 Aug 2003 19:25, Michal Wallace wrote:
> On Fri, 1 Aug 2003, K Stol wrote:
> Really, there's a ton of overlap between the various
> "high level" languages that parrot wants to support.
> Maybe we could put together a generic code generator
> that everyone could use? Obviously, it would hav
On Sun, 3 Aug 2003, K Stol wrote:
> At this moment, I'm looking at a new version of Lua, the previous
> 'pirate' compiled (well, sort of :-) Lua 4 Lua 5 has some features,
> such as coroutines (If I remembered well) and all kinds of neat
> stuff for which Parrot has built-in support (and it droppe
- Original Message -
From: "Michal Wallace" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, August 03, 2003 2:25 AM
Subject: generic code generator? [was: subroutines and python status]
> On Fri, 1 Au
On Fri, 1 Aug 2003, K Stol wrote:
> > From: "Leon Brocard" <[EMAIL PROTECTED]>
...
> > I don't like things becoming dead-ends. How much work do you think
> > it'd be to extend it some more and update it to latest Lua?
...
> 2: I misdesigned the code generator; that is, at the point where I
> could
On Fri, 1 Aug 2003, Dan Sugalski wrote:
> At 11:04 PM +0200 7/31/03, Leopold Toetsch wrote:
> >Luke Palmer <[EMAIL PROTECTED]> wrote:
> >> You mind submitting a patch to put this in the languages/pirate
>
> >I'd appreciate that very much. Pie-thon, here we come ...
>
> As would I. If you're willin
At 11:04 PM +0200 7/31/03, Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
You mind submitting a patch to put this in the languages/pirate
I'd appreciate that very much. Pie-thon, here we come ...
As would I. If you're willing, Michal, we can check it in and get you
CVS repository
- Original Message -
From: "Leon Brocard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 01, 2003 1:30 AM
Subject: Re: subroutines and python status
> K Stol sent the following bits through the ether:
>
> > Actually, I named my li
K Stol sent the following bits through the ether:
> Actually, I named my little project "pirate" (s.
> http://members.home.nl/joeijoei/parrot for this) already, but it's a bit of
> a dead end already (although I learnt much of it), so I don't mind.
Quick, we need more parrot jokes...
I don't li
- Original Message -
From: "Melvin Smith" <[EMAIL PROTECTED]>
To: "Luke Palmer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 31, 2003 3:33 PM
Subject: Re: subroutines and python status
> At 01:51 PM
Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
You mind submitting a patch to put this in the languages/pirate
I'd appreciate that very much. Pie-thon, here we come ...
Speaking of adding new projects to languages, I have a partially complete
JVM->PIR translator done. It's comp
At 01:51 PM 7/31/2003 -0600, Luke Palmer wrote:
You mind submitting a patch to put this in the languages/pirate
directory of the parrot distro? I'd like to stay up to date, and
probably do some work (as, I imagine, would others).
I'd like to officially complain that "pirate" is a cooler name than
At 02:54 PM 7/31/2003 -0400, Michal Wallace wrote:
Actually, between imcc and the python compiler
module, it's not nearly as hard as I thought it
would be. So far, I think the parrot version is
actually a lot simpler than the python compiler,
just because imcc is doing so much of the work.
Leo and
Luke Palmer <[EMAIL PROTECTED]> wrote:
> You mind submitting a patch to put this in the languages/pirate
I'd appreciate that very much. Pie-thon, here we come ...
> Luke
leo
Michal Wallace <[EMAIL PROTECTED]> wrote:
> .sub __start__
>call __main__
> .end
> .sub __main__
> .sub _f
> print ":)"
> ret
>.end
>$I0 = addr _f
>print $I0
>end
> .end
> That prints ":)", followed by the address,
No, can't imagine that:
$ parrot -o- pir
> > One of my questions is, why do you make so many PerlNums when there
> > isn't a trace of a floating point number to be found...?
>
> Because I didn't read the docs that said PerlNum means "float". :)
> I'll switch it to PerlInt (or maybe int?) later...
Yeah, all your auxillary data; i.e. th
On 31 Jul 2003, Luke Palmer wrote:
> > It now runs amk's euclid.py perfectly now.
> > Do we have a way to compare the speed vs python? :)
> We just modify it to repeat 100,000 times or so, and compare that way.
Oh, duh. :)
> Which I did. Parrot comes in about 3x slower than python on euclid.
>
On Thu, 31 Jul 2003, Brent Royal-Gordon wrote:
> Michal Wallace:
> > I can store all my subroutine definitions in
> > a list or something and then dump them out
> > after the "__main__" routine.
>
> That seems to be the way to do it, speaking as someone who's working
> on a Perl 5-to-PIL converter
On Thu, 31 Jul 2003, Leopold Toetsch wrote:
> You can do that:
> .sub __main__
>bsr _main
>end
> .end
> .sub _main
...
> So you have just to emit code, to call your real main at the beginning.
Well that worked, and even let me get rid of the
endsub label:
.sub __start__
call __main
> Hey all,
>
> I'm trying to get functions working
> in python, and I'm not sure the best way
> to do this.
>
> What seems natural to me is to define
> subroutines in the middle of the code
> as I walk the parse tree:
>
> .sub __main__
> g
Michal Wallace wrote:
Hey all,
What seems natural to me is to define
subroutines in the middle of the code
as I walk the parse tree:
You can do that:
.sub __main__
bsr _main
end
.end
.sub _main
.sub _f
print ":)\n"
ret
.end
.sub _g
pr
Michal Wallace:
> I can store all my subroutine definitions in
> a list or something and then dump them out
> after the "__main__" routine. Is that the
> right approach? It seems strange to me,
> but I'm new at this.
That seems to be the way to do it, speaking as someone who's working on a
Perl 5-
Hey all,
I'm trying to get functions working
in python, and I'm not sure the best way
to do this.
What seems natural to me is to define
subroutines in the middle of the code
as I walk the parse tree:
.sub __main__
goto endsub
.sub _f
print ":(\n"
All~
Jonathan Sillito wrote:
The patch looks pretty good to me. Here is a proposal for an alternative
inheritance hierarchy. Invocable, the root of the hierarchy, is basically a
sub that is not a closure (i.e. *no* context at all, just an address).
pmclass Invocable { # I called this sublite befor
The patch looks pretty good to me. Here is a proposal for an alternative
inheritance hierarchy. Invocable, the root of the hierarchy, is basically a
sub that is not a closure (i.e. *no* context at all, just an address).
pmclass Invocable { # I called this sublite before
/* SELF->data is always N
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #22745]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22745 >
Attached is a first try to unify the various sub types, structures and
classes.
- s
On Thu, 2002-04-25 at 18:14, Dan Sugalski wrote:
> Okay, fair enough. Subs in general will have the following potential
> information:
>
> *) A pointer to a template lexical scratchpad
> *) A pointer to a *real* scratchpad (for co-routines and continuations)
> *) A pointer to a parent lexical sc
Andrew J Bromage <[EMAIL PROTECTED]> writes:
> G'day all.
>
> On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
>
>> [ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
>
> Understood.
>
>> Isn't compiler convienience a (the?) major issue here?
>
> I wouldn't cal
G'day all.
On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
> [ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
Understood.
> Isn't compiler convienience a (the?) major issue here?
I wouldn't call it a "major issue". I think of it as a constraint.
The ma
G'day all.
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
> Welcome to my world. They're all bad ideas in some way or, rather,
> they're all equally as good.
That's definitely true. :-)
I should also point out that for Perl, all this is moot. Current Perl
semantics require tha
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
> At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
> >G'day all.
> >
> >On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
> >
> >> We're going
>>OO code is full of subs which a) are called very often and b) look
>>like this:
>>
>> sub code
>> {
>> my $self = shift;
>> return $self->{CODE};
>> }
>>
>> sub body
>> {
>> my $self = shift;
>> if (@_) {
>> $self->{BODY} =
At 11:05 AM -0400 4/29/02, Melvin Smith wrote:
> >Just for chuckles, I went and benchmarked things, as meaningless
>>numbers are useful to have. With my current GCC3/-O3 build of parrot,
>>the cost to do 10,000,000 sets of saves is as follows:
>>
>>save all: 5.3 sec usertime
>>save 1: 2.6 sec
AIL PROTECTED]> To: Andrew J Bromage
<[EMAIL PROTECTED]>, [EMAIL PROTECTED]
cc:
04/29/2002 10:53 Subject: Re:
At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
>G'day all.
>
>On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
>
>> We're going caller-save. I think I made this declaration before, but
>> now it's backed up with pure PDD goodness. :)
>
>The first thing to realise is that this vi
dle the recompilation
dependencies. After all, we don't want existing code to break every
time someone does a CPAN upgrade.
Of course the ultimate solution is the old MIPS register allocation
at link time approach, but I assume that for a dynamic language like
Perl this is a bad idea. :-)
>
> > Actually, I _was_ saying we shouldn't do caller-save (except
> > possibly for a small number of registers designated for the
> > purpose).
>
> Remember that the caller only has to save the stuff that is important
> to it, after all, anything that might be of importance to *its*
> callers will
x27;t trivial, it will
> still have to save lots of registers, so it really doesn't matter
> who does it.
Well factored code tends to have plenty of small, trivial
subroutines... And in the case of non trivial subs then the register
saving overhead will be the same whereever it happens. T
I'd have to agree with Andrew. With only 32 registers of each type in
Parrot (the last time I checked) using most of them for function arguments
would cause much needless register copying within each function.
Surely 8 registers of each type would be more than sufficient for
function paramet
G'day all.
On Sun, Apr 28, 2002 at 10:26:12PM -0400, Melvin Smith wrote:
> Ok, agreed. Sorry for speaking for you.
Not a problem. Having people try to speak for you can actually
clarify your thoughts, or so I've found.
> Regarding performance, a decent compiler should be able to
> analyze a m
At 12:09 PM 4/29/2002 +1000, Andrew J Bromage wrote:
>G'day all.
>
>On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
>
> > I don't think I and Andrew were saying we shouldn't do caller-save, we
> > were just discussing that the calling convention (read activation record of
> > a subro
G'day all.
On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
> I don't think I and Andrew were saying we shouldn't do caller-save, we
> were just discussing that the calling convention (read activation record of
> a subroutine) should support the common optimization of passing args
>
At 11:44 AM 4/28/2002 -0400, Dan Sugalski wrote:
>At 7:00 AM +0100 4/27/02, Piers Cawley wrote:
>>Andrew J Bromage <[EMAIL PROTECTED]> writes:
>>
>>> G'day all.
>>>
>>> On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
>>>
I also vote for reserving some caller-save registers to
G'day all.
On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
> We're going caller-save. I think I made this declaration before, but
> now it's backed up with pure PDD goodness. :)
The first thing to realise is that this violates the principle of
"callee does everything important t
G'day all.
On Sat, Apr 27, 2002 at 07:00:17AM +0100, Piers Cawley wrote:
> I'm trying to see how, if you want genuine continuations and/or tail
> call optimization, you're going to get away with anything but 'caller
> saves everything important to it', and what do you know, I
> can't.
If you ha
At 7:00 AM +0100 4/27/02, Piers Cawley wrote:
>Andrew J Bromage <[EMAIL PROTECTED]> writes:
>
>> G'day all.
>>
>> On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
>>
>>> I also vote for reserving some caller-save registers to make
>>> arg passing faster, however, reserving 16 is p
Andrew J Bromage <[EMAIL PROTECTED]> writes:
> G'day all.
>
> On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
>
>> I also vote for reserving some caller-save registers to make
>> arg passing faster, however, reserving 16 is probably useless, except
>> for symmetry.
>>
>> I think mo
G'day all.
On Fri, Apr 26, 2002 at 08:16:27AM -0400, Melvin Smith wrote:
> I also vote for reserving some caller-save registers to make
> arg passing faster, however, reserving 16 is probably useless, except
> for symmetry.
>
> I think most texts agree that 5 or so are about all you need.
Fair
TED]To: [EMAIL PROTECTED]
rg> cc:
Subject: Re: Subro
G'day all.
On Mon, Apr 22, 2002 at 01:52:30PM -0700, Brent Dax wrote:
> > How about we instead declare that all subs have One True Entry Point,
> > and the sub does whatever is needed there? Normal subs can just set up
> > scoping and jump to the beginning of the sub's body; coroutines retrieve
At 10:03 AM -0500 4/25/02, Fisher Mark wrote:
> > I've no strong opinions on how it's done, but I do believe that
>> it's *very* important that subroutine calls be as fast as possible
>> (and significantly faster than perl5). This must be a priority.
>>
>> To my mind that means that a subrouti
At 4:42 PM -0700 4/22/02, Steve Fink wrote:
>On Tue, Apr 23, 2002 at 09:28:29AM +1000, Andrew J Bromage wrote:
>> G'day all.
>>
>> On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
>>
>> > 3) We're having a new rule--you may *not* take a continuation from
>> > within an opcode func
> I've no strong opinions on how it's done, but I do believe that
> it's *very* important that subroutine calls be as fast as possible
> (and significantly faster than perl5). This must be a priority.
>
> To my mind that means that a subroutine should be responsible for
> setting up whatever _it_
On Mon, Apr 22, 2002 at 01:52:30PM -0700, Brent Dax wrote:
>
> How about we instead declare that all subs have One True Entry Point,
> and the sub does whatever is needed there? Normal subs can just set up
> scoping and jump to the beginning of the sub's body; coroutines retrieve
> their context
On Tue, Apr 23, 2002 at 09:28:29AM +1000, Andrew J Bromage wrote:
> G'day all.
>
> On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
>
> > 3) We're having a new rule--you may *not* take a continuation from
> > within an opcode function! This is probably one of those "Well, Duh!"
>
1 - 100 of 104 matches
Mail list logo
