Re: Missing MMD default functions?
Dan Sugalski [EMAIL PROTECTED] wrote: I sync'd up with subversion this afternoon, and I'm finding that a *lot* of things that used to work for me are now breaking really badly. Specifically where there used to be sane fallbacks for pretty much all of the MMD functions now we've got nothing and I'm having to install a lot of crud I never used to have to. You are not very verbose about what actually fails, but I presume that you are speaking of ParrotObjects, which happened to call the mmd fallback functions in absence of a Cmmdvtregister overload. I assume that we didn't throw away all the default functions on purpose, since that'd be more than a little foolish. Well, if this is sane or foolish is probably a matter of taste or usage. I think that arbitrary objects shouldn't have floating point mathematical semantics. If your class Cisa float then you can just sublass a CFloat. If it Cisa integer then subclass CInteger. .pragma n_operators 1 .sub _main @MAIN $P0 = subclass Float, Foo $P1 = new Foo # [2] $P2 = new Foo $P1 = 2 $P2 = 40 $P0 = $P1 + $P2 print $P0 print \n typeof $S0, $P0 print $S0 print \n .end ... Is this stuff being worked on, or shall I take some time to throw the default code back into the MMD subsystem? All the fallback functions where just duplicating code from (mostly) float.pmc or integer.pmc. All these functions are available in these PMCs anyway, a lot of common code is in scalar.pmc. The only thing that still needs work is to always return a PMC of a type belonging to the type system of the HLL in use. Most of this is done [3], only some explicit enum_class_* in classes/*.pmc needs replacing by the equivalent of: dest = pmc_new(INTERP, Parrot_get_ctx_HLL_type(INTERP, enum_class_Float)); (this is from Complex.absolute - the abs() of a CPyComplex Cisa CPyFloat albeit the Cabsolute function is only implemented in Parrot core and not in Python PMCs) If the class needs some custom behavior, drop an appropriate function into it's namespace and it works: .namespace [Foo] .sub __add .param pmc l .param pmc r print in add\n $P0 = new Foo $P0 = 77 .return($P0) .end leo [1] $ cat mmd1.imc .sub _main @MAIN $P0 = newclass Foo $I0 = find_type Foo $P0 = new $I0 $P1 = new $I0 $P2 = new $I0 $P0 = $P1 + $P2 .end $ ../parrot-0.1.2/parrot mmd1.imc Can't find method '__get_number' for object 'Foo' (The backtrace reveals that Cmmd_fallback_add_pmc was called) [2] With a C.HLL declaration numeric types are working too. [3] src/hll.c
[perl #36098] Solaris - Large number of tests fail under jit
# New Ticket Created by Peter Sinnott # Please include the string: [perl #36098] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36098 --- osname= solaris osvers= 2.9 arch= sun4-solaris cc= gcc 3.3.1 --- Flags: category=core severity=high ack=no --- A large number of tests are failing under jit on solaris but pass using other cores Failed Test Stat Wstat Total Fail Failed List of Failed --- imcc/t/reg/spill.t 5 1280 95 55.56% 3 6-9 imcc/t/syn/bsr.t1 256131 7.69% 8 imcc/t/syn/file.t 4 1024124 33.33% 5-8 imcc/t/syn/objects.t3 768113 27.27% 2-3 9 imcc/t/syn/pcc.t 27 691247 27 57.45% 1-2 4-7 9 11-27 32-33 40 t/dynclass/pyclass.t3 768 63 50.00% 2 5-6 t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4 t/op/debuginfo.t1 256 81 12.50% 5 t/op/gc.t 4 1024194 21.05% 10-11 13-14 t/op/interp.t 4 1024114 36.36% 7-10 t/op/string_cclass.t6 1536 66 100.00% 1-6 t/pmc/coroutine.t 8 2048138 61.54% 1 4 6-10 12 t/pmc/delegate.t4 1024 94 44.44% 2 6 8-9 t/pmc/eval.t 11 281611 11 100.00% 1-11 t/pmc/exception.t 1 256301 3.33% 21 t/pmc/hash.t1 256361 2.78% 9 t/pmc/mmd.t16 409626 16 61.54% 1-4 7-8 10-17 24-25 t/pmc/namespace.t 2 512142 14.29% 13-14 t/pmc/nci.t 8 2048568 14.29% 38-45 t/pmc/object-meths.t7 1792287 25.00% 11 13-15 23-24 28 t/pmc/objects.t10 256062 10 16.13% 29-31 48-52 55-56 t/pmc/pmc.t 1 256231 4.35% 5 t/pmc/sub.t14 358451 14 27.45% 3-4 7 17-20 29-34 48 t/pmc/sys.t 1 256 11 100.00% 1 5 tests and 68 subtests skipped. Failed 24/126 test scripts, 80.95% okay. 146/2231 subtests failed, 93.46% okay. The failures seem to have a few distinct types 1. Null PMC access t/op/debuginfo.ok 4/8 t/op/debuginfo.NOK 5# Failed test (t/op/debuginfo.t at line 116) # 'ok 1 # ok 2 # ok 3 # Null PMC access in find_method() # current instr.: 'Test1 :: foo' pc -1 ((unknown file):-1) # called from Sub 'Test1 :: main' pc -1 ((unknown file):-1) # ' # doesn't match '/^ok 1 # ok 2 # ok 3 # Method 'nosuchmethod' not found # current instr.: 'Test1 :: foo' pc (\d+|-1) \(.*?:(\d+|-1)\) # called from Sub 'Test1 :: main' pc (\d+|-1) \(.*?:(\d+|-1)\)$/ # ' # './parrot -j --gc-debug /var/tmp/tinder/parrot/t/op/debuginfo_5.pir' failed with exit code 43 t/op/debuginfo.ok 8/8# Looks like you failed 1 test of 8. t/op/debuginfo.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 5 Failed 1/8 tests, 87.50% okay (less 3 skipped tests: 4 okay, 50.00%) 2. Functions not found t/pmc/exceptionok 20/30 t/pmc/exceptionNOK 21# Failed test (t/pmc/exception.t at line 460) # got: 'MMD function __add not foundfor types (1, -100) # current instr.: 'b :: b11' pc -1 ((unknown file):-1) # called from Sub 'main' pc -1 ((unknown file):-1) # ' # expected: 'ok 1 # 99 # ' # './parrot -j --gc-debug /var/tmp/tinder/parrot/t/pmc/exception_21.pir' failed with exit code 1 t/pmc/exceptionok 30/30# Looks like you failed 1 test of 30. t/pmc/exceptiondubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 21 Failed 1/30 tests, 96.67% okay 3. Seg faults 4. No obvious error message but output does not match expected output --- Summary of my parrot 0.2.0 (r0) configuration: configdate='Thu Jun 2 00:34:28 2005' Platform: osname=solaris, archname=sun4-solaris jitcapable=1, jitarchname=sun4-solaris, jitosname=SOLARIS, jitcpuarch=sun4 execcapable=0 perl=perl Compiler: cc='gcc', ccflags=' -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib ', cc_ldflags='', libs='-lsocket -lnsl -ldl -lm -lpthread -lrt' Dynamic Linking: share_ext='.so', ld_share_flags=' -G -z ignore -z lazyload -z combreloc -L/usr/local/lib', load_ext='.so', ld_load_flags=' -G -z ignore -z lazyload -z combreloc -L/usr/local/lib' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=4321, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATHSHELL
[perl #36110] [PATCH] PLATFORMS with MinGw32
# New Ticket Created by Franois PERRAD # Please include the string: [perl #36110] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36110 This patch updates PLATFORMS for MinGW. $ parrot -V This is parrot version 0.2.0-devel (r8259) built for i386-MSWin32. $ make fulltest Failed TestStat Wstat Total Fail Failed List of Failed --- t/dynclass/foo.t 9 2304 99 100.00% 1-9 t/dynclass/gdbmhash.t13 332813 13 100.00% 1-13 t/dynclass/pybuiltin.t6 1536 66 100.00% 1-6 t/dynclass/pyclass.t 6 1536 66 100.00% 1-6 t/dynclass/pycomplex.t3 768 33 100.00% 1-3 t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4 t/dynclass/pyint.t 26 665626 26 100.00% 1-26 t/op/spawnw.t 5 1280 65 83.33% 2-6 t/pmc/threads.t 7 1792117 63.64% 2-5 7-9 t/pmc/timer.t 2 512 82 25.00% 3 5 2 tests and 63 subtests skipped. Failed 10/136 test scripts, 92.65% okay. 81/2373 subtests failed, 96.59% okay. Francois Perrad. PLATFORMS.patch Description: Binary data
Re: HP-UX build notes
H.Merijn Brand wrote: On Wed, 01 Jun 2005 12:45:12 +0100, Nick Glencross [EMAIL PROTECTED] wrote: Here are some notes for those that are interested in parrot being built on other platforms. The system in question is a PA-RISC HP-UX 11.11 system (hppa2.0w-hp-hpux11.11). The system only has the bundled C compiler and linker, so I've compiled gcc 3.3.6 for it. gcc cannot create debug information without gas, which is unfortunately not supported on this platform. It is. Go fetch from my site! Having downloaded the version of gas from H.Merijn's site, I've now recompiled gcc against it and have debugging support on HP-UX (I'm still using the system ld for the timebeing). Strangely all the segfaults have now gone away (perhaps the assembler aligns data differently?), although the 'l != left' assertions are still there. There are quite a lot, and some are listed here. This lists the failed test, and the line number that the assertion occurs in mmd.c. TEST: mmd assertion line number getopt_long_1.pir: 727 jit_54.pasm: 676 coroutine_6.pir: 625 coroutine_12.pir: 625 float_[16,17,18,19,20,21,22,23].pasm: 625 and 676 integer_1.pir: 625 perlint_[12,15,16,17,18,19,20,21,23,35,36,37,38,39,40,41,42,35,36,37,...]: 625 676 ... I shall obviously be investigating these in more detail. Briefly, getopt_long_1.pir seems to assert on the following instruction. 858 i_concatenate P15, S15 - P15=String=PMC(0x4020a740 Str:), S15=.sub _pge_rule\n and jit_54.pasm asserts on this instruction: 9 i_divide P0, N0 - P0=Integer=PMC(0x4020d3c8: 123), N0=4000.00 If someone can give me any insight into what this assertion is checking, I'd be grateful. It seems to boil down to whether the left PMC is a deleg pmc (else left is assigned to l, and the assertion fires). I've also attached a patch to rename the CPU arch which causes warnings from config.h. If someone can apply this (or a variant if you don't like the '|'s) I'd be grateful. Failing that, I'll log a call this evening when I have access to an SMTP server. Cheers, Nick Index: config/auto/jit.pl === --- config/auto/jit.pl (revision 8253) +++ config/auto/jit.pl (working copy) @@ -34,6 +34,9 @@ ($osname, $cpuarch) = ($cpuarch, ); } + # This was added to convert 9000/800 to 9000_800 on HP-UX + $cpuarch =~ s|/|_|g; + # On OS X if you are using the Perl that shipped with the system # the above split fails because archname is darwin-thread-multi-2level.
Re: [perl #36110] [PATCH] PLATFORMS with MinGw32
François PERRAD [EMAIL PROTECTED] wrote: This patch updates PLATFORMS for MinGW. Thanks, applied - r8262 leo
Re: [PATCH] Fix 3 of the spawnw.t failures.
Nigel Sandever [EMAIL PROTECTED] wrote: Thanks, applied - r8263 Further thoughts on the questions in comments invited. Yeah. njs leo
MSWin32 Test Results of Parrot r8259
Nothing unexpected, I guess. Windows XP SP2 Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Activestate Python 2.4.1 Build 245 Activestate Perl 5.8.6 Build 811 ANTLR 2.7.5 GNU bc 1.06 GNU m4 1.4 ICU 3.2 GDBM 1.8.3 GMP 4.1.4 Failed TestStat Wstat Total Fail Failed List of Failed --- t\dynclass\foo.t 9 2304 99 100.00% 1-9 t\dynclass\gdbmhash.t13 332813 13 100.00% 1-13 t\dynclass\pybuiltin.t6 1536 66 100.00% 1-6 t\dynclass\pyclass.t 6 1536 66 100.00% 1-6 t\dynclass\pycomplex.t3 768 33 100.00% 1-3 t\dynclass\pyfunc.t 4 1024 44 100.00% 1-4 t\dynclass\pyint.t 26 665626 26 100.00% 1-26 t\op\spawnw.t 5 1280 65 83.33% 2-6 t\pmc\threads.t 7 1792117 63.64% 2-5 7-9 t\pmc\timer.t 2 512 82 25.00% 3 5 2 tests and 63 subtests skipped. Failed 10/136 test scripts, 92.65% okay. 81/2373 subtests failed, 96.59% okay. Ron
Re: HP-UX build notes
Nick Glencross wrote: Strangely all the segfaults have now gone away (perhaps the assembler aligns data differently?), although the 'l != left' assertions are still there. Looking at the code this is very likely caused by unaligned function pointers. To verify it please set: #define PARROT_HASH_ALIGNED_FUNCPTR 0 in include/parrot/has_header.h (after Configure.pl) - then make. Thanks, leo
Regarding Google's Summer of Code 2005
I m interseted in one of LLVM project Implement well-known optimizations in PIR compiler (SSA - register allocation) Can Any send me the details? -- Dheeraj Kumar H.No. 7 Room No. 249 IITB Bombay Mumbai-400076 Mobile No. 09819939038
Re: HP-UX build notes
Nick Glencross wrote: + # This was added to convert 9000/800 to 9000_800 on HP-UX + $cpuarch =~ s|/|_|g; Thanks, applied - r8264 leo
Building nci/dynclasses on HP-UX
Guys, I'm currently investigating the build process for nci and dynclasses on HP-UX. As you may have seen from my previous posts, I'm using gcc and the native bundled ld. Although the build process isn't using the right flags to compile nci and dynclasses, I've managed to compile things manually. Certain files need special PIC treatment (at least on HP-UX) so that they can be included in shared libraries: src/extend.o src/nci_test.o dynclasses/*.o more? Hence, these files need: GNU cc: -fpic HP-UX cc: +z and then for linking the library: GNU ld: -shared HP ld: -b Also HP ld does not like -g, and should not be used. In fact, I'm not aware that any flavours of ld should be using -g (it is ignored in GNU ld). Most of the nci tests pass, except for tests 8 and 52 which both hang (on the dlvar call with nci_dlvar_int). I'm still working on getting dynclasses working. Although compiled, the libraries are failing to mmap in the backend of dlopen (probably unresolved symbols, pic or something else). Regards, Nick
Re: Missing MMD default functions?
At 9:23 AM +0200 6/3/05, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: I sync'd up with subversion this afternoon, and I'm finding that a *lot* of things that used to work for me are now breaking really badly. Specifically where there used to be sane fallbacks for pretty much all of the MMD functions now we've got nothing and I'm having to install a lot of crud I never used to have to. You are not very verbose about what actually fails, but I presume that you are speaking of ParrotObjects, which happened to call the mmd fallback functions in absence of a Cmmdvtregister overload. I assume that we didn't throw away all the default functions on purpose, since that'd be more than a little foolish. Well, if this is sane or foolish is probably a matter of taste or usage. I think that arbitrary objects shouldn't have floating point mathematical semantics. Then they don't implement the floating point accessor vtable functions. All the fallback functions where just duplicating code from (mostly) float.pmc or integer.pmc. Right, so to reduce code duplication you remove stuff that's working so people have to go reimplement the code. That makes *perfect* sense. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Regarding Google's Summer of Code 2005
On Fri, Jun 03, 2005 at 05:30:51PM +0530, Dheeraj Kumar Arora wrote: I m interseted in one of LLVM project Implement well-known optimizations in PIR compiler (SSA - register allocation) Can Any send me the details? I'm not an expert with with PIR or SSA, but I'm aware of LLVM's JIT subsystem, which can manage register allocation from an SSA representation. It was previously known as Jello -- see http://llvm.cs.uiuc.edu/ProjectsWithLLVM/#jello for a 2002 paper that discusses this topic. Also maybe of interest is ANF (A-normal form), a functional-flavoured representation closely related (and indeed translatable from) SSA. Sabry, Felleisen et al gave a useful overview in The Essence of Compiling with Continuations (Retrospective), available at http://www.ccs.neu.edu/scheme/pubs/. A translator from SSA to ANF is given in http://www.jantar.org/papers/ssa-lambda/. I'd be very happy to work with a ANF/SSA-PIR/PASM toolkit and provide feedback from the side of a compiler writer. Thanks, /Autrijus/ pgpA5TXqe5p3O.pgp Description: PGP signature
Re: Regarding Google's Summer of Code 2005
Dheeraj Kumar Arora wrote: I m interseted in one of LLVM project Implement well-known optimizations in PIR compiler (SSA - register allocation) [ I have answerd this ] Parrot is a register based virtual machine with 32*4 registers. There are a lot of studies WRT optimizations and register allocations for compilers and hardware CPUs but probably all these things can be applied to Parrot too. See also imcc/cfg.c and imcc/reg_alloc.c for existing code. I'm not a computer scientist nor am I able to follow most of the papers regarding various optimization techniques or the needed infrastructure to implement it Anyway, there are folks on our mailing list like Curtis Rawls, who could probably better summarize what's needed and what should be done. Can Any send me the details? Yes please, folks. leo
Re: HP-UX build notes
Leopold Toetsch wrote: Nick Glencross wrote: Strangely all the segfaults have now gone away (perhaps the assembler aligns data differently?), although the 'l != left' assertions are still there. Looking at the code this is very likely caused by unaligned function pointers. To verify it please set: #define PARROT_HASH_ALIGNED_FUNCPTR 0 Shame, that doesn't seem to have made any difference, even though I had my fingers crossed. :-( I'll revisit this later this afternoon; just looking at dynclasses at the moment. Nick
Re: Missing MMD default functions?
Dan Sugalski wrote: Right, so to reduce code duplication you remove stuff that's working so people have to go reimplement the code. That makes *perfect* sense. I've announced and summarized all these changes, e.g. http://xrl.us/gayp on Apr. 8th And, what is wrong about: cl = subclass Float, MyFloat leo
Re: Missing MMD default functions?
At 2:50 PM +0200 6/3/05, Leopold Toetsch wrote: Dan Sugalski wrote: Right, so to reduce code duplication you remove stuff that's working so people have to go reimplement the code. That makes *perfect* sense. I've announced and summarized all these changes, e.g. http://xrl.us/gayp on Apr. 8th It's been a long time since I sync'd up. I *assumed* that you wouldn't break stuff. I don't know why. And, what is wrong about: cl = subclass Float, MyFloat Why should I have to sublcass anything to get basic functionality? Don't bother answering that one. Having to deal with this sort of crap is the single biggest reason I bailed. I'm happy to not have to do so, and I'm going to keep on being bailed. Do whatever you want, you're someone else's problem now. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: HP-UX build notes
Nick Glencross wrote: Leopold Toetsch wrote: Nick Glencross wrote: Strangely all the segfaults have now gone away (perhaps the assembler aligns data differently?), although the 'l != left' assertions are still there. Looking at the code this is very likely caused by unaligned function pointers. To verify it please set: #define PARROT_HASH_ALIGNED_FUNCPTR 0 Actually, where it uses this in mmd.c is actually an #ifndef which means that really the above line should be commented out. Brilliant! That seems to have fixed it! (Thanks Leo!) I've made some progress on the dynclasses too. Where the libraries are copied into runtime/parrot/dynext they lose their execute flag, which is really important to HP-UX. I'll provide a patch this evening which will probably replace copy with syscopy in build_dynclasses.pl. Still some hangs in dynamic loading, but real close now... Regards, Nick
Re: Building nci/dynclasses on HP-UX
On Fri, 03 Jun 2005 13:11:57 +0100, Nick Glencross [EMAIL PROTECTED] wrote: Guys, I'm currently investigating the build process for nci and dynclasses on HP-UX. As you may have seen from my previous posts, I'm using gcc and the native bundled ld. Although the build process isn't using the right flags to compile nci and dynclasses, I've managed to compile things manually. Certain files need special PIC treatment (at least on HP-UX) so that they can be included in shared libraries: src/extend.o src/nci_test.o dynclasses/*.o more? Hence, these files need: GNU cc: -fpic use -fPIC for more portability HP-UX cc: +z use +Z -z for more portability and higher run-time safety and never forget -Ae, but I can't see from this post if you already use it further, if you use -O2 or up, add +Onolimit and then for linking the library: GNU ld: -shared HP ld: -b Also HP ld does not like -g, and should not be used. In fact, I'm not aware that any flavours of ld should be using -g (it is ignored in GNU ld). Most of the nci tests pass, except for tests 8 and 52 which both hang (on the dlvar call with nci_dlvar_int). I'm still working on getting dynclasses working. Although compiled, the libraries are failing to mmap in the backend of dlopen (probably unresolved symbols, pic or something else). -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11, AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: Building nci/dynclasses on HP-UX
H.Merijn Brand wrote: On Fri, 03 Jun 2005 13:11:57 +0100, Nick Glencross [EMAIL PROTECTED] wrote: Guys, I'm currently investigating the build process for nci and dynclasses on HP-UX. As you may have seen from my previous posts, I'm using gcc and the native bundled ld. use +Z -z for more portability and higher run-time safety and never forget -Ae, but I can't see from this post if you already use it Good points about the flags. I only have the 'bundled' C compiler and am stuck with gcc, so I've not actually been able to use the HP cc. You're right, -Aa or c89 command-line, a very good point. I've been trying to understand the rules that HP-UX's dlopen/dlsym play by. I've still a few more experiments to try, but dlsym has only worked for me if the the executable is also created PIC and the dynamic library is linked against libparrot.a, resulting in huge dynclasses, but dlsym returns NULL otherwise (mind you, it's worked pretty well for nci_test.sl) I fear that there may be some pointer alignment problems in hash because I'm getting hangs which seem to be linked to finding strings in hash tables. (That's pure conjecture) Nick
Re: Building nci/dynclasses on HP-UX
On Fri, 03 Jun 2005 16:20:53 +0100, Nick Glencross [EMAIL PROTECTED] wrote: H.Merijn Brand wrote: On Fri, 03 Jun 2005 13:11:57 +0100, Nick Glencross [EMAIL PROTECTED] wrote: Guys, I'm currently investigating the build process for nci and dynclasses on HP-UX. As you may have seen from my previous posts, I'm using gcc and the native bundled ld. use +Z -z for more portability and higher run-time safety and never forget -Ae, but I can't see from this post if you already use it Good points about the flags. I only have the 'bundled' C compiler and am Get yourself a testdrive account on http://www.testdrive.hp.com/ Current available systems: http://www.testdrive.hp.com/current.shtml All systems have native ANSI-C compilers installed If you are serious in using that for HP-UX or OpenVMS, please contact me off-list, since we have a special perl5 group there with just a little bit more rights stuck with gcc, so I've not actually been able to use the HP cc. You're right, -Aa or c89 command-line, a very good point. I've been trying to understand the rules that HP-UX's dlopen/dlsym play by. I've still a few more experiments to try, but dlsym has only worked for me if the the executable is also created PIC and the dynamic library is linked against libparrot.a, resulting in huge dynclasses, but dlsym returns NULL otherwise (mind you, it's worked pretty well for nci_test.sl) I fear that there may be some pointer alignment problems in hash because I'm getting hangs which seem to be linked to finding strings in hash tables. (That's pure conjecture) -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11, AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32
Mr. Gay, let me know if you wait for a special request to uncomment the line /*#include parrot/thr_windows.h*/ in config/gen/platform/win32/threads.h whatever was broken, has now been fixed. patch applied, and ticket closed. ~jerry
Re: Building nci/dynclasses on HP-UX
Nick Glencross wrote: I fear that there may be some pointer alignment problems in hash because I'm getting hangs which seem to be linked to finding strings in hash tables. (That's pure conjecture) I'm not aware of any problems with alignment in hash.c. *But* we will have troubles on that platform with doubles. Parrot PMCs are allocate off a big piece of mem. A PMC currently happens to be 24 bytes (on 32-bit) but only with the debug-ish version field compiled in. With an --optimze compiled parrot every second PMC would have unaligned doubles. I'm not quite sure if there are other places in Parrot, where a double could be only aligned at 4 bytes. Nick leo
Re: Missing MMD default functions?
Chip Salzenberg wrote: On Fri, Jun 03, 2005 at 02:50:38PM +0200, Leopold Toetsch wrote: I've announced and summarized all these changes, e.g. http://xrl.us/gayp on Apr. 8th I didn't realize the implications when that was posted. I think the native fallbacks are important. ... and probably dangerous. Given two array-ish instances of a class that implements __get_integer (get array size), Parrot would happily execute: $P0 = a b# or other bitwise operations By just depending on the fact that a missing __get_integer or __get_number would inhibit the execution of the MMD fallback seems not to be the best idea to me. cl = subclass Float, MyFloat In particular, I don't like the idea that an empty subclass provides functionality that ought to have been available already. ++verbose please. If I want a float-ish class with some customization it seems to be a logical idea to use a base class (Float) that provides already all defaults and then override what's different. The same is true for an Integer based class (which was in fallbacks, when it comes to bitwise operations). I still don't see the point that an arbitrary Foo class shall have MMD functions of a Float/Integer mix. leo
Re: Regarding Google's Summer of Code 2005
On 6/3/05, Leopold Toetsch [EMAIL PROTECTED] wrote: Dheeraj Kumar Arora wrote: I m interseted in one of LLVM project Implement well-known optimizations in PIR compiler (SSA - register allocation) [ I have answerd this ] Parrot is a register based virtual machine with 32*4 registers. There are a lot of studies WRT optimizations and register allocations for compilers and hardware CPUs but probably all these things can be applied to Parrot too. See also imcc/cfg.c and imcc/reg_alloc.c for existing code. I'm not a computer scientist nor am I able to follow most of the papers regarding various optimization techniques or the needed infrastructure to implement it Anyway, there are folks on our mailing list like Curtis Rawls, who could probably better summarize what's needed and what should be done. Can Any send me the details? Yes please, folks. leo Wow, thanks for the link to the Summer of Code, that looks like fun! (I know I'll be thinking about my proposal all day at work : ). I don't have my TODO list with me, I will try to post it later today. I have been working and thinking about improvements to the Parrot/IMCC optimizer for a while now. Implementing SSA is definitely at the top of my list, because it simplifies a lot of optimizations and makes some others possible. The biggest challenge is to graft such a big change onto a working system, with small changes at a time. The reference to LLVM is interesting, since it has similar goals to Parrot, but is research-oriented. I bet there are some good techniques that could be learned (and borrowed : ) from LLVM. -Curtis Rawls
Re: Regarding Google's Summer of Code 2005
All~ On 6/3/05, Curtis Rawls [EMAIL PROTECTED] wrote: On 6/3/05, Leopold Toetsch [EMAIL PROTECTED] wrote: Dheeraj Kumar Arora wrote: I m interseted in one of LLVM project Implement well-known optimizations in PIR compiler (SSA - register allocation) [ I have answerd this ] Parrot is a register based virtual machine with 32*4 registers. There are a lot of studies WRT optimizations and register allocations for compilers and hardware CPUs but probably all these things can be applied to Parrot too. See also imcc/cfg.c and imcc/reg_alloc.c for existing code. I'm not a computer scientist nor am I able to follow most of the papers regarding various optimization techniques or the needed infrastructure to implement it Anyway, there are folks on our mailing list like Curtis Rawls, who could probably better summarize what's needed and what should be done. Can Any send me the details? Yes please, folks. leo Wow, thanks for the link to the Summer of Code, that looks like fun! (I know I'll be thinking about my proposal all day at work : ). I don't have my TODO list with me, I will try to post it later today. I have been working and thinking about improvements to the Parrot/IMCC optimizer for a while now. Implementing SSA is definitely at the top of my list, because it simplifies a lot of optimizations and makes some others possible. The biggest challenge is to graft such a big change onto a working system, with small changes at a time. I know that Melvin Smith (aka Mr JoltCola) was planning on a full scale rewrite of imcc. His plan involved SSA. I don't know what came of that; I think that he ran out of tuits... But you might ask him where he is. I cc'ed him on this email... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Regarding Google's Summer of Code 2005
Hello, I worked on the parrot register allocation problem a few months ago. The problem I encountered was that of continuations based dependencies. There were architectural issues about continuations, and Leo proposed changes that would fix this, but Dan said it was too late for architectral changes. Basically the existence of continuations adds a lot of dependencies that don't want to go away, defeating most of the benefit that one can get from register alloction. I am referring to parrot's use of full continuations, which allow a snap shot of the current runtime stack. Any function can take a snapshot or restore the stack to a previous snap shot. This makes traditional register allocation problematic. As far as I can tell, the continuations depency problem was not solved, and in fact the existing register allocator is also in conflict with the continuations based dependencies. (Unless something has been done in the last few weeks.) The resolutions seems to be not to add tests that break things. Thus, continuations based tests are few, and unstable. Changing the way the registers allocate, even though they still don't violate the interference graph, will break some tests. There are several threads in the parrot mailing list that discuss the continuations problem. I hoped to be able to address parrot register allocator again, at some point, but it could be a while before I get to that. In the mean time, search the perl6-internals mailing list for continuations and register allocation. I'm sure you'll find it. The above not withstanding, I think there are still quite a few things that can be done to improve register allocation in parrot. If anyone is interested, I'm sure I could dig up my code. Bill Coffman On 6/3/05, Curtis Rawls [EMAIL PROTECTED] wrote: On 6/3/05, Leopold Toetsch [EMAIL PROTECTED] wrote: Dheeraj Kumar Arora wrote: I m interseted in one of LLVM project Implement well-known optimizations in PIR compiler (SSA - register allocation) [ I have answerd this ] Parrot is a register based virtual machine with 32*4 registers. There are a lot of studies WRT optimizations and register allocations for compilers and hardware CPUs but probably all these things can be applied to Parrot too. See also imcc/cfg.c and imcc/reg_alloc.c for existing code. I'm not a computer scientist nor am I able to follow most of the papers regarding various optimization techniques or the needed infrastructure to implement it Anyway, there are folks on our mailing list like Curtis Rawls, who could probably better summarize what's needed and what should be done. Can Any send me the details? Yes please, folks. leo Wow, thanks for the link to the Summer of Code, that looks like fun! (I know I'll be thinking about my proposal all day at work : ). I don't have my TODO list with me, I will try to post it later today. I have been working and thinking about improvements to the Parrot/IMCC optimizer for a while now. Implementing SSA is definitely at the top of my list, because it simplifies a lot of optimizations and makes some others possible. The biggest challenge is to graft such a big change onto a working system, with small changes at a time. The reference to LLVM is interesting, since it has similar goals to Parrot, but is research-oriented. I bet there are some good techniques that could be learned (and borrowed : ) from LLVM. -Curtis Rawls -- -Bill
Register Allocation and Continuations problem definition
All~ On 6/3/05, Bill Coffman [EMAIL PROTECTED] wrote: There are several threads in the parrot mailing list that discuss the continuations problem. I hoped to be able to address parrot register allocator again, at some point, but it could be a while before I get to that. In the mean time, search the perl6-internals mailing list for continuations and register allocation. I'm sure you'll find it. I would actually very much like to see this issue moved on. In the hopes of getting everything up to speed quickly I will try and summarize all of the discussions and suggestions that have been made. I am NOT trying to advocate any particular solution (yet), I just want to make sure that everyone is on the same page. I propose that we use this thread to ensure that we are not talking past each other. Discussions about specific solutions should and religion should have a seperate thread. PROBLEM: Continuations can be invoked repeatedly. Whenever a continuation is reinvoked, the registers must be in a defined state or the code will behave incorrectly. BASIC ANALYSIS The actual state of the registers does not matter as long as it is well defined. A) If the registers are defined to be garbage, then every continuation will start by returning them to the state it expects. B) If the registers are defined to be preserved, then every continuation merrily chugs along. Unfortunately these each have issues and as such much debate ensued. SUGGESTED SOLUTIONS 1) Context includes registers + continuations don't have to preserve specifc registers + register allocator can ignore continuations wrt spilling - copying overheard - value based registers (IN) return to old values - pointer based registers (SP) cannot have their pointers moved or require double indirection 2) Return Continuations include registers, non don't + register allocator can remain mostly ignorant + only non return continuations need to worry - promoting a return continuation will force copying as plan (1) 3) register are not restored + simple to explain - register allocator must add many extra interference edges - largely prevents reuse of register 4) variable sized register frames + never have unused registers + no need for a register allocator + could correspond directly to scratchpad - more complicated - no register reuse - large architectural change - more custom allocation (can't pool register sets) I believe the official spec calls for (2); however, I do not believe that it is currently implemented. Once again in this thread please try to remain objective and just summarize/correct. We can start a new thread to hash out the minutia of pro's/con's and new ideas, I just want everyone to be on the same page. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Missing MMD default functions?
Chip Salzenberg wrote:
I didn't realize the implications when that was posted. I think the
native fallbacks are important.
If we really want these fallbacks, it's rather easy to reestablish the
functionality. Given e.g.
classes/scalar.pmc:add (which Float intherits from)
we have
MMD_DEFAULT: {
yada ..
exactly the code that was in mmd_default: .. _add_pmc
}
This installs the MMD funtion add(Float, Any)
With a little change in parsing inside the PMC compiler we could define,
that:
MMD_DEFAULT, MMD_DEFAULT: {}
also defines the LHS of the operation, which we currently can't denote.
This would immediately give an implementation for
add(Any, Any)
without all the code duplication of the vanished mmd_fallback.c, without
any special cased code in the mmd lookup and without more entries in the
mmd_table that would prevent an efficient compression of it.
leo
Re: Missing MMD default functions?
At 2:21 PM -0400 6/3/05, Chip Salzenberg wrote: One could argue that by providing __get_integer, Foo class is automatically implying that it would serve where an Integer would. This is obviously what Dan was expecting. :-, Dan was expecting sane defaults, that is when I do addition with two PMCs that haven't otherwise said they behave specially that the floating point values of the two PMCs are retrieved and added together. Y'know, like people would generally expect from all the languages in the core set parrot cares about. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Building nci/dynclasses on HP-UX
On Fri, 3 Jun 2005, Leopold Toetsch wrote:
Nick Glencross wrote:
I fear that there may be some pointer alignment problems in hash because I'm
getting hangs which seem to be linked to finding strings in hash tables.
(That's pure conjecture)
I'm not aware of any problems with alignment in hash.c. *But* we will have
troubles on that platform with doubles. Parrot PMCs are allocate off a big
piece of mem. A PMC currently happens to be 24 bytes (on 32-bit) but only with
the debug-ish version field compiled in. With an --optimze compiled parrot
every second PMC would have unaligned doubles.
That's likely to cause a problem. We've been recently hunting down odd
alignment-related oddities on p5p. As a first approximation, doubles need
to be aligned at least on the boundaries given by Perl5's
Config{'alignbytes'}. However, when those doubles are part of a structure,
it apparently can get more confusing. I don't think we sorted out all the
possibilities, but Nick C. was the last one fiddling with it.
In the end, there may be no recourse other than using unions.
--
Andy Dougherty [EMAIL PROTECTED]
Re: Missing MMD default functions?
On Fri, Jun 03, 2005 at 02:50:38PM +0200, Leopold Toetsch wrote: I've announced and summarized all these changes, e.g. http://xrl.us/gayp on Apr. 8th I didn't realize the implications when that was posted. I think the native fallbacks are important. cl = subclass Float, MyFloat In particular, I don't like the idea that an empty subclass provides functionality that ought to have been available already. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Missing MMD default functions?
On Fri, Jun 03, 2005 at 07:18:56PM +0200, Leopold Toetsch wrote: Chip Salzenberg wrote: On Fri, Jun 03, 2005 at 02:50:38PM +0200, Leopold Toetsch wrote: I've announced and summarized all these changes, e.g. http://xrl.us/gayp on Apr. 8th I didn't realize the implications when that was posted. I think the I think the native fallbacks are important. ... and probably dangerous. Given two array-ish instances of a class that implements __get_integer (get array size) Well, aside from everything else, I think __get_integer shouldn't return array size. But anyway. cl = subclass Float, MyFloat In particular, I don't like the idea that an empty subclass provides functionality that ought to have been available already. ++verbose please. Perhaps I misunderstood, but I thought you were implying that MyFloat would automatically have some features that Float did not, just by virtue of the derivation. Sorry if I got that wrong. I still don't see the point that an arbitrary Foo class shall have MMD functions of a Float/Integer mix. Hm. That's an interesting point. One could argue that by providing __get_integer, Foo class is automatically implying that it would serve where an Integer would. This is obviously what Dan was expecting. :-, On the other hand, C++ has been down that road, and it has potholes. Just because an X-Y conversion exists does _not_ imply that an X will do every place you want a Y. Ask anyone who's accidentally passed a string as a char* without noticing. (C operator char * () is _not_ always your friend, and see also the Cexplicit keyword in ANSI C++.) The new status quo is looking better. -- Chip Salzenberg [EMAIL PROTECTED]
[perl #36119] [PATCH] Reapply execute permissions on dynclasses for HP-UX
# New Ticket Created by Nick Glencross
# Please include the string: [perl #36119]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36119
Folks,
this small patch fixes a current problem with loading dynclasses on
HP-UX. The libraries are copied from dynclasses/ to
runtime/parrot/dynext/ but in the process lose their execute flags which
is one of the prerequisites for dlopen to open it.
Regards,
Nick
p.s. I've been having a look at how the internals of Configure work. I
like it! It's too early to say, but in the same way that it determines
if the C compiler is gcc, it may be necessary to do something similar
for the linker. Too early to say though...
[It looks like most of the initial values for Configure are extracted
from Perl. I need to find out why it chooses strange values for my 'ld',
unless we are misinterpreting some of their meanings]
Index: config/gen/makefiles/dynclasses_pl.in
===
--- config/gen/makefiles/dynclasses_pl.in (revision 8266)
+++ config/gen/makefiles/dynclasses_pl.in (working copy)
@@ -140,6 +140,10 @@
foreach (@ungrouped_pmcs, keys %$group_files) {
copy($_$LOAD_EXT, $dest) or die Copy $_$LOAD_EXT failed ($?)\n;
+if ($^O ne 'MSWin32') {
+# Execute permissions on libraries is especially important on HP-UX
+chmod 0755, $dest/$_$LOAD_EXT;
+}
}
}
else {
Re: Register Allocation and Continuations problem definition
I hope that no one misunderstands when I say this. It is not meant to be a criticism, but rather it is my understanding of the problem, put very directly. I may be wrong, and in many ways, I hope am. There is a fundamental flaw in the Parrot architecture. In it's current form, continuations and register allocation cannot coexist. The solution is to do away with the register allocator, or to do away with continuations. This can be done, perhaps by saying that certain functions won't be subject to continuation snapshots or calls. Then register allocation can be done on those routines. Or compiling the whole program with a switch of on or off. When I say do away with the register allocator, I mean that nearly all registers will interfere, so essentially each variable gets a register. The extensible register stack is the best way to implement this strategy. If there are long sections of code with lots of temporary variables, then register allocation might be of some use. But most variables will interfere. Implementing this would be an interesting project. It would be quite different from a standard register allocator. It might even be worth writing a paper on the techniques involved. Turning off full continuations, is a another matter. I don't know what impact that would have on parrot. It would be relatively straightforward to write the allocator with this approach. There are other issues involved, regarding how registers change when called. What is preserved, and how. Matt touched on some of these issues. My main concearn in attempting to implement the register allocator was to find the minimal control flow graph (cfg) which helps to provide the variable interference graph. This is my understanding of the problem. Matt wants this thread to be a problem definition, so these thoughts seem appropriate for this thread. I hope no one is offended by my bluntness, but if this problem is to be solved, it must be understood. Bill Coffman ps: a couple important threads on this issue were http://groups-beta.google.com/group/perl.perl6.internals/browse_frm/thread/3a61fe5e97d17389/0603ff13ca52f0ff?_done=%2Fgroup%2Fperl.perl6.internals%3F_doneTitle=Back+to+topics_doneTitle=Backd#0603ff13ca52f0ff http://groups-beta.google.com/group/perl.perl6.internals/browse_frm/thread/214157bf29879710/4c15aa4a1f56c20a?_done=%2Fgroup%2Fperl.perl6.internals%3F_doneTitle=Back+to+topics_doneTitle=Backd#4c15aa4a1f56c20a On 6/3/05, Matt Fowles [EMAIL PROTECTED] wrote: All~ On 6/3/05, Bill Coffman [EMAIL PROTECTED] wrote: There are several threads in the parrot mailing list that discuss the continuations problem. I hoped to be able to address parrot register allocator again, at some point, but it could be a while before I get to that. In the mean time, search the perl6-internals mailing list for continuations and register allocation. I'm sure you'll find it. I would actually very much like to see this issue moved on. In the hopes of getting everything up to speed quickly I will try and summarize all of the discussions and suggestions that have been made. I am NOT trying to advocate any particular solution (yet), I just want to make sure that everyone is on the same page. I propose that we use this thread to ensure that we are not talking past each other. Discussions about specific solutions should and religion should have a seperate thread. PROBLEM: Continuations can be invoked repeatedly. Whenever a continuation is reinvoked, the registers must be in a defined state or the code will behave incorrectly. BASIC ANALYSIS The actual state of the registers does not matter as long as it is well defined. A) If the registers are defined to be garbage, then every continuation will start by returning them to the state it expects. B) If the registers are defined to be preserved, then every continuation merrily chugs along. Unfortunately these each have issues and as such much debate ensued. SUGGESTED SOLUTIONS 1) Context includes registers + continuations don't have to preserve specifc registers + register allocator can ignore continuations wrt spilling - copying overheard - value based registers (IN) return to old values - pointer based registers (SP) cannot have their pointers moved or require double indirection 2) Return Continuations include registers, non don't + register allocator can remain mostly ignorant + only non return continuations need to worry - promoting a return continuation will force copying as plan (1) 3) register are not restored + simple to explain - register allocator must add many extra interference edges - largely prevents reuse of register 4) variable sized register frames + never have unused registers + no need for a register allocator + could correspond directly to scratchpad - more complicated - no register reuse - large architectural change - more custom allocation (can't pool
Software Transactional Memory interaction with Garbage Collection
Hi all, While I must start this post out by saying that I've never implemented either STM or a garbage collector, during a discussion on #parrot (is that channel logged?), a similarity between the two processes occurred to me. Would this be an adequate expression of a generational Garbage Collector, in terms of STM; 1. start transaction for a memory region / incubator 2. gather a set of objects for update (giving you a consistent read copy of them). 3. commit memory transaction. The consistent read copy becomes the master, and the old incubator is reaped. There is the gaping gap in the above about how you know which objects to gather, of course. I'm just thinking it would be nice if the implementation for these two advanced technologies could share the same basic memory transaction API, to get two elusive birds with one stone. Sam.
