On Oct 22, 2004, at 3:57 AM, Leopold Toetsch wrote:
Jeff Clites wrote:
On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:
[JIT changes]
I just finished tracking down the source of a couple of JIT test
failures on PPC--due to recent changes but only indirectly related,
and pointing out things whi
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #32092]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32092 >
---
osname= linux
osvers= 2.4.21-14.elsmp
arch= i386-linux-thread-multi
cc=
--- Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > ICU libs are in /usr/local/lib
>
> > /usr/local/lib is in my path
>
> Which "path"? Do you mean LD_LIBRARY_PATH or do
> you mean PATH?
>
> PATH is irrelevant. That's the set of directories
> used by /bin/sh
> (or equivalent) to find executable
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> >> All tests pass normally, but I get 3 tests
> failing
> >> under JIT
> >>
> >> t/op/interp.t #7
> >> t/pmc/coroutine.t #10
> >> t/pmc/exception.t #19
>
> > ok, so I did investigate a little further.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What're we looking at for performance impact on mops.pasm and the
> other simple benchmarks?
I didn't look yet. Compiling optimized takes ages here :) Anyway:
Estimate performance impact:
JIT mops.pasm 0 (i386, PPC)
CGP mops.pasm 0 - 1%
plain mo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... It *could* spill the used registers, or it could
> just push the whole set onto the register stack and start fresh,
> popping off the old set when the code's done.
Or probably much simpler: given a fairly big linear register frame, just
advance the ba
At 9:20 AM +0200 10/22/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 5:34 PM +0200 10/21/04, Leopold Toetsch wrote:
The question is: is saveall supposed to copy registers or just
prepare a fresh set of registers.
What about that?
Missed that, sorry. A copy.
and we see where we go from there.
At 3:33 PM +0200 10/22/04, Leopold Toetsch wrote:
A serious of patches has now eliminated all direct usage of Parrot
registers. The last patch also introduces a new define in
include/parrot/settings.h:
#define INDIRECT_REGS 0
It's default value is still off. But turning it to 1 will use the
ind
A serious of patches has now eliminated all direct usage of Parrot
registers. The last patch also introduces a new define in
include/parrot/settings.h:
#define INDIRECT_REGS 0
It's default value is still off. But turning it to 1 will use the
indirect access of Parrot registers through a pointer
I am fully aware that an absolute path can have some negative side
effects. You can lose platform independecy - not to speak of problems
with the Win-Filesystem. I don't now how to write tests for it either.
But do you think, this could work for a start?
I promise, I will try to find more impor
Matthias Huerlemann <[EMAIL PROTECTED]> wrote:
> Hello
> This patch is not meant to repair a bug. It is rather a microscopic
> feature request:
> The ".include" statement does not allow absolute paths like:
> .include "/home/user/folder/file.pir"
I think, if the filename looks like an absolute
Jeff Clites wrote:
On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:
[JIT changes]
I just finished tracking down the source of a couple of JIT test
failures on PPC--due to recent changes but only indirectly related, and
pointing out things which needed fixing anyway (float register
preservati
On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:
[JIT changes]
I just finished tracking down the source of a couple of JIT test
failures on PPC--due to recent changes but only indirectly related, and
pointing out things which needed fixing anyway (float register
preservation issues). I'll sen
# New Ticket Created by Matthias Huerlemann
# Please include the string: [perl #32087]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32087 >
Hello
This patch is not meant to repair a bug. It is rather a microscopic
fe
On Mon, Oct 18, 2004 at 01:05:06PM -0400, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 18, 2004 at 04:43:12PM +0200, H.Merijn Brand wrote:
> > > Please consider 0.50 very soon, in which you fix 'err' calls that are an
> > > obvious mistake given defined-or functionality in blead and 5
The functions inside F look bogus. They are unused
altogether.
What's the state of these functions?
leo
Most of the current JIT code assumes a certain layout of Parrot registers.
1) use interpreter->int_reg.registers[0] as base
1a) interpreter is base
2) use a certain ordering inside registers
alpha ... 1)
arm ... 2)
hppa ... 1)
ia64 ... 1a)
mips ... does very likely not even compile
sun4 ... 2
The direct register access a la:
interpreter->int_reg.registers[x]
and such will break soon. If you have such syntax in your code, please
replace it with:
REG_INT(x)
REG_STR(x)
...
These macros are defined in interpreter.h and will be adjusted as needed.
Thanks,
leo
Jeff Clites wrote:
Are we still planning to move the current return continuation and
current sub, out of the registers and into their own spots in the
interpreter context
The current sub, continuation, and object already have a storage in the
context structure and are accessible via the C opcode
On Mon 18 Oct 2004 19:05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 18, 2004 at 04:43:12PM +0200, H.Merijn Brand wrote:
> > > Please consider 0.50 very soon, in which you fix 'err' calls that are an
> > > obvious mistake given defined-or functionality in blead and 5.8.x-dor:
> >
>
Dan Sugalski wrote:
At 5:34 PM +0200 10/21/04, Leopold Toetsch wrote:
The question
is: is saveall supposed to copy registers or just prepare a fresh set
of registers.
What about that?
I think the next steps are:
1) Implement the new indirect register frame
2) Note in the calling conventions that
21 matches
Mail list logo
