Sam Ruby <[EMAIL PROTECTED]> wrote:
> I'm now converting to dynclasses. To be honest, I'm not thrilled with
> this. What I would really prefer is a Parrot_new_p_s opcode with the
> runtime worrying about caching class names across sub and module boundaries.
$P0 = new "Py_int"
or some such ha
Sam Ruby <[EMAIL PROTECTED]> wrote:
> I note that the perlscalar code is careful about multithreading issues
> (example: "if we morph to a string, first clear str_val so that after
> changing the vtable a parallel reader doesn't get a gargabe pointer"),
> but reuses a static PMC* intret.
Lets post
I've now committed the new (internal) calling scheme. On the surface
nothing has changed, at least, if the code obeys to the rules in
docs/pdds/pdd03_calling_conventions.pod.
If you are using PIR code and the function call directives all will
still work. PASM code or handcrafted calls have to t
StÃphane Payrard writes:
> That would allow to implement typechecking in imcc.
>
> .sym Scalar a
> a = new .PerlInt # ok. Perlint is derived from Scalar
Ugh, yeah, but what does that buy you? In dynamic languages pure
derivational typechecking is very close to useless. The reason C++[1]
h
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #32178]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32178 >
Currently there's no way to include a file using a relative path. This
is a bit li
With the indirect register addressing all prederefed run cores
(Prederefed, CGP, Switch) are currently not functional, as these run
cores have absolute addresses in the prederefed code.
I see two ways to fix it:
1) use frame pointer relative addressing:
+ prederefed code is usable by differen
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> this patch adds a benchmark for random access of different Array PMCs.
Thanks, applied.
> Their differences against /dev/null are part of the attached patch. Hope
> that works.
works fine.
leo
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I'm now converting to dynclasses. To be honest, I'm not thrilled with
this. What I would really prefer is a Parrot_new_p_s opcode with the
runtime worrying about caching class names across sub and module boundaries.
$P0 = new "Py_int"
o
I left the make for overnight :)
Here is the error I got..
xx.c
cc -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/includ
e/gdbm -g -Dan_Sugalski -Larry -Wall -Wstrict-prototypes
-Wmissing-prototypes -W
inline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strin
On Thu, Oct 28, 2004 at 04:49:26PM +0530, Vijay D. wrote:
>
> I left the make for overnight :)
> Here is the error I got..
>
> xx.c
> cc -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -I/usr/includ
> e/gdbm -g -Dan_Sugalski -Larry -Wall -Wstrict-prototypes
> -Wmissing-prototyp
> pass the --cgoto=0 flag to Configure.pl.
Thanks for the tip, I installed successfully ..
>I also have
>RH 9.0 and would love someone to confirm that make
>testj will fail on 3 tests (unless you additionally
>pass it another flag).
Here is the output for the fulltest on my redhat machine.
At 4:49 PM +0530 10/28/04, Vijay D. wrote:
I left the make for overnight :)
Here is the error I got..
xx.c
ops/core_ops_cg.c
cc1: Cannot allocate 56022680 bytes after allocating 116981760 bytes
gmake: *** [ops/core_ops_cg.o] Error 1
You just ran out of memory during the build. (If this is a server
At 11:13 AM +0200 10/28/04, Leopold Toetsch wrote:
With the indirect register addressing all prederefed run cores
(Prederefed, CGP, Switch) are currently not functional, as these run
cores have absolute addresses in the prederefed code.
I see two ways to fix it:
1) use frame pointer relative add
At 9:36 PM +0200 10/27/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 11:09 AM +0200 10/26/04, Leopold Toetsch wrote:
So, if you want that really super efficient, you would allocate
registers around function calls directly to that wanted register number,
which should be in the SymReg's want_reg
Dan Sugalski wrote:
Or 3) Toss the prederef stuff entirely.
Which might not be quite as bad as it sounds: on at least one "strange
platform" (IA64 HP-UX) the native C compiler gets the switch core
running faster than the prederef core! (!)
Duraid
Leopold Toetsch wrote:
Parrot_call() runs a Parrot subroutine, but it takes PMC arguments only
and provides no return value.
If no one hollers, I'll replace this function with a more flexible set
of functions that are wrappers to the *runops* functions in
src/inter_run.c:
void *Parro
Dan Sugalski wrote:
At 11:13 AM +0200 10/28/04, Leopold Toetsch wrote:
1) use frame pointer relative addressing:
+ prederefed code is usable by different threads too
- ~4 times increase in code size of core_ops_*.{c,o} [1]
2) Re-prederef on function calls, if frame pointer differs
+ no imp
Duraid Madina wrote:
Dan Sugalski wrote:
Or 3) Toss the prederef stuff entirely.
Which might not be quite as bad as it sounds: on at least one "strange
platform" (IA64 HP-UX) the native C compiler gets the switch core
running faster than the prederef core! (!)
Err, the switched core *is* a prede
Vijay D. <[EMAIL PROTECTED]> wrote:
> Failed 104/112 test scripts, 7.14% okay. 1851/1905 subtests failed,
> 2.83% okay.
> make: *** [testg] Error 2
Well, testing the now non-existing CGoto core with "make testg" is
probably not really helpfull ;)
> Regards,
> Vijay.
leo
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Yes, I meant the ability to do things like '$P0 = new "Py_int"'.
> Could this be JITed? The mapping between string class name and assigned
> PMC type is constant throughout the life of the VM...
Not really or not easily. Fastest is to have type enum numbers
On 10/27/04 Luke Palmer wrote:
> Stéphane Payrard writes:
> > That would allow to implement typechecking in imcc.
> >
> > .sym Scalar a
> > a = new .PerlInt # ok. Perlint is derived from Scalar
>
> Ugh, yeah, but what does that buy you? In dynamic languages pure
> derivational typechecking
So I've *finally* created a Perl.org account in order to update Parakeet
in CVS. As I understand it my next step is to inform the developers of
my username "michel" so that I can be given access to that area. I'm
got some exciting new changes to commit just as soon as I figure out if
they wor
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #32196]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32196 >
Parrot exploded when running my forth implementation after a cvs
update. Below is
Hi all,
Thanks for your continued comments. Btw, I usually read all the
parrot list, so don't think I'm not paying attention.
Currently, here's how the register allocator is doing.
Failed TestStat Wstat Total Fail Failed List of Failed
-
Bill~
I have to say that I am really impressed by all of the work that you
are doing, and if you can make the internals of imcc a little more
approachable, you would be doing a great service.
Thanks,
Matt
On Thu, 28 Oct 2004 15:08:23 -0700, Bill Coffman <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>
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
At 3:08 PM -0700 10/28/04, Bill Coffman wrote:
It passes the other tests, plus the
randomized tests that I created, up to 150 symbols. At that range, it
still takes about 20x longer than g++ -O2, for equivalent programs to
compile (see gen4.pl).
Still, that's not bad.
Also, it is currently runnin
When I cvs up'd, cleared and reConfigure'd I got these stats:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/library/streams.t1 256211 4.76% 11
t/op/gc.t 1 25618
Thanks Matt,
I hope I can help out. The patch I am submitting actually does
simplify register coloring a bit. I've been waiting for perl6 with so
much anticipation, I just couldn't stand it any more, and I had to
participate.
-Bill
On Thu, 28 Oct 2004 18:17:57 -0400, Matt Fowles <[EMAIL PROTE
Thanks for the info...
Apparently,
gcc -ansi -pedantic
is supposed to be ANSI C '89. Equiv to -std=c89. Also, my
Configure.pl generated make file uses neither -ansi nor -pedantic. I
do have access to a K&R C v2, but it doesn't look like it's going to
match the actual practice. Oh well.
30 matches
Mail list logo
