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
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 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.
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
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
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,
>
>
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
-
# 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
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
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
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
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
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
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:
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
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
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 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
> 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.
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
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
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
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
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
# 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
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
Aaron Sherman writes:
> > The current syntax for what you're
> > trying to write is:
> >
> > /ab(c|b) <($1 eq 'c')>/
> >
> > which is equivalent to
> >
> > /ab(c|b) {fail unless $1 eq 'c'}/
>
> Now, what does "fail" mean? I can think of two definitions:
>
> 1. proceed to trap s
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
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
31 matches
Mail list logo
