On Mon, Sep 02, 2002 at 11:15:17AM -0700, Steve Fink wrote:
> On Mon, Sep 02, 2002 at 08:25:30AM -0700, Sean O'Rourke wrote:
> > On Mon, 2 Sep 2002, Dan Sugalski wrote:
> >
> > > Here's a call for potential goals for the 0.0.9 release of parrot. My list:
> > >
> > > *) Exceptions
> > > *) initial PMC freeze/thaw API
> > > *) Sub indicators in bytecode
> > > *) On-the-fly bytecode section generation
> >
> > *) methods (in PASM and C)
> > *) implementation of some methods for the Perl classes
> > *) stashes
>
> *) Resolve the prompt finalization problem (good luck...)
> *) PMC name, implementation cleanup
> *) Filename, line number tracking
*) Careful elimination of all compiler warnings, particularly on non x86
platforms, and for builds with non-default INTVAL size
This is going to need some care to work out why some warnings happen, and
find ways to re-order/re-pack/re-size structures to avoid both these gcc
warnings:
In file included from ../include/parrot/register.h:16,
from ../include/parrot/interpreter.h:42,
from ../include/parrot/parrot.h:160,
from perlhash.c:24:
.../include/parrot/string.h:59: warning: padding struct size to alignment boundary
In file included from ../include/parrot/interpreter.h:51,
from ../include/parrot/parrot.h:160,
from perlhash.c:24:
.../include/parrot/debug.h:53: warning: padding struct to align `value'
over all platforms. (which will be fun)
and I think
*) Rationalisation of how we make bytecode
I think that the assembler is slower than it could be. I feel that the
"correct" solution is a perl front end talking to a C bytecode generation
library. I feel the library ought to be common, so that it would be possible
for imcc (or anything else) to use the bytecode generation library direct,
rather than having to emit PASM only for it to be re-interpreted.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
