Re: Interpreter memory allocation

On Thu, 14 Feb 2002, Dan Sugalski wrote: > To allocate memory that is GCable, call Parrot_allocate(interpreter, > size). Then stash the pointer and size in your buffer header, or > it'll go missing later. To resize a chunk of memory, call > mem_realloc(interpreter, from, oldsize, newsize). Havin

Three address code, named variables

See if this has any value, I thought it might. For a toy compiler I'm working on, I also started a trivial translator that does three address code -> Parrot assembler. While its currently a very simple script, I'm making it do named lexicals, named globals and register tracking. Then it'd be nice

Re: Interpreter memory allocation

On Fri, 15 Feb 2002, Alex Gough wrote: > On Thu, 14 Feb 2002, Dan Sugalski wrote: > > > To allocate memory that is GCable, call Parrot_allocate(interpreter, > > size). Then stash the pointer and size in your buffer header, or > > it'll go missing later. To resize a chunk of memory, call > > mem_r

Re: Interpreter memory allocation

At 2:56 PM + 2/15/02, Alex Gough wrote: >On Thu, 14 Feb 2002, Dan Sugalski wrote: > >> To allocate memory that is GCable, call Parrot_allocate(interpreter, >> size). Then stash the pointer and size in your buffer header, or >> it'll go missing later. To resize a chunk of memory, call >> me

Re: Interpreter memory allocation

At 11:38 AM -0500 2/15/02, Michael Maraist wrote: >On Fri, 15 Feb 2002, Alex Gough wrote: > >> On Thu, 14 Feb 2002, Dan Sugalski wrote: >> >> > To allocate memory that is GCable, call Parrot_allocate(interpreter, >> > size). Then stash the pointer and size in your buffer header, or >> > it'll

RE: Three address code, named variables

Hello, >If people have different opinions on intermediate code generation, I'd >like to hear them, since I've only done toy compilers in school which >always used 3address or quadruples. I have been working in a compiler for an intermediate language that I call P-- (obviously inspired in C--) fo

Re: Three address code, named variables

> >If people have different opinions on intermediate code generation [...] > > I have been working in a compiler for an intermediate language that I call > P-- (obviously inspired in C--) for now. [...] I find it encouraging and exciting that people are already building useful middlecode on top o

Re: Your mission...

On Thu, Feb 14, 2002 at 08:22:49PM -0500, Dan Sugalski wrote: > If you choose to accept it, is to dig out the computed goto and > switch runops cores from the archives, dust 'em off and get them up > to snuff with the current sources. > > Takers, anone? I spent about an hour on this last night

Re: Your mission...

On Fri, Feb 15, 2002 at 12:13:57PM -0800, Steve Fink wrote: > Looks like the commits since last night have re-broken pbc2c.pl, so > it'll be a little while before I can generate a patch. My mistake, it was just that 'make clean' deleted my .pbc file and pbc2c.pl wasn't very good about reporting t

ADA number syntax?

Original Message Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: (qmail 14099 invoked from network); 14 Feb 2002 22:51:43 - Received: from eros.cs.jhu.edu (128.220.223.245)by hilbert.umkc.edu with SMTP; 14 Feb 2002 22:51:43 - Received: from e

[COMMIT] More informative panics (start spreading panics around!)

I just committed some modifications to make panics produce better output. I'll paste a sample here (I got it by commenting out a line in embed.c, thus inducing a panic in pmc_new): Parrot VM: PANIC: Null vtable used! C file c:\brent\visual studio projects\perl 6\parrot\parrot\pmc

[Patch] Fix warnings in exceptions.c

Index: exceptions.c === RCS file: /home/perlcvs/parrot/exceptions.c,v retrieving revision 1.2 diff -u -r1.2 exceptions.c --- exceptions.c15 Feb 2002 23:20:31 - 1.2 +++ exceptions.c16 Feb 2002 03:55:58 - @

Re: [Patch] Fix warnings in exceptions.c [APPLIED]

Thanks, applied. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even

Re: [Patch] Fix warnings in exceptions.c [APPLIED]

Oops, my patch introduced some more warnings in other files. Here's a fixed version. Index: exceptions.c === RCS file: /home/perlcvs/parrot/exceptions.c,v retrieving revision 1.2 diff -u -r1.2 exceptions.c --- exceptions.c1

Re: [Patch] Fix warnings in exceptions.c [APPLIED]

At 11:07 PM -0500 2/15/02, Josh Wilmes wrote: >Oops, my patch introduced some more warnings in other files. Here's a >fixed version. In instead. Thanks. -- Dan --"it's like this"--- Dan Sugalski

Re: Your mission...

At 12:35 PM -0800 2/15/02, Steve Fink wrote: > >Anyway, here's a patch to repair pbc2c.pl, combined with removing >typecasts in various places throughout the code. It probably won't >work for Windows yet. The libparrot.a target might need to be modified >to at least prevent it from confusing make

[Patch] More lint-induced fixes

Fixes some bad returns, some unused variables, and some mismatched formats. This should be distinct from my other pending patch, which changes the way function pointers are handled outside of the JIT. --Josh Index: embed.c === RC

RE: [Patch] More lint-induced fixes

Josh Wilmes: # --- misc.c15 Feb 2002 02:30:02 - 1.11 # +++ misc.c16 Feb 2002 05:36:46 - # @@ -277,6 +277,7 @@ # info.phase = PHASE_WIDTH; # goto AGAIN; # } # +break; # #

Re: [Patch] More lint-induced fixes

At 22:02 on 02/15/2002 PST, "Brent Dax" <[EMAIL PROTECTED]> wrote: > # +++ misc.c 16 Feb 2002 05:36:46 - > It's not indenting the nested switch() statements the same as their > matched break;s. Hrm. It _should_ be indented OK.. not sure what happened there- can whoever applies the patch

interesting lint warning in array.pmc

array.pmc: (in function Parrot_Array_move_to) array.pmc:70:18: Stack-allocated storage pmc->data reachable from parameter pmc A stack reference is pointed to by an external reference when the function returns. The stack-allocated storage is destroyed after the call, leaving a dangling refer