G'day all.
On Fri, Apr 19, 2002 at 07:06:04AM +0100, Piers Cawley wrote:
> If I'm going to be doing tail call optimization
> (and I can't call it scheme if I don't) then my first thought was as
> follows.
>
> # This is a tail call
>
> branch FOO_tail
> ...
>
> #
So, here I am, roughing out some ideas for how I'm going to implement
a very lovely and worthwhile scheme interpreter (or a compiler, I'm
not proud) for parrot. If I'm going to be doing tail call optimization
(and I can't call it scheme if I don't) then my first thought was as
follows.
# This i
G'day all.
On Fri, Apr 19, 2002 at 12:44:49AM -0400, Dan Sugalski wrote:
> Ah. Hmmm. Well, we're already attaching some metadata to ops in a
> different way--that's what the op and inline keywords are doing. For
> metadata that use parameters I can see a scheme like you're
> proposing, though
At 1:59 PM +1000 4/19/02, Andrew J Bromage wrote:
> > Interesting. Could you give an example of how an op with metadata
>would look?
>
>Sure. Here's some of my experimenting with what is the right kind
>of metadata to attach. Brief glossary:
Ah. Hmmm. Well, we're already attaching some metada
> Added: languages/regex/lib/Regex Ops.pm
>languages/regex/lib/Regex/Ops List.pm Tree.pm
> Removed: languages/regex/lib/Regex AsmOps.pm RegexOps.pm
>languages/regex/lib/Regex/Rewrite Re.pm
Make sure to update the MANIFEST. It usually works fine if you
G'day all.
On Thu, Apr 18, 2002 at 11:31:32PM -0400, Dan Sugalski wrote:
> Interesting. Could you give an example of how an op with metadata would look?
Sure. Here's some of my experimenting with what is the right kind
of metadata to attach. Brief glossary:
- CANNOT_FALL_THROUGH mean
At 1:04 PM +1000 4/19/02, Andrew J Bromage wrote:
>This patch allows op-writers to store optional metadata to be
>associated along with an op. Very simple key-value stuff at the
>moment; may get fancier later.
Interesting. Could you give an example of how an op with metadata would look?
--
G'day all.
This patch allows op-writers to store optional metadata to be
associated along with an op. Very simple key-value stuff at the
moment; may get fancier later.
Once again, this is mostly for the optimizer's benefit, so you
can note things like if an op affects the state of the world, or
G'day all.
On Thu, Apr 18, 2002 at 09:09:59PM -0400, Dan Sugalski wrote:
> I've applied this, with the exception of the branch and bsr ops. At
> the moment, I agree--I can't see any case where "if" or "gte" needs
> to have a variable target. (I can see it for branch, bsr, jump, and
> jsr, as
At 6:43 PM -0400 4/18/02, Mike Lambert wrote:
>Undoing the patch in resources.c seems to fix the problem.
>
>Changing:
> ((Buffer *)buffer)->buflen = req_size;
>to:
> ((Buffer *)buffer)->buflen = size;
>makes it work again.
>
>Looking into it a bit more, this seems like a 'bad' patch.
I a
At 11:11 PM +0200 4/18/02, Marco Baringer wrote:
>
>i am attaching a patch to Parrot::OpTrans::CGoto which makes goto
>ADDRESS(X) jump to the offset X relative to the start of the byte_code
>(in other words interpreter->code->byte_code + X). given this "new"
>interpretation of goto ADDRESS() i hav
At 3:24 PM +1000 4/18/02, Andrew J Bromage wrote:
>G'day all.
>
>This patch introduces a new op parameter type "inconst", which is like
>"in" except that it only produces const versions of the op (i.e. it
>will not take values from registers).
>
>This is mostly for the benefit of branch targets.
G'day all.
On Thu, Apr 18, 2002 at 09:35:11AM -0400, Jason Gloudon wrote:
> Having registers provide the destination for some branches makes it
> possible to generate code that eliminates most of the comparisions
> needed to implement C style case/switch statements, so this is not a
> useless fe
Undoing the patch in resources.c seems to fix the problem.
Changing:
((Buffer *)buffer)->buflen = req_size;
to:
((Buffer *)buffer)->buflen = size;
makes it work again.
Looking into it a bit more, this seems like a 'bad' patch. Take, for
example, resize_array in array.pmc. If I call resiz
Sometime during or shortly after the 0.0.5 release, BASIC broke with
string/stack/GC errors. During program LOAD, Parrot runs off eats a ton of
memory (sometimes) and falls over dead (eventually). Someone else in
#parrot tried the exact same test without problems. I'm dismayed.
To reproduce
# New Ticket Created by "Clinton A. Pierce"
# Please include the string: [netlabs #522]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=522 >
Sometime during or shortly after the 0.0.5 release, BASIC broke with
string/s
Jason Gloudon <[EMAIL PROTECTED]> writes:
[i distincly remember sending this email, but it's not in the web
archive or in my gnus archive, so i'm sending it again, pardon me if
you've already seen this]
> On Thu, Apr 18, 2002 at 01:49:20PM +0200, Marco Baringer wrote:
>
> > in trying to make go
At 10:52 PM +0200 4/16/02, Marco Baringer wrote:
>Steve Fink <[EMAIL PROTECTED]> writes:
> > On the other hand, I may be overlooking a good reason for adding
>> these. The two reasons I can think of right now are (1) you've done
>> benchmarking and combining these ops demonstrates a significant
On Thu, Apr 18, 2002 at 03:24:58PM +1000, Andrew J Bromage wrote:
> - Nobody is likely to use it any time soon.
People say that about my brain, but they haven't tried to take it from me
yet :)
Having registers provide the destination for some branches makes it possible to
generate code th
On Thu, Apr 18, 2002 at 01:49:20PM +0200, Marco Baringer wrote:
> in trying to make goto ADDRESS($1) work as it should i have come
> across the following doubt:
How are you interpreting that it "should" work ? I don't know of any
documentation that says what it should do, but currently it is onl
in trying to make goto ADDRESS($1) work as it should i have come
across the following doubt:
out of core_ops.c, core_ops_cg.c and core_ops_prederef.c which one is
parrot using? and how do i change it if i want? i notice while
compling is have the HAVE_COMPUTED_GOTO macro defined, but it seems
(a
21 matches
Mail list logo
