On Thu, Oct 28, 2004 at 10:06:05AM +0200, Leopold Toetsch wrote:
* all JIT platforms except ppc and i386 are broken
Takers wanted for JIT fixes. See jit/ppc/* for necessary changes.
This patch fixes JIT for the sparc platform (make testj passes
except for the streams and gc_10.pasm where it
This patch adds tests for iscompare style ops (isgt, isge, isle, islt,
iseq, isne) on integers, numbers and strings, in t/op/comp.t.
Thanks,
Stéphane
PS.: maybe t/op/*.t could be reorganized so that test filenames match
what is under ops/*.ops? and t/op would test only I, N, and S stuff,
These two patches add jit support for iscompare style ops (isgt, isge, isle,
islt, iseq, isne) on integers for the sun/sparc platform.
The jitted code follows this pattern:
cmp %r2, %r3
bc,a next
mov 1, %r1
mov 0, %r1
next: ..
c
Sorry the previous core.jit patch for sun contained a typo. The correct
patch file is attached here again.
Thanks!
Stephane
On Sun, Sep 26, 2004 at 02:40:29AM -0700, Leopold Toetsch wrote:
The integer and number variants of these opcodes could need JIT support.
Index: jit/sun4/core.jit
On Tue, Aug 24, 2004 at 09:44:56AM +0200, Leopold Toetsch wrote:
Whatever you'll try the current scheme is not compatible with this GTK
callback. Parrot needs a PMC as user_data. GTK awaits a GObject.
Yes. But draining the event queue still needs a running Parrot runloop.
This made me
On Mon, Aug 23, 2004 at 12:14:51PM +0200, Leopold Toetsch wrote:
Leopold Toetsch wrote:
Stephane Peiry wrote:
g_return_val_if_fail (G_IS_OBJECT (gobject), 0); Fails here
gtk shouldn't make assumption on the user_data argument IMHO.
[...]
call is NULL, because of the same check
mh.. guess P is an actuall pointer to PMC, in that case forget that part.. :)
Stephane
On Mon, Aug 23, 2004 at 11:15:03PM +0200, Stephane Peiry wrote:
[signatures question gone]
*If* that is solved then the next problem is of course that by calling
gtk_main() the GTK event loop is running
On Thu, Aug 19, 2004 at 01:21:33PM +0200, Leopold Toetsch wrote:
[ segfaulting example ]
g_signal_connect_object (G_OBJECT (button), clicked,
G_CALLBACK (hello), NULL, 0);
Are you sure, that these two G_foo() aren't doing something with the
function arguments?
On Wed, Aug 18, 2004 at 09:11:17AM +0200, Leopold Toetsch wrote:
You've mixed up the function parameters.
P0 = global Gtk::gtk_window_new
null I5
invoke
P15 = P5
I presume that's instance ...
actually shouldnt the callback is for the button
# -- function sig is
On Tue, Aug 17, 2004 at 09:01:39AM +0200, Leopold Toetsch wrote:
It returns a PerlUndef.
60 dlfunc P2, P1, g_signal_connect, lptpP - \
P2=NCI=PMC(0x8363fd0), P1=ParrotLibrary=PMC(0x8364108), ,
65 store_global Gtk::g_signal_connec, P2 - , \
On Mon, Aug 16, 2004 at 10:20:46AM +0200, Leopold Toetsch wrote:
gtk-signal-connect or g-signal-connect isn't found here. I can't
check the symbols of the lib, this dam** OS has symbols stripped. The
other box has only gtk-1.2.
actually it should run as well against gtk-1.2 if
Hi All,
Ive been trying to get the (NCI) callbacks working with GTK but somehow
cant. Mainly the attached file implements a (very) small test app where
it simply displays a button within a window.
The problem is that as soon as it goes onto installing the callback
parrot returns with a
Done thanks,
Stéphane
On Mon, Mar 01, 2004 at 11:48:08AM -0500, Gay, Jerry wrote:
if this is accepted, please close [perl #27083], as it addresses this bug,
but i haven't yet seen it posted to the list.
--jerry
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
On Fri, Feb 27, 2004 at 03:40:20PM -0500, Simon Glover wrote:
20707 -- fixed (and also irrelevant now we no longer use assemble.pl)
21665 -- fixed
21759 -- patch accepted and applied
22321 -- patch accepted and applied
ok these are now closed (resolved).
26898, 26904, 26927, 26939,
On Mon, Feb 23, 2004 at 11:07:48AM +0100, Leopold Toetsch wrote:
Yep. That's a bit complicated. The jit code tries to avoid
loading/storing the same register from/to memory.
Actually on this, while looking at what jit on i386 would give for this
particular loop, just noticed it does quite a lot
On Mon, Feb 16, 2004 at 09:08:55AM +0100, Leopold Toetsch wrote:
I see. Your libc's sprintf seems to be missing the 0x prefix for the
%p format.
Ok you were right, that fixed it immediatly, and I'm now able to
see within jit :). Attached are the dumps for this loop, with
and without the print
On Fri, Feb 13, 2004 at 10:48:09AM +0100, Leopold Toetsch wrote:
I don't know suns JIT code nor the assembler syntax, but it seems that
the two subcc lines are broken:
emitm_subcc_r(NATIVECODE, MAP[1], emitm_g(0), emitm_g(0));
If I understand that correctly it should read:
On Sat, Feb 14, 2004 at 02:35:02PM +0100, Leopold Toetsch wrote:
docs/debug.pod /jit
saw that one, but jit doesn't generate a .o file under sparc?
Stéphane
Hi All,
While playing with JIT on Suns, I've found out that the following pasm code:
set I1, 2
LOOP: sub I1, 1
ifI1, LOOP
print end\n
end
never finishes.. that is: parrot -j loop.pasm hangs forever (never printing
'end') while the non-jitted
Hi All,
Attached here is a list with old entries in RT where you can see the
requestor (email address), ticket number, description. If your email
address is in there, please give an update or I'll go flagging these
as obsolete (unless they are obviously resolved, patch applied or
else ;)
Thanks
Hi All,
For some reason.. always wanted to be able to write (and get) perl
applets on web browsers, so attached here is my go at a parrot plugin
for Mozilla :)
The files attached are:
The plugin.tar is the one containing it mainly with some instructions
on how to build it (and test it).
Since I
Well I posted a very simple patch for it (maybe a bit too simplistic
since it didnt end up being applied! ;-) Also noticied that I was
the second trying apply a patch so that at least it does not core
dump any more...
Maybe its just hanging there for beginners to easy patch something ,-)
Le
22 matches
Mail list logo
