Steve Fink wrote:
... it
just replaces make's timestamp-based dependency check with a
checksum-based check.
Ah, then it's ok.
leo
Currently all architecures have there own core.jit. These are very
similar, e.g. checking for MAPped registers, but differ depending on
the processor architecure: basically we have 3 register machines
(alpha, arm, ppc, sparc) and a 2 register machine (i386).
My proposal is to write a universal
I would do a cisc.jit and a risc.jit to avoid the #ifdef forest.
The problem is when you want to implement an opcode like div, which is easy in
ppc but not in arm ideas?
I was sort of going in that direction, mips/core.jit is almost like
ppc/core.jit (If everything is on schedule I'll find
Daniel Grunblatt wrote:
I would do a cisc.jit and a risc.jit to avoid the #ifdef forest.
Good idea.
The problem is when you want to implement an opcode like div, which is easy in
ppc but not in arm ideas?
I don't know arm, but this belongs to jit_emit.h, how it's done there is
a
On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
The problem is when you want to implement an opcode like div, which is
easy in ppc but not in arm ideas?
I don't know arm, but this belongs to jit_emit.h, how it's done there is
a different issue.
what
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #18520]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18520
This patch just adds a new control flow flag to op.h and extracts the
additional
On Tue, Nov 19, 2002 at 03:40:33PM -0300, Daniel Grunblatt wrote:
On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
We could do it like parrot (dest, src, src) too, but I want really a
unique naming convention.
leo
Cool, let's do it like parrot.
Good call.
I think it's the
Looks like somebody gave the TD-* machines the correct input. Yay! We
can actually see some green again!
On the other hand, everything else is still failing. I tried compiling
on a Solaris box, but the darned thing worked flawlessly. Here's a
summary of what's going wrong on the various
At 9:33 PM -0800 11/19/02, Steve Fink wrote:
### glastig (Mac OS X 10.1) ###
I've seen this message before, but I thought it was fixed now:
find_type returned 0 for illegal wanted -68. The next failure is
similar: Sub PMCs should be type 17 but have incorrect type 16.
That's a test I added when
At 21:33 on 11/19/2002 PST, Steve Fink [EMAIL PROTECTED] wrote:
### galactic-lcc (Debian x86, lcc 4.1) ###
Failed the mod_n test in number.t, and the pushn popn (deep)
test in stacks.t.
Not sure what the story is with pushn/popn, but the mod_n failure is normal
for lcc- it appears to
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Steve Fink) wrote:
[snip]
### glastig (Mac OS X 10.1) ###
I've seen this message before, but I thought it was fixed now:
find_type returned 0 for illegal wanted -68. The next failure is
similar: Sub PMCs should be type 17 but have incorrect
Steve Fink wrote:
Looks like somebody gave the TD-* machines the correct input. Yay! We
can actually see some green again!
t/op/interp.t 1 256 21 50.00% 2
unimp restart on PPC
t/op/lexicals.t6 1536 66 100.00% 1-6
t/pmc/scratchpad.t
Jason Gloudon (via RT) wrote:
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #18520]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18520
This patch just adds a new control flow flag to
Daniel Grunblatt wrote:
On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
what if we just don't want to implement that opcode in this specific
architecture?
Prefered: provide a native function doing the e.g. div and call this
function from within the
14 matches
Mail list logo
