Jason --
> Making the distinction between the three cases enables a number of
> optimizations of native code based on analysing data flow. 'in' would be good
> as an implicit default, as many PMC opcodes will not overwrite any PMC
> registers.
>
> An optimizing native code generator (whether st
On Mon, Dec 24, 2001 at 02:11:15PM -0500, Gregor N. Purdy wrote:
> Or, do we really need to have the three-way in/out/inout tagset?
>
> inline op set(out i, in i|ic) {
> $1 = $2;
> }
Making the distinction between the three cases enables a number of
optimizations of native code based on
On Mon, Dec 24, Gregor N. Purdy wrote:
> Nicholas --
>
> > Parrot_set_i_i(in,out): \x8b \x0d &IR2 \x89 \x0d &IR1
>
> I'm tempted to push the specification of this information all the way
> back to the syntax of .ops files, since the code that lives there
> should behave the same wrt read/write o
On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > To run a program with the JIT, pass test_parrot the -j flag and watch it
> > scream. Well, scream if you're on x86 Linux or BSD (I get a speedup o
Gregor N. Purdy:
# > Parrot_set_i_i(in,out): \x8b \x0d &IR2 \x89 \x0d &IR1
#
# I'm tempted to push the specification of this information all the way
# back to the syntax of .ops files, since the code that lives there
# should behave the same wrt read/write on args.
#
# Dan likes C-like syntax as m
Nicholas --
> Parrot_set_i_i(in,out): \x8b \x0d &IR2 \x89 \x0d &IR1
I'm tempted to push the specification of this information all the way
back to the syntax of .ops files, since the code that lives there
should behave the same wrt read/write on args.
Dan likes C-like syntax as much as possible
On Mon, Dec 24, 2001 at 03:19:39PM -0300, Daniel Grunblatt wrote:
> I think we should leave all that for an optimizer.
I agree with that
Sorry, my point wasn't clear:
I believe the current JIT description syntax precludes making a good optimiser.
By making all ops pass by reference, with no inf
Oh, and by the BTW,
I already tried you fastest example last week and got 50x speed up, but
that's works only for mops, so ...
Daniel Grunblatt.
On Mon, 24 Dec 2001, Nicholas Clark wrote:
> On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
>
> > It looks like it is going to need some
I think we should leave all that for an optimizer.
Daniel Grunblatt.
On Mon, 24 Dec 2001, Nicholas Clark wrote:
> On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
>
> > It looks like it is going to need some work before it can work for
> > other instruction sets though, at least for
On Fri, Dec 21, 2001 at 12:03:51AM +, Tom Hughes wrote:
> It looks like it is going to need some work before it can work for
> other instruction sets though, at least for RISC systems where the
> operands are typically encoded with the opcode as part of a single
> word and the range of immedi
Don't forget that (if I'm missing somthing) by the time that pbc2c.pl
work with all the ops it will be much slower than the jit.
Daniel Grunblatt.
On 21 Dec 2001, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Daniel Grunblatt <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 21 Dec 2001,
In message <[EMAIL PROTECTED]>
Daniel Grunblatt <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2001, Tom Hughes wrote:
>
> > I suspect it is also rather questionable to call system calls
> > directly rather than going via their C library veneers - that is
> > even more true when you come to
On Fri, 21 Dec 2001, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > To run a program with the JIT, pass test_parrot the -j flag and watch it
> > scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on
> > mops.pbc of 3
All --
> > > $ ./test_parrot -j examples/assembly/mops.pbc
> > > Illegal instruction
> > >
> > > That's not supposed to happen is it? Its Linux/PowerPC, so maybe it
> > > is supposed to happen.
> >
> > It's sort of supposed to happen. It shouldn't work, at least--we need
> > better error chec
Dan and Michael --
> > $ ./test_parrot -j examples/assembly/mops.pbc
> > Illegal instruction
> >
> > That's not supposed to happen is it? Its Linux/PowerPC, so maybe it
> > is supposed to happen.
>
> It's sort of supposed to happen. It shouldn't work, at least--we need
> better error checking
On Thu, 20 Dec 2001, Michael G Schwern wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > To run a program with the JIT, pass test_parrot the -j flag and watch it
> > scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on
> > mops.pbc of 35x) but it's a darned good place to star
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> To run a program with the JIT, pass test_parrot the -j flag and watch it
> scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on
> mops.pbc of 35x) but it's a darned good place to start.
$ ./test_parrot -j examples/assembly/mops.pbc
Ille
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> To run a program with the JIT, pass test_parrot the -j flag and watch it
> scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on
> mops.pbc of 35x) but it's a darned good place to start.
It does s
Thanks to the work of Daniel Grunblatt, we now have JIT capabilities in
parrot. It's in the latest CVS, ready for your use and abuse.
To run a program with the JIT, pass test_parrot the -j flag and watch it
scream. Well, scream if you're on x86 Linux or BSD (I get a speedup on
mops.pbc of 35x)
19 matches
Mail list logo
