Re: Another deadlock on Mac OS 10.5.1
I was able to reproduce the identical deadlock on Mac OS 10.5.1, though it appears to occur only ever 2 or three times that that particular test is run. I caught it in gdb, and get the info below. I'm new to the internals of Parrot, so other than seeming like a race condition, nothing jumped out at me. Let me know if I can provide more information. -Tupshin (gdb) run -D40 -gc-debug /usr/src/parrot/t/stm/basic_mt_2.pir Starting program: /usr/src/parrot/parrot -D40 -gc-debug /usr/src/parrot/t/stm/basic_mt_2.pir ^C Program received signal SIGINT, Interrupt. 0x9681aace in __semwait_signal () (gdb) bt #0 0x9681aace in __semwait_signal () #1 0x96845306 in _pthread_cond_wait () #2 0x96844ced in pthread_cond_wait$UNIX2003 () #3 0x000b9a66 in pt_gc_wait_for_stage (interp=0x500180, from_stage=THREAD_GC_STAGE_NONE, to_stage=THREAD_GC_STAGE_MARK) at src/thread.c:987 #4 0x000ba93e in pt_DOD_start_mark (interp=0x500180) at src/thread.c:1573 #5 0x0006f024 in Parrot_dod_ms_run (interp=0x500180, flags=1) at src/gc/dod.c:1126 #6 0x000b9de7 in pt_suspend_self_for_gc (interp=0x500180) at src/thread.c:1167 #7 0x000b8b41 in pt_thread_wait (interp=0x500180) at src/thread.c:395 #8 0x000b9f10 in pt_thread_join (parent=0x500180, tid=2) at src/thread.c:1207 #9 0x001e184a in Parrot_ParrotRunningThread_nci_join (interp=0x500180, pmc=0x73cdf0) at parrotrunningthread.pmc:100 #10 0x0008fa06 in pcf_P_JO (interp=0x500180, self=0x6e3060) at src/nci.c:3781 #11 0x00165f18 in Parrot_NCI_invoke () #12 0x0001af64 in Parrot_callmethodcc_p_sc (cur_opcode=0x51cae4, interp=0x500180) at object.ops:70 #13 0x000b01bf in runops_slow_core (interp=0x500180, pc=0x51cae4) at src/runops_cores.c:211 #14 0x0007b4e3 in runops_int (interp=0x500180, offset=52) at src/interpreter.c:876 #15 0x0007bfe7 in runops (interp=0x500180, offs=52) at src/inter_run.c:104 #16 0x0007c27a in runops_args (interp=0x500180, sub=0x6e04b0, obj=0x82e048, meth_unused=0x0, sig=0x257832 vP, ap=0xb43c ?\004n) at src/inter_run.c:230 #17 0x0007c3b9 in Parrot_runops_fromc_args (interp=0x500180, sub=0x6e04b0, sig=0x257832 vP) at src/inter_run.c:299 #18 0x0006a3ec in Parrot_runcode (interp=0x500180, argc=1, argv=0xb554) at src/embed.c:886 #19 0x0021fa19 in imcc_run_pbc (interp=0x500180, obj_file=0, output_file=0x0, argc=1, argv=0xb554) at compilers/imcc/main.c:788 #20 0x002204bd in imcc_run (interp=0x500180, sourcefile=0xb62a /usr/src/parrot/t/stm/basic_mt_2.pir, argc=1, argv=0xb554) at compilers/imcc/main.c:1069 #21 0x1dee in main (argc=1, argv=0xb554) at src/main.c:62
Re: Another deadlock on Mac OS 10.5.1
I was able to reproduce the identical deadlock on Mac OS 10.5.1, though it appears to occur only ever 2 or three times that that particular test is run. I caught it in gdb, and get the info below. I'm new to the internals of Parrot, so other than seeming like a race condition, nothing jumped out at me. Let me know if I can provide more information. -Tupshin (gdb) run -D40 -gc-debug /usr/src/parrot/t/stm/basic_mt_2.pir Starting program: /usr/src/parrot/parrot -D40 -gc-debug /usr/src/parrot/t/stm/basic_mt_2.pir ^C Program received signal SIGINT, Interrupt. 0x9681aace in __semwait_signal () (gdb) bt #0 0x9681aace in __semwait_signal () #1 0x96845306 in _pthread_cond_wait () #2 0x96844ced in pthread_cond_wait$UNIX2003 () #3 0x000b9a66 in pt_gc_wait_for_stage (interp=0x500180, from_stage=THREAD_GC_STAGE_NONE, to_stage=THREAD_GC_STAGE_MARK) at src/thread.c:987 #4 0x000ba93e in pt_DOD_start_mark (interp=0x500180) at src/thread.c:1573 #5 0x0006f024 in Parrot_dod_ms_run (interp=0x500180, flags=1) at src/gc/dod.c:1126 #6 0x000b9de7 in pt_suspend_self_for_gc (interp=0x500180) at src/thread.c:1167 #7 0x000b8b41 in pt_thread_wait (interp=0x500180) at src/thread.c:395 #8 0x000b9f10 in pt_thread_join (parent=0x500180, tid=2) at src/thread.c:1207 #9 0x001e184a in Parrot_ParrotRunningThread_nci_join (interp=0x500180, pmc=0x73cdf0) at parrotrunningthread.pmc:100 #10 0x0008fa06 in pcf_P_JO (interp=0x500180, self=0x6e3060) at src/nci.c:3781 #11 0x00165f18 in Parrot_NCI_invoke () #12 0x0001af64 in Parrot_callmethodcc_p_sc (cur_opcode=0x51cae4, interp=0x500180) at object.ops:70 #13 0x000b01bf in runops_slow_core (interp=0x500180, pc=0x51cae4) at src/runops_cores.c:211 #14 0x0007b4e3 in runops_int (interp=0x500180, offset=52) at src/interpreter.c:876 #15 0x0007bfe7 in runops (interp=0x500180, offs=52) at src/inter_run.c:104 #16 0x0007c27a in runops_args (interp=0x500180, sub=0x6e04b0, obj=0x82e048, meth_unused=0x0, sig=0x257832 vP, ap=0xb43c ?\004n) at src/inter_run.c:230 #17 0x0007c3b9 in Parrot_runops_fromc_args (interp=0x500180, sub=0x6e04b0, sig=0x257832 vP) at src/inter_run.c:299 #18 0x0006a3ec in Parrot_runcode (interp=0x500180, argc=1, argv=0xb554) at src/embed.c:886 #19 0x0021fa19 in imcc_run_pbc (interp=0x500180, obj_file=0, output_file=0x0, argc=1, argv=0xb554) at compilers/imcc/main.c:788 #20 0x002204bd in imcc_run (interp=0x500180, sourcefile=0xb62a /usr/src/parrot/t/stm/basic_mt_2.pir, argc=1, argv=0xb554) at compilers/imcc/main.c:1069 #21 0x1dee in main (argc=1, argv=0xb554) at src/main.c:62
Re: problems grabbing darcs repo
Greg Buchholz wrote: ...Well sure enough, there is no Compile.hs in my src/ directory. Digging around a little bit, I notice that there is a Compile.hs in... http://wagner.elixus.org/~autrijus/darcs/pugs/src/ ...but not in... http://wagner.elixus.org/~autrijus/darcs/pugs/_darcs/current/src/ Knowing nothing about darcs, this may be a red herring. Anyone have a clue as to why my machine doesn't appear to have the latest greatest version of pugs? (I've got GHC 6.4, perl 5.8.6, darcs 1.0.2) I get the same error. That doesn't seem like a red herring (knowing a bunch about darcs and not much about pugs). The _darcs/current/ directory should contain a pristine copy of everything that has been recorded in the darcs repository, and the fact that those files are not there, but are in the main working directory certainly indicates that a bunch of files have not been recorded using darcs. I used wget -r to pull down the entire darcs repo, including the working directory, and then ran darcs whatsnew --look-for-adds --summary to generate a list of files that don't seem to have been recorded with darcs, and got the list of 150 files below. I have recorded a naive darcs patch that adds these files. You can pull it from: http://69.233.54.134/pugs/, though if you do pull it, you will want to unpull it after the main repo is fixed to avoid conflicts. Can somebody in charge of the pugs repo explain the reason for the missing files? -Tupshin a ./LICENSE/GHC a ./examples/golf/rg0now-head.p6 a ./examples/golf/rg0now-mid.p6 a ./examples/golf/rg0now-rev.p6 a ./examples/golf/rg0now-tail.p6 a ./examples/golf/rg0now-wc.p6 a ./examples/golf/tsanta.p6 a ./examples/mandel.p5 a ./examples/output/junctions/ a ./examples/output/junctions/1 a ./examples/output/junctions/3 a ./examples/output/junctions/all-all a ./examples/output/junctions/all-any a ./examples/output/junctions/any-any a ./examples/output/junctions/any-any2 a ./examples/output/junctions/grades a ./ext/FileSpec/ a ./ext/FileSpec/lib/ a ./ext/FileSpec/lib/File/ a ./ext/FileSpec/t/ a ./ext/FileSpec/t/01_file_spec_test.t a ./ext/FileSpec/t/10_unix_test.t a ./ext/FileSpec/t/11_unix_test_p5.t a ./ext/FileSpec/t/20_win32_test.t a ./ext/FileSpec/t/21_win32_test_p5.t a ./ext/Perl5-Kwid/doc/ a ./ext/Perl5-Kwid/doc/kwidinput.pod a ./ext/Perl5-Kwid/doc/poddomspec.pod a ./ext/Perl5-Kwid/t/data1 a ./ext/Perl5-Kwid/t/to_html1.t a ./ext/SHA1/ a ./ext/SHA1/lib/ a ./ext/SHA1/lib/SHA1.pm a ./ext/SHA1/src/ a ./ext/SHA1/src/SHA1.hs a ./ext/SHA1/t/ a ./ext/SHA1/t/sha1.t a ./modules/CGI-Lite/ a ./modules/Commands-Guarded/ a ./modules/Commands-Guarded/lib/ a ./modules/Commands-Guarded/lib/Commands/ a ./modules/Commands-Guarded/t/ a ./modules/Commands-Guarded/t/01use.t a ./modules/Commands-Guarded/t/02nullop.t a ./modules/Commands-Guarded/t/03trivial.t a ./modules/Commands-Guarded/t/04exception.t a ./modules/Commands-Guarded/t/05sanity.t a ./modules/Commands-Guarded/t/06rollback.t a ./modules/Commands-Guarded/t/07doforeach.t a ./modules/Config-Tiny/ a ./modules/Config-Tiny/lib/ a ./modules/Config-Tiny/lib/Config/ a ./modules/Config-Tiny/t/ a ./modules/Config-Tiny/t/01_main.t a ./modules/Config-Tiny/test.conf a ./modules/Email-Simple/ a ./modules/Email-Simple/lib/ a ./modules/Email-Simple/lib/Email/ a ./modules/Email-Simple/t/ a ./modules/Email-Simple/t/1.t a ./modules/Email-Simple/t/2.t a ./modules/Email-Simple/t/3.t a ./modules/Email-Simple/t/4.t a ./modules/Email-Simple/t/test-mails/ a ./modules/Geo-Distance/ a ./modules/Geo-Distance/lib/ a ./modules/Geo-Distance/lib/Geo/ a ./modules/Getopt-Std/ a ./modules/Getopt-Std/lib/ a ./modules/Getopt-Std/lib/Getopt/ a ./modules/Getopt-Std/t/ a ./modules/Getopt-Std/t/tests.t a ./modules/Locale-KeyedText/t/Locale_KeyedText.t a ./modules/MIME-Lite/ a ./modules/MIME-Lite/lib/ a ./modules/MIME-Lite/lib/MIME/ a ./modules/MIME-Lite/t/ a ./modules/Mail-Address/ a ./modules/Mail-Address/lib/ a ./modules/Mail-Address/lib/Mail/ a ./modules/Mail-Address/t/ a ./modules/Mail-Address/t/extract.t a ./modules/Tree-Simple/ a ./modules/Tree-Simple/lib/ a ./modules/Tree-Simple/lib/Tree/ a ./modules/Tree-Simple/t/ a ./modules/Tree-Simple/t/10_Tree_Simple_test.t a ./modules/Tree-Simple/t/11_Tree_Simple_fixDepth_test.t a ./modules/Tree-Simple/t/12_Tree_Simple_exceptions_test.t a ./modules/Tree-Simple/t/13_Tree_Simple_clone_test.t a ./modules/Tree-Simple/t/14_Tree_Simple_leak_test.t a ./modules/Tree-Simple/t/14a_Tree_Simple_weak_refs_test.t a ./modules/Tree-Simple/t/15_Tree_Simple_height_test.t a ./modules/Tree-Simple/t/16_Tree_Simple_width_test.t a ./modules/Tree-Simple/t/20_Tree_Simple_Visitor_test.t a ./modules/URI/ a ./modules/URI/lib/ a ./modules/URI/lib/URI/ a ./modules/URI/lib/URI.pm a ./modules/URI/t/ a ./modules/URI/t/abs.t a ./modules/URI/t/data.t a ./modules/URI/t/escape.t a ./modules/URI/t/file.t a ./modules/URI/t/ftp.t a ./modules/URI/t/generic.t a ./modules/URI/t/heuristic.t a ./modules/URI/t/http.t a ./modules/URI/t/ldap.t a
Re: extproc_parrot
Jeff Horwitz wrote: after many days of swimming through source code, i've successfully built a library that lets you embed parrot in oracle. this was important to me because for extproc_perl (embeds perl in oracle) to have a future with perl 6, i had to embed parrot. what makes this even cooler is that now we can embed other languages like python (via pirate or equivalent), BASIC (sick, i know, but that should be possible now), and whatever other languages are targeted to parrot. There's something sublimely satisfying about being able to embed bf in Oracle. Thank you. ;-) -Tupshin
Re: This week's summary
Rhys Weatherley wrote: Have a look at the Portable.NET FAQ, which describes some of the difficulties in targetting stack machines with gcc. http://www.southern-storm.com.au/pnet_faq.html#q4_7 Cheers, Rhys. Yeah...I've read that before. But it doesn't mention the possibility of emulating a more traditional CPU that could be targeted by gcc. -Tupshin
Re: This week's summary
Paolo Molaro wrote: Traditional processors aren't stack-oriented, not even ones that are more register-starved than the x86 family. (I'm thinking of the 6502 with it's 1.75 registers here) The wording stack-oriented processor is a little misleading, since it usually means the processor has a stack-oriented instruction set, instead of a register one. The original context, instead, implies it refers to GCC's assumptions about the existence of the runtime stack (as the contiguous area of memory where call frames are stored). Exactly. I think a gcc port would require parrot to provide at least a stack memory area and a register (sp) that points to it. There may be other issues with the parrot instruction set, but since you have already hundreds (or thousands?) of opcodes, I guess it wouldn't be an issue to add a few more if needed:-). This exactly mirrors my thinking on the issue. -Tupshin
Re: This week's summary
Piers Cawley wrote: Targeting Parrot from GCC Discussion in the thread entitled 'WxWindows Support / Interfacing Libraries' centred on writing a Parrot backend to GCC. (No, I have no idea what that has to do with the thread subject.) Tupshin Harper, Leo Tötsch and Benjamin Goldberg discussed possibilities and potential pit/pratfalls. At one point, Tupshin suggested emulating a 'more traditional stack-oriented processor' and I don't think he was joking... Indeed, I wasn't, but I wish somebody would at least have the decency to tell me how insane this is. ;-) -Tupshin
Re: wxWindows Support / Interfacing libraries with Parrot
Leopold Toetsch wrote: Tupshin Harper wrote: I'm not a GCC person, but I do have an interest in this working. I did some exploratory work (mostly getting familiar with the GCC backend mechanism and with PASM), and quickly ran into what appeared to be fundamental roadblocks regarding gcc's predilection for generating stack-oriented assembly. Do you have some insights into what the most viable path for GCC---pasm could be? No :-) Most processors work stack-oriented. AFAIK does have the ia64 cpu some deviations like register windows. But parrot - and the more with CPS subroutines - is really different. And parrot has a different ABI too. Translating IReg and Nreg operations wouldn't be too hard, but what about strings (and functions) and objects. I think, that is impossible. I'm confused...it sounds like you are talking about translating pbc-regular CPU, and I'm thinking the opposite. Targeting native C is not a primary goal, just some nice to have. IIRC do the mono people have a C parser too and there are some thoughts to translate C/C# to parrot, so I can imagine, that there might be some more in the future. -Tupshin leo Here's a wacky idea. What about emulating a more traditional stack-oriented processor in parrot? (What...surely you jest). Seriously, though, it might actually be a really thin emulation layer. You add some PMC's to handle C-style stacks and any other CPU oddities that would be expected of a back-end by a compiler. How complicated could it be? Obviously performance would suffer, but it seems workable. -Tupshin
Re: wxWindows Support / Interfacing libraries with Parrot
Benjamin Goldberg wrote: Leopold Toetsch wrote: Tupshin Harper wrote: I'm not a GCC person, but I do have an interest in this working. I did some exploratory work (mostly getting familiar with the GCC backend mechanism and with PASM), and quickly ran into what appeared to be fundamental roadblocks regarding gcc's predilection for generating stack-oriented assembly. Do you have some insights into what the most viable path for GCC---pasm could be? No :-) Most processors work stack-oriented. AFAIK does have the ia64 cpu some deviations like register windows. But parrot - and the more with CPS subroutines - is really different. And parrot has a different ABI too. Translating IReg and Nreg operations wouldn't be too hard, but what about strings (and functions) and objects. I think, that is impossible. Since the discussion is (gcc-produced-)assembly to pasm, we're fortunate... there aren't any objects to translate from asm to pasm :) For strings, the real challenge is identifying when the assembler is manipulating something which should be thought of as a string, or when it is manipulating something which should be thought of as an array of character-sized integers; then we use either Sreg operations, or Preg operations (operating on some Array (sub-)type). My point with my previous response to Leopold's mail was that you could actually do CPU emulation at such a low parrot level that you wouldn't even have to do that (e.g. identify strings vs. array of int's) initially. You emulate at the register and opcode level. Performance would suffer (quite a bit), but you could get it working pretty easily. Then it's a matter of gradual optimization to recognize lower level structures that can map to more complex higher level parrot equivalents. -Tupshin
Re: wxWindows Support / Interfacing libraries with Parrot
Leopold Toetsch wrote: Why the smilies ;-) Parrot is a fine processor well suited for an optimizing compiler and with a reasonable architecture. Its not the first time that I'm thinking of such a hack. ... though it would need some extensions at both sides. Are some gcc people listening? leo I'm not a GCC person, but I do have an interest in this working. I did some exploratory work (mostly getting familiar with the GCC backend mechanism and with PASM), and quickly ran into what appeared to be fundamental roadblocks regarding gcc's predilection for generating stack-oriented assembly. Do you have some insights into what the most viable path for GCC---pasm could be? -Tupshin
sablevm
Has anybody involved in parrot taken a look at SableVM? It's an interesting Java VM, done as a doctoral thesis. http://www.sablevm.org The thesis covers some interesting optimizations(don't know if any could apply to parrot). http://www.info.uqam.ca/%7Eegagnon/gagnon-phd.pdf -Tupshin
c-style assembly in .pasm
In my ongoing quest to understand the possibilities (and possible
limitations) of parrot, here's another one. ;-)
How close a mapping can there be between regular (x86 in this example)
assembly (as generated by c-compilation) and pasm?
I can't figure out if the stack ops can approximate this kind of thing.
Issues I don't understand are inline in the assembly.
---test.c-
int main(){
int i=5;
i++;
}
-test.s
main:
pushl %ebp
movl%esp, %ebp
subl$8, %esp ; Is there a stack pointer to move?
andl$-16, %esp
movl$0, %eax
subl%eax, %esp
movl$5, -4(%ebp); Is there any analogue to bit/byte
sized offsets?
leal-4(%ebp), %eax ; Or is the granularity strictly at the
item level?
incl(%eax); can you modify an element on
the stack in place?
leave
ret
-Tupshin
Re: Parrot 0.0.10 freeze
Benjamin Goldberg wrote: African Grey, Brotogeris, Parakeet, Budgerigar, Budgie, Cockatiel, Cockatoo, Conure, Eclectus, Kakapo, Lory, Lorikeet, Lovebird, Macaw, Parrotlet, Pionus, Poicephalus, Quaker, Ringneck? Since we don't have any of objects, exceptions, or a real IO system, I would suggest Kakapo (which is a kind of weird flightless parrot). Once we do have these things (0.1 or 0.2 ? ) how about codename greencheeks for the Green-cheaked parrot? -Tupshin
Re: access to partial registers?
Dan Sugalski wrote: At 6:54 PM -0800 2/22/03, Tupshin Harper wrote: Sorry for all the questions...these are the trials and tribulations of dealing with a newbie trying to get up to speed with the current state of parrot. So here's another question: Is it possible and/or meaningful to read and write from a part of a register(e.g. a single word) in pasm? At the moment no, and they'd only really be useful for the integer registers. Having said that, which ones would you want? I don't mind us thinking about an intreg.ops set. I actually *don't* necessarily want to. The question only came up becasue virtually all real CPUs allow you to do this to conserve registers, and I'm just trying to understand how and why a VM like parrot diverges from the concepts/semantics of a real CPU. If this kind of optimization is to take place, it sems like it would have to take place on the fly (JIT level) once the system knew what kind of target CPU it was running on, and that it wouldn't be meaningful to do so at the pasm or pbc generation levels(except possibly as a hinting mechanism). Does this make sense, or am I smoking crack? -Tupshin
non-inline text in parrot assembly?
Parrot assembly supports inline strings, but are there any plans to have it support a distinct .string (or similar) asm section? The main benefit would be easier compatibility/portability with existing assembly code generators. Is anybody aware of an existing assembly format that doesn't support a separate string section? -Tupshin
Re: non-inline text in parrot assembly?
Leopold Toetsch wrote: Tupshin Harper wrote: Thanks. Apparently I'm being daft. I don't see any mention of pasm sections(constant or otherwise) in the pod docs, nor do any of the examples appear to use a constants section. What am I missing? Sorry nothing. There are only IIRC 3 tests in parrot and 3 in imcc using these features. $ perldoc assemble.pl Actually you're wrong ;-) I was missing something, and that of course was perldoc assemble.pl. ;-) Thanks for the pointer, that contains a *lot* of information that doesn't appear to be anywhere else(.constant, for example, is never mentioned in docs/*.pod). But they are not very well covered in the main docs. I would vote to move virtually all of this information out of assemble.pl and into docs/parrot_assembly.pod (or something similar), and have the perldoc for assemble.pl just be an overview + usage information. Thanks. -Tupshin
Re: non-inline text in parrot assembly?
Leopold Toetsch wrote: You can use the .constant (PASM) or .const (IMCC) syntax, to keep strings visually together. leo Thanks. Apparently I'm being daft. I don't see any mention of pasm sections(constant or otherwise) in the pod docs, nor do any of the examples appear to use a constants section. What am I missing? -Tupshin
access to partial registers?
Sorry for all the questions...these are the trials and tribulations of dealing with a newbie trying to get up to speed with the current state of parrot. So here's another question: Is it possible and/or meaningful to read and write from a part of a register(e.g. a single word) in pasm? As with my previous questions, I'm not really interested in pbc issues/format(with exceptions of course), just learning the intricacies of pasm. -Tupshin
Re: Using imcc as JIT optimizer
Leopold Toetsch wrote: Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm) Lol...what are you going to do when somebody comes along with the unbearable example of primes.s(optimized x86 assembly), and you are forced to throw up your hands in defeat? ;-) Cool idea, if I understand correctly, and I am in awe of how fast the bloody thing is already. -Tupshin
bit rot (and other tribulations) in parrot/languages/*
A number of the language examples in parrot seem to not work as well as they once might have(or should). The learning curve to get familiar something like parrot is much easier if things like this just work. So, if anybody cares, here's the list of issues I ran into in the languages directory: ook: executing: parrot ook.pbc generates: invoke() not implemented in class 'PerlUndef' basic: no instructions on how to actually run the .bas examples. Tried a few thing like parrot basic.pbc eliza.bas and got nothing but BAD KEYWORD. Probably my usage error, but at a loss how to use it. Befunge-93: Trivial, but a fresh cvs checkout has a lingering empty Befunge-93 directory. cola: doesn't compile bison -v -y -d -o parser.c cola.y cola.y:75.7-11: type redeclaration for class_decl cola.y:84.7-11: type redeclaration for element_access cola.y:91.7-11: type redeclaration for relational_expr cola.y:91.7-11: type redeclaration for equality_expr forth: not an error, but no examples of usage tried a helloworld, but didn't get anywhere miniperl: make fails t/harness make: t/harness: Command not found make: *** [test] Error 127 parrot_compiler: unclear what its relationship(if any) to the top level assemble.pl is. Looks like it might be a proof of concept assembler written in native parrot, but a little unclear. A tiny readme would be good. Also, tried ../../parrot pc.pbc and got no such file or directory. When I did ../../parrot pc.pbc sample.pasm, I didn't get an error, but it didn't do anything. perl6: The perl6 interpreter/compiler is fine, but some it's examples are broken: qsort.p6: get_pmc_keyed() not implemented in class 'PerlUndef' bnf.p6: Undefined subroutine P6C::Tree::concat_string called at P6C/Tree.pm line 1053. qsort.p6: [IMCC::add_function (diagnostic) main] Redefining function reverse [IMCC::add_function (diagnostic) main] Redefining function main error:imcc:mk_address file examples/qsort.imc line 73: Label '_reverse' already defined Error: '../imcc/imcc -oexamples/qsort.pasm examples/qsort.imc' failed with exit code 1 Stopped at ./perl6 line 312, DATA chunk 155. ruby: absolutely no idea what the status of this one is. The README is a placeholder. -Tupshin
parrot performance vs.(trivial test) the good, the bad, and the ugly
In case anyone is interested. On a whim I took the primes.pasm example from the parrot examples page and converted it to both c and perl5, with _interesting_ results. Timing all three with a max of 100,000 produced the following results: c -primes.c(lickety split): real0m7.710s user0m6.790s sys 0m0.030s parrot primes.pasm(default options not too impressive): real0m33.289s user0m29.130s sys 0m0.080s parrot primes.pasm(with -P...a bit better) real0m21.063s user0m20.000s sys 0m0.050s parrot primes.pasm (with jit -j option--omfg...i'm impressed) real0m12.625s user0m11.610s sys 0m0.040s perl5 primes.pl(ouch!, yes...this is the same algorithm) real6m53.454s user6m33.490s sys 0m0.990s FYI...all three used the identical algorithm taken from the primes.pasm example complete with labels and gotos(makes for very disconcerting perl code). Startup times and printf times were not significant in any of the cases(5%). Further curious because of the python challenge, I took a different (slower) primes algorithm(trying to be fair to python since it doesn't have gotos), That someone had already written C and python versions of, and ported it to parrotdrum roll please(only 10,000 primes due to slower algorithm): c - primes2.c real0m1.147s user0m1.050s sys 0m0.000s parrot primes2.pasm(default) real0m4.868s user0m4.700s sys 0m0.020s parrot primes2.pasm(-P) real0m3.058s user0m2.920s sys 0m0.000s parrot primes2.pasm(-J) real0m1.825s user0m1.700s sys 0m0.000s python primes2.py real0m25.922s user0m24.900s sys 0m0.050s So at least on simple looping benchmarks like this, parrot is much closer to the performance of C than it is to perl or python...I lke it (doing my best Tony the Tiger impersonation here). Congrats guys...it's pretty impressive. Testing platform is linux debian (sid) on an Athlon 2100, gcc 3.2.3, perl 5.8.0, python 2.2.2, and parrot CVS head as of today. -Tupshin Code available if anybody cares.
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
Leopold Toetsch wrote:
Did you have an optimized parrot compile?
( make progclean ; perl Configure.pl ... --optimize ; make -s)
No I hadn't, but I just did, using those exact commands(no additional
options to Configure.pl), and had no perceivable performance change
using any of the parrot variances(default, -P, -j). Is there a way to
verify that an optimized build was truly made? Did you expect to see
much of any difference? GCC issues(running 3.2.3)?
-Tupshin
Code available if anybody cares.
Yes please.
Alright...all versions are attached (sorry for spamming the list, but
others might be interested). Some of the code is ugly (done around 3:00
in the morning), and some are in languages I am less then fluent in
(last touched any flavor of assembly in 1985, and barely touched it
then), so be kind. I don't believe I'm being too unfair to any of the
languages, though feel free to tell me otherwise.
The python and c versions of prime2 come from a tutorial on optimizing
python by writing extensions in C
http://kortis.to/radix/python_ext/
Modified slighly to behave more analogously to the first test, and some
compilation bugs fixed.
TIA,
leo
WATF
(welcome after the fact)
-Tupshin
#include stdio.h
int main()
{
int I1 = 1;
int I2 = 10;
int I3;
int I4;
int I5;
printf(\nThe primes up to );
printf(%d, I2);
printf( are:\n);
REDO:
I3 = 2;
I4 = I1 / 2;
LOOP:
I5 = I1 % I3;
if (I5) {goto OK;}
goto NEXT;
OK:
I3++;
if (I3 = I4) {goto LOOP;}
printf (%d, I1);
printf (\n);
NEXT:
I1++;
if (I1 = I2) {goto REDO;}
}
primes.pl
Description: Perl program
# Some simple code to print out the primes up to 100
# Leon Brocard [EMAIL PROTECTED]
# I1 holds the number we're currently checking for primality
set I1, 1
# I2 holds the highest number we want to check for primality
set I2, 10
print The primes up to
print I2
printare:\n
# I1 counts up to I2
REDO: # I3 counts from 2 up to I4 (I1/2)
set I3, 2
div I4, I1, 2
LOOP: # Check if I3 is a factor of I1
mod I5, I1, I3
if I5, OK
# We've found a factor, so it can't be a prime and
# we can skip right out of this loop and to the next
# number
branch NEXT
OK: inc I3
le I3, I4, LOOP
# We haven't found a factor so it must be a prime
print I1
print \n
NEXT: # Move on to the next number
inc I1
le I1, I2, REDO
end
int main(){
int i=0, l=0, max=1;
while (1) {
if (isprime1(i)==1) {
printf(%i\n,i);
l++;
}
i++;
if (i==max){
break;
}
}
printf(primes calculated to %i\n,max);
}
int isprime1(int input)
{
int n;
if (input 1) {
return 0;
}
n = input - 1;
while (n 1){
if (input%n == 0) return 0;
n--;
}
return 1;
}
import os,sys
def isprime1(input):
if input 1:
return 0
n = input-1
while n 1:
if input%n == 0:
return 0
n = n - 1
return 1
def main():
i = 0
l = 0
max = 1
while 1:
if isprime1(i):
l = l +1
print i
i = i + 1
if i == max:
break
print primes calculated to ,max
if __name__ == __main__:
main()
set I1, 0
set I2, 0
set I3, 0
set I4, 1
BEGINLOOP:
branch PRIMECHECK
ISPRIME:
print I1
print \n
inc I2
NOTPRIME:
inc I1
eq I1,I4, DONE
PRIMECHECK:
set I5, I1
lt I5,1,NOTPRIME
set I6,I5
dec I6
NLOOP:
mod I7, I5, I6
eq I7, 0, NOTPRIME
dec I6
gt I6, 1, NLOOP
branch ISPRIME
DONE:
printprimes calculated to
print I1
print \n
end
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
[EMAIL PROTECTED] wrote: On Tue, Feb 18, 2003 at 04:03:40AM -0800, Tupshin Harper wrote: FYI...all three used the identical algorithm taken from the primes.pasm example complete with labels and gotos(makes for very disconcerting perl code). Startup times and printf times were not significant in any of the cases(5%). This is, unfortunately, a rigged demo. Its code optimized for Parrot and then mechanically translated into Perl and C. The algorithm would have been the same if it, for example, used a loop in Perl instead of gotos. I don't know that its all that interesting to show that goto is slow in Perl. OTOH, goto should be fast in C, no? I'm going to tinker with those benchmarks again. Agreed...the second example is probably less rigged, since the mechanical translation was to pasm(and don't know enough to optimize the pasm ;-) -Tupshin
Re: parrot performance vs.(trivial test) the good, the bad, and the ugly
On my system, the perl takes 2.24 second and the python takes 3.76 seconds. You are correct that the 2 versions I send out earlier are *very* different. I started from two places, the primes.pasm which I converted to C and perl versions and a pre-existing primes.py and primes.c that I converted to primes.pasm. My interest was in comparing parrot to other things, so I didn't pay any attention in trying to get comparable perl and parrot ones. Thanks for taking an interest. -Tupshin Jim Meyer wrote: Hello! Benchmarks are idiosyncratic and devious and I thank you for starting a comparison whose results interest me greatly. =] On Tue, 2003-02-18 at 10:03, Tupshin Harper wrote: [...]and some are in languages I am less then fluent in (last touched any flavor of assembly in 1985, and barely touched it then), so be kind. I don't believe I'm being too unfair to any of the languages, though feel free to tell me otherwise. I looked at the .pl and .py versions and was struck by the very dissimilar approaches taken in the two. I translated the GOTO-style primes.pl to a loop syntax in both Perl and Python which I believe accurately represents the logic of primes.pasm without resorting to actual GOTO statements[1]. I'd be very curious as to the runtime of these on the system you used for the earlier benchmarks. On my box, the retooled Python script takes only approximately 50% of the time used by the earlier Perl version; the retooled Perl version runs in roughly 30% the time of its Perl predecessor. Thanks again for taking this initiative! --j [1] Go To Statement Considered Harmful, Edsger W. Dijkstra, Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148; see http://www.acm.org/classics/oct95/
XML within parrot?
I've been a parrot lurker for quite some time, and I've recently wanted to start participating in some way. One idea that came to mind was to port a language I wrote a while back which is an XML-relational converter. Call it XTOR(XML to Relational for lack of imagination). Think of it as analogous to XSL, but for converting XML data to row/column data in completely arbitrary(and sometimes quite capricious) ways. The problem(s) is that the language itself is written in XML (as is XSL), and therefore anything that processes it has to have an XML engine available. I originally wrote a perl program to act as an interpreter for this language, but it would also obviously be possible to write a compiler to target some platform. Targeting parrot with either method would require access to an XML parser. Is there currently any way to get access to an XML parser from within parrot? -Tupshin
pxs help
So I'm gonna take a look at the native calling functionality of parrot to see about access to an XML parser. Taking a look at the pxs example (is this the right place to be looking?), and I'm having problems compiling PQt.C per it's own instructions. After getting the qt headers installed, the following has problems all across the map. My command: g++ -fPIC -I/usr/include/qt3 -I../../include -L$QTDIR -c PQt.C -lqt produces: In file included from ../../include/parrot/global_setup.h:18, from ../../include/parrot/parrot.h:198, from ../../include/parrot/pxs.h:14, from PQt.C:15: ../../include/parrot/interpreter.h:34: conflicting types for `typedef struct Parrot_Interp*Parrot_Interp' ../../include/parrot/interpreter.h:32: previous declaration as `struct Parrot_Interp' In file included from ../../include/parrot/interpreter.h:46, from ../../include/parrot/global_setup.h:18, from ../../include/parrot/parrot.h:198, from ../../include/parrot/pxs.h:14, from PQt.C:15: ../../include/parrot/warnings.h:27: conflicting types for `struct Parrot_Interp ' ../../include/parrot/interpreter.h:34: previous declaration as `typedef struct Parrot_Interp*Parrot_Interp' In file included from ../../include/parrot/parrot.h:201, from ../../include/parrot/pxs.h:14, from PQt.C:15: ../../include/parrot/datatypes.h:117: syntax error before `typename' In file included from PQt.C:15: ../../include/parrot/pxs.h:17: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:17: syntax error before `)' token ../../include/parrot/pxs.h:17: variable or field `PXS_reti' declared void ../../include/parrot/pxs.h:17: initializer list being treated as compound expression ../../include/parrot/pxs.h:18: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:18: syntax error before `)' token ../../include/parrot/pxs.h:18: variable or field `PXS_retn' declared void ../../include/parrot/pxs.h:18: initializer list being treated as compound expression ../../include/parrot/pxs.h:19: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:19: syntax error before `*' token ../../include/parrot/pxs.h:20: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:20: syntax error before `*' token ../../include/parrot/pxs.h:21: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:22: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:23: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:24: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:25: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:26: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:26: syntax error before `*' token ../../include/parrot/pxs.h:27: `parrot_interp_t' was not declared in this scope ../../include/parrot/pxs.h:27: syntax error before `char' PQt.C:25: `parrot_interp_t' was not declared in this scope PQt.C:25: syntax error before `,' token PQt.C: In function `void QApplication_new(...)': PQt.C:32: `interp' undeclared (first use this function) PQt.C:32: (Each undeclared identifier is reported only once for each function it appears in.) PQt.C: At global scope: PQt.C:36: syntax error before `,' token PQt.C: In function `void QApplication_exec(...)': PQt.C:37: `object' undeclared (first use this function) PQt.C: At global scope: PQt.C:40: syntax error before `,' token PQt.C: In function `void QApplication_setMainWidget(...)': PQt.C:41: `PXS_shiftp' cannot be used as a function PQt.C: At global scope: PQt.C:50: syntax error before `,' token PQt.C: In function `void QLabel_new(...)': PQt.C:51: `PXS_shiftcs' cannot be used as a function PQt.C: At global scope: PQt.C:57: syntax error before `,' token PQt.C:61: syntax error before `,' token PQt.C: In function `void QLabel_resize(...)': PQt.C:62: `PXS_shifti' cannot be used as a function PQt.C:63: `PXS_shifti' cannot be used as a function Could somebody give me any 1 or more of the following? ;-) 1) compilation tips for PQt.C 2) alternate pxs examples 3) docs for pxs 4) a swift kick in the pants saying: don't do A, do B -Tupshin
Re: pretty pictures
The ability to download autodia off of the primary site and the mirror is unfortunately broken. -Tupshin James Michael DuPont wrote: --- Mitchell N Charity [EMAIL PROTECTED] wrote: Doxygen unfortunately doesn't handle perl code, and even has problems with parrot's C. You might be interested in autodia, it handles perl. http://droogs.org/autodia/ (IMHO, the world needs a wrapper hack which allows you to run all these variously broken code analysis tools, and then gloms their outputs together into something browsable. Ah well. Todo list.) The goal of the introspector is to publish a RDF/XML ontology of the various systems and thier dumps. Then you can merge the ontologies on a logical level and transform them between each other. Well what exactly do you need? I will be looking in running the introspector over the parrot code. That will produce a rdf file of the entire parrot source code. I would like to also figure out how to extract the high-level infomration from perl. The next step for the introspector was B::ToXML and to get that running. But for Perl6, i wonder what that best way to get at the data? The assembler does not contain any high level information. GraphVis (www.graphviz.org) did the actual drawing. Yes, that is on major goal of the introspector project to replace this funky non-free graphvis with the VCG. I hope to port VCG to GTK this year, and integrate it with DIA for a nice graph editor. http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html Hmm. Maybe a picture of the complete include graph would be useful introductory material... the graphs you doxygen produces are great. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
