[CVS ci] JIT/NCI
I have put in the follwing patch:
- if CAN_BUILD_CALL_FRAMES is defined, call the JITed version
- if that returns zero, use the hardcoded version in nci.c
- else use hardcoded version
So you can implement signatures step by step.
If you are going to implement JITted NCI stubs:
1) create a function:
void *
Parrot_jit_build_call_func(Parrot_Interp interpreter, PMC *pmc_nci,
String *signature)
{
return NULL;
}
in jit/*/jit_emit.h
2) enable calling this for your architecture in
build_tools/build_nativecall.pl near line 180
3) make libnci.$(SO)
4) Implement signatures step by step
5) Have fun
leo
Re: Freezing strings?
Leopold Toetsch wrote: If it's just some busywork, such as copying some code into PerlString and tweaking it, I can probably do it, but I've been out of the loop for a while, so anything particularly involved is likely beyond me. The interfaces are all there. It *should* just be: - cut'n paste code from perlint - s/_integer/_string/ for (push, shift) and s/int_val/str_val/ It was. I've committed it, along with a test for it. All tests pass on Debian. I also tried to add freeze and thaw to PerlNum (as long as I was screwing around in that bit of the code), but the linker wasn't very happy with that--complained about being unable to find VTABLE_shift_number and VTABLE_push_number, so I undid that. By the way, I never realized how patient you gcc guys were with the computed-goto core--VC++ doesn't support it, so I didn't know that it took so long to compile. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia. [I *will* learn to use Thunderbird correctly one of these days!]
Re: [perl #27391] parrot -t crash
Jens Rieks [EMAIL PROTECTED] wrote: The following code crashes parrot if run with -t (trace). Fixed. That was not an easy one. A slightly wrong implementation (braino courtesy of leo) did reset interpreter-lo_var_ptr (the stack limit), when reentering the run loop, e.g. in object's __init calls. This lead to memory corruption if a DOD or GC was triggered inside the method call. During tracing, a lot of string handling is done, which sooner or later always exposed the bug. jens leo
Re: Freezing strings?
Brent Dax Royal-Gordon [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: The interfaces are all there. It *should* just be: - cut'n paste code from perlint - s/_integer/_string/ for (push, shift) and s/int_val/str_val/ It was. I've committed it, along with a test for it. All tests pass on Debian. Whee. FTL check in :) I also tried to add freeze and thaw to PerlNum (as long as I was screwing around in that bit of the code), but the linker wasn't very happy with that--complained about being unable to find VTABLE_shift_number and VTABLE_push_number, so I undid that. My fault. Mixed up shift_number vs shift_float. So the macros don't match. You could just rename in pmc_freeze.h: typedef struct _image_funcs s/_number/_float/ or call the functions explicitely. By the way, I never realized how patient you gcc guys were with the computed-goto core--VC++ doesn't support it, so I didn't know that it took so long to compile. Yep. Albeit newer gcc versions seem to be faster. BTW try an optimized compile ... leo
Re: Freezing strings?
Leopold Toetsch wrote: Brent Dax Royal-Gordon [EMAIL PROTECTED] wrote: I also tried to add freeze and thaw to PerlNum (as long as I was screwing around in that bit of the code), but the linker wasn't very happy with that--complained about being unable to find VTABLE_shift_number and VTABLE_push_number, so I undid that. My fault. Mixed up shift_number vs shift_float. So the macros don't match. You could just rename in pmc_freeze.h: Renaming did it. freeze/thaw for PerlNum checked in, with test. The first time I ran tests after compiling, I got a failure in t/pmc/signals.t--it thought that no tests had run, and the harness eventually reported 12/6 subtests of signals.t failed. Immediately re-running make test came out fine; I added the new PerlNum test to freeze.t and ran it a third time, which also passed. I guess it was a fluke. Yep. Albeit newer gcc versions seem to be faster. [EMAIL PROTECTED]/~/parrot% gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) So my compiler's almost as old as Parrot itself. Typical Debian. A project for the weekend, perhaps... -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Freezing strings?
Brent Dax Royal-Gordon [EMAIL PROTECTED] wrote: Renaming did it. freeze/thaw for PerlNum checked in, with test. Fine, thanks. The first time I ran tests after compiling, I got a failure in t/pmc/signals.t--it thought that no tests had run, and the harness eventually reported 12/6 subtests of signals.t failed. Immediately re-running make test came out fine; I added the new PerlNum test to freeze.t and ran it a third time, which also passed. I guess it was a fluke. It's mainly a problem with the test script (and likely timing of that). The test is of course a big hack. Yep. Albeit newer gcc versions seem to be faster. [EMAIL PROTECTED]/~/parrot% gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) Pah. That's a really new one ;) $ gcc -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) But ony my laptop I have: gcc-version 3.3.3 20040110 (prerelease) (Debian) So my compiler's almost as old as Parrot itself. Typical Debian. A project for the weekend, perhaps... $ apt-get install gcc # w. appropriate sources.list? leo
Re: [DOCS] Documentation tools
On 6 Mar 2004, at 05:31, Robert Spier wrote: [...] The problem isn't today. It's the trend and next month, when someone decides they need to add some other module, and has a precedent to follow. Then, suddenly we end up with 30 different modules included in our distribution, each one changed slightly from the CPAN one. Dual-lifed modules that live with perl5 are hard enough. I shoved Pod::Simple in because I had problems with the Pod modules in the Perl distribution and the people on pod-people assured me Pod::Simple was the way to go. It was the soft option, i wanted people to be able to build the html docs easily, and I took the existence of the other modules in lib as examples of how to go about it. So, yes, precedent is the problem. Which is why I'd prefer if we could decide what the rule is and apply it to Pod::Simple etc* now, so that it sets the correct precedent. I have held off modifying it, so that it can be removed if necessary. Also, Dan, is it inherently bad to to install perl modules off the 'net, or, just bad for Parrot's config to do it? Would it be acceptable for write_docs.pl to do it? Or, do you mean that the distribution has to be complete in itself, so that it can be installed off a cd on a network-less box and run? Lastly, if we use Leo's prominent notes approach, is that note in the end not just going to be: To install the additional Perl modules required by Parrot run the following command in a shell: perl -MCPAN -e 'CPAN::Shell-install(Parrot::Bundle) Mike [*] Class::Struct has been patched to work with 5.005_03. Digest::Perl::MD5 is unmodified except where I changed the bang perl line. Parse::Parse::RecDescent has been modified for perl6. Pod::Simple unmodified. Test::More, only Test::Builder has been modified. Text::Balanced is unmodified.
A Perl Task - Benchmarking
I'd a short look at perlbench from CPAN. This inspired me to the following idea: examples/benchmarks/* has a bunch of programs e.g. oo1.pasm oo1.pl oo1.py stress.pasm stress.pl ... Now like perlbench is able to compare run times of different perl versions, the goal of this task is to provide a script that compares different interpreters and finally spits out: Parrot-j Parrot-C PerlPython Ruby oo1 100%103% 75% 50% - mops 100%200% 4% stress ... - - or some such. To simplify the task, we could of course move used tests into a separate directory. Unavailable interpreters (or missing scripts for that language) are just skipped. Any takers? leo
[perl #27469] [PATCH] Use named constants in iterator.pod
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #27469] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27469 Hi, this patch is just a little documentation update in 'docs/iterator.pod'. Now named constants are used for setting up the iterator in the examples. There was even a little bug, .ITERATE_FROM_END is no longer 3, but 4. There is now also a PIR test in 't/pmc/iter.t'. CU, Bernhard -- /* [EMAIL PROTECTED] */ +++ NEU bei GMX und erstmalig in Deutschland: TV-geprfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz iterator_20040306.patch Description: Binary data
Re: [perl #27469] [PATCH] Use named constants in iterator.pod
Hi, On Saturday 06 March 2004 13:55, Bernhard Schmalhofer wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #27469] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27469 Hi, this patch is just a little documentation update in 'docs/iterator.pod'. Now named constants are used for setting up the iterator in the examples. This file is automatically generated from classes/iterator.pmc There was even a little bug, .ITERATE_FROM_END is no longer 3, but 4. There is now also a PIR test in 't/pmc/iter.t'. CU, Bernhard jens
[perl #27465] [PATCH] Library to access configuration info
# New Ticket Created by Brent Dax
# Please include the string: [perl #27465]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27465
The attached patch creates a Parrot-level library similar to Parrot::Config.
There are three components to this:
1. A .pasm file, generated at Configure time and run at make time
(just after $(TEST_PROG) is built), which creates a PerlHash and
freezes it to...
2. A file, Flibrary/config.fpmc (for Frozen PMC), which is usually
accessed by...
3. An IMCC library, Flibrary/config.imc, which contains a
subroutine to open, unfreeze, and return the configuration.
This approach has two benefits:
1. The configuration data is always for the *current* machine, rather
than the machine on which Fconfig.imc was assembled/linked in.
2. It avoids bloating bytecode files that use Fconfig.imc.
Flibrary/config.imc and Fconfig/gen/config_pm/config_lib.in are the
only new files added to CVS; Fconfig/gen/config_pm.pl,
Fconfig/gen/makefiles/root.in, and FMANIFEST are also touched.
There are no tests because I don't know where to put them.
One potentially controversial aspect of this patch is that it means that
Parrot is invoked during the make process, before it's been tested. I
don't see any easy way around this, short of re-implementing PMC
freezing in Perl 5, allowing Configure to write Fconfig.fpmc itself.
Fconfig.fpmc does not contain all of the configuration data--Parrot
seems to segfault when fed some of the really long values[1], so it
doesn't include any entry with a newline in it. On my Debian box,
Fconfig.fpmc weighs in at around 15k.
As currently implemented, you must be in Flibrary/'s parent directory
(i.e. the Parrot root directory) to make use of Flibrary/config.imc.
I'm not sure what I can do about that yet.
The following PIL will dump your entire configuration to stdout:
.sub _main
.local PerlHash config
config=_config()
_dumper(config, config)
end
.end
.include library/config.imc
.include library/dumper.imc
I'm going to bed now. Good night.
[1] Said really long values are cases where someone inserted a key
into the Configure data for the sole purpose of interpolating it into a
particular file--a Configure no-no. I may rant on this practice in the
near future.
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
? config/gen/config_pm/config_lib.in
? library/config.imc
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.580
diff -u -r1.580 MANIFEST
--- MANIFEST6 Mar 2004 07:35:18 - 1.580
+++ MANIFEST6 Mar 2004 11:09:14 -
@@ -110,6 +110,7 @@
config/gen/config_h.pl[]
config/gen/config_h/config_h.in []
config/gen/config_pm.pl []
+config/gen/config_pm/config_lib.in[]
config/gen/config_pm/Config_pm.in []
config/gen/core_pmcs.pl []
config/gen/feature_h.pl []
@@ -2302,6 +2303,7 @@
lib/Test/Simple.pm[devel]
lib/Text/Balanced.pm [devel]
libnci.def[]
+library/config.imc[devel]
library/dumper.imc[devel]
library/libpcre.imc [devel]
library/ncurses.declarations [devel]
Index: config/gen/config_pm.pl
===
RCS file: /cvs/public/parrot/config/gen/config_pm.pl,v
retrieving revision 1.3
diff -u -r1.3 config_pm.pl
--- config/gen/config_pm.pl 26 Feb 2004 00:43:05 - 1.3
+++ config/gen/config_pm.pl 6 Mar 2004 11:09:17 -
@@ -19,7 +19,7 @@
use Parrot::Configure::Step;
use Data::Dumper;
-$description=Writing Parrot::Config module...;
+$description=Writing configuration data modules for Perl 5 and Parrot...;
@args=();
@@ -36,6 +36,38 @@
close IN or die Can't close Config_pm.in: $!;
close OUT or die Can't close Config.pm: $!;
+
+ open(IN, config/gen/config_pm/config_lib.in) or die Can't open config_lib.in:
$!;
+ open(OUT, config_lib.pasm) or die Can't open config_lib.pasm: $!;
+
+ print OUT END;
+# Generated by config/gen/config_pm.pl
+# This file should be the last thing run during
+# the make process, after Parrot is built.
+END
+
+ while(IN) {
+if(/HERE/) {
+ my $k;
+ for $k(Configure::Data-keys) {
+ my $v=Configure::Data-get($k);
+ if(defined $v) {
+ next if $v =~ /\n/;
+ $v =~ s/([\\])/\\$1/g;
+
Re: [perl #27469] [PATCH] Use named constants in iterator.pod
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: this patch is just a little documentation update in 'docs/iterator.pod'. Now named constants are used for setting up the iterator in the examples. Thanks, applied. leo
Re: [perl #27469] [PATCH] Use named constants in iterator.pod
Jens Rieks [EMAIL PROTECTED] wrote: Hi, On Saturday 06 March 2004 13:55, Bernhard Schmalhofer wrote: this patch is just a little documentation update in 'docs/iterator.pod'. This file is automatically generated from classes/iterator.pmc Actually the patch is against docs/pmc/iterator.pod, which is fine. leo
Re: A Perl Task - Benchmarking
Hi Leo, Attached is a quick'n dirty parrotbench, instead of a complicated test harness it uses bash to make time measurements, so that new languages are very simple to add. Currently it's just a proof of concept but if you like it i will make a better version with pretty printing, extended reports and stuff. Here's an example run: parrotperl python ruby addit 8.469 7.379 - - arriter- 1.657 - - bench_newp 1.827 - - - fib - 0.594 - - freeze 0.783 1.65 - - gc_alloc_new 0.191 -- - gc_alloc_reuse 4.068 - - - gc_generations 6.363 - - - gc_header_new 1.168 - - - gc_header_reuse 5.772 - - - gc_waves_headers 1.302 - - - gc_waves_sizeable_data1.074 - - - gc_waves_sizeable_headers 3.702 - - - oo1 3.571 1.189 0.689 - primes 27.991 383.851- - primes2 17.325 - 44.379 - primes2_p 29.753 - - - prop0.14 - - - shared_ref 0.55211.563 - - stress 1.988 0.905 - - stress1 27.53917.312 - - stress23.908 3.440 - - stress3 19.050 - - - utf8 0.13 - - - vpm- 40.057 - - Cheers, Sebastian Leopold Toetsch wrote: I'd a short look at perlbench from CPAN. This inspired me to the following idea: examples/benchmarks/* has a bunch of programs e.g. oo1.pasm oo1.pl oo1.py stress.pasm stress.pl ... Now like perlbench is able to compare run times of different perl versions, the goal of this task is to provide a script that compares different interpreters and finally spits out: Parrot-j Parrot-C PerlPython Ruby oo1 100%103% 75% 50% - mops 100%200% 4% stress ... - - or some such. To simplify the task, we could of course move used tests into a separate directory. Unavailable interpreters (or missing scripts for that language) are just skipped. Any takers? leo parrotbench.patch.gz Description: application/tgz
