All --
> The missing code is going to look something like this:
> Next time I'm in front of my development machine, I'll give this a try.
> If this approach works, I'll work harder to produce a version of the
> solution that we can be proud of.
OK. I got it working. I'm attaching the compile.pl
All --
> Chances are good that you were at least having trouble do to the string
> constants not being loaded into the interpreter (I pointed this problem
> out a few minutes ago in a related message). Perhaps getting those
> string-constant-loading statements in there as directed earlier would
Brent --
> # My first cut is pretty sloppy, but it does generate this C file, which
> # compiles, but I don't have the time to figure out how to get
> # it all the
> # stuff it needs to link to. If someones gets it running, I'd
>
> Parrot::Config may come in handy, especially @PConfig{qw(cc ccf
All --
> My first cut is pretty sloppy, but it does generate this C file, which
> compiles, but I don't have the time to figure out how to get it all the
> stuff it needs to link to. If someones gets it running, I'd like to see
> how many Mops they get vs. regular.
BTW, I realized as I left the
Gregor N. Purdy:
# Dan --
#
# > Here's something for someone looking to do something
# interesting while the
# > code freeze is on.
# >
# > Write yourself a program that takes a .pasm file and,
# rather than spitting
# > out bytecode, spits out the bodies of the opcode functions with the
# > appro
Dan --
> Here's something for someone looking to do something interesting while the
> code freeze is on.
>
> Write yourself a program that takes a .pasm file and, rather than spitting
> out bytecode, spits out the bodies of the opcode functions with the
> appropriate replacements done on the
At 04:32 PM 9/21/2001 -0400, Michael Maraist wrote:
>Either way, branching can be reduced by a clustering a sequence of
>regularly used-ops together into macro-ops.
Congrats, you've uncovered another hidden reason for the preprocessed
opcode functions. :)
The intention is that we'll be able to
> On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> > Doing this by hand with -O3, you can see a speedup of around a factor of 45
> > over an unoptimised runops loop, so it's definitely worth doing in some
> > cases...
>
> Cool! Parrot JIT!
>
> But that tells us *just* how time-cons
On Fri, Sep 21, 2001 at 03:52:52PM -0400, Gregor N. Purdy wrote:
> OK. I'm tinkering with this a bit, but I've tripped over what appears to
> be a bug somewhere in the PackFile::* classes.
You too, eh? I think it would be a VERY good idea to have the configure
process spit out a module containin
Dan --
> Write yourself a program that takes a .pasm file and, rather than spitting
> out bytecode, spits out the bodies of the opcode functions with the
> appropriate replacements done on the parameters. The output should be
> suitable for stuffing into the guts of test_main.c in the place of
At 07:41 PM 9/21/2001 +0100, Simon Cozens wrote:
>On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> > Doing this by hand with -O3, you can see a speedup of around a factor
> of 45
> > over an unoptimised runops loop, so it's definitely worth doing in some
> > cases...
>
>Cool! Parro
On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> Doing this by hand with -O3, you can see a speedup of around a factor of 45
> over an unoptimised runops loop, so it's definitely worth doing in some
> cases...
Cool! Parrot JIT!
But that tells us *just* how time-consuming our ru
12 matches
Mail list logo
