Re: Debian on parisc: Parrot 0.1.0 fails
On Wednesday 03 March 2004 19:50, Leopold Toetsch wrote: Daniel Grunblatt [EMAIL PROTECTED] wrote: When updating the old version I had at the TD machine to the current cvs version I realize that it fails right after start running, entering in an eternal loop, I could not find out exactly what is the problem but I think it's related to threads. It's Debian 3.0 on parisc using gcc 3.0.4 Any idea how to solve it? Provide more informatiion? $ cat myconfig Summary of my parrot 0.1.0 configuration: configdate='Wed Mar 3 12:56:25 2004' Platform: osname=HPUX, archname=PA-RISC1.1-thread-multi jitcapable=1, jitarchname=hppa-HPUX, jitosname=HPUX, jitcpuarch=hppa execcapable=0 perl=perl Compiler: cc='cc', ccflags='-DUSE_REENTRANT_API -D_POSIX_C_SOURCE=199506L -D_HPUX_SOURCE -L/lib/pa1.1 -DUINT32_MAX_BROKEN -mpa-risc-1-1 -fPIC -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -lnm -lmalloc -ldld -lm -lpthread -lndir -lcrypt -lsec' Dynamic Linking: so='.so', ld_shared='-b -L/usr/local/lib', ld_shared_flags='' 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 Does it run: print hi\n end No If not, does it use threads? What does ps/top/whatever have? Where does it hang? Run it with s?trace or such. Or attach a debugger... spe170 gdb parrot GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as hppa-linux... (gdb) r t.pasm Starting program: /house/grunblat/hp-ux/parrot/parrot t.pasm -- I press ^C after some time -- Program received signal SIGINT, Interrupt. 0x401e2d54 in ?? () (gdb) bt #0 0x401e2d54 in ?? () (gdb) So it's not so usefull. In top it has the R stat. I think it fails at: (gdb) b pmc.c:40 Breakpoint 2 at 0x5b5c8: file src/pmc.c, line 40. (gdb) r Starting program: /house/grunblat/hp-ux/parrot/parrot Breakpoint 1, pmc_init_null (interpreter=0x205030) at src/pmc.c:40 40 LOCK(init_null_mutex); (gdb) n Program received signal SIGINT, Interrupt. 0x401e2d54 in ?? () (gdb) bt #0 0x401e2d54 in ?? () (gdb) Could 3.0.4 be too old? Too many questions ... I'll try to install 3.3.3, but I'm not sure if it will compile given it's a TD machine. Daniel. leo
Debian on parisc: Parrot 0.1.0 fails
When updating the old version I had at the TD machine to the current cvs version I realize that it fails right after start running, entering in an eternal loop, I could not find out exactly what is the problem but I think it's related to threads. It's Debian 3.0 on parisc using gcc 3.0.4 Any idea how to solve it? Daniel.
Re: Howto write a JIT?
I can point you to the docs: docs/jit.pod There should be an explanation of how it works. Daniel. On Wednesday 08 October 2003 13:16, Clemens Eisserer wrote: Hi there! I´m currently interrested a bit in howto write a just in time compilier (jit). I searched a long time using google, and there are thousands of sites which explain what a JIT stands for, but not who it works. Because of parrot has its own jit written from scratch, maybe you can point me to some useful documentation. (Please dont point me to the source, its hard to understand source when you dont know how the concept works at all) Thanks a lot, Clemens ___ ___ Die Besten ihrer Klasse! WEB.DE FreeMail (1,7) und WEB.DE Club (1,9) - bei der Stiftung Warentest - ein Doppelsieg! http://f.web.de/?mc=021184
Re: [PATCH] Re: Timely Destruction: An efficient, complete solution
On Wednesday 10 September 2003 01:52, Luke Palmer wrote: Okay, after some major changes, here's the second revision of my patch. This one is fully functional. On my system, it creates over a 10x speedup for lazy DOD runs! Yay! (I'll post the benchmark program if someone wants; it's pretty long) What about puting it under examples/benchmarks/ ? Luke Daniel
Re: [PATCH] pdd7
On Friday 05 September 2003 12:34, Steve Fink wrote: Nicholas Clark wrote: On Tue, Sep 02, 2003 at 06:39:23AM +0300, Vladimir Lipskiy wrote: D. Function parametres in declarations. At the monent, pdd7 says that we mustn't omit them in declarations. I propose to omit them. The advantage is: We wouldn't run the risk to having a keyword of C++ as a parameter, we would have nothing to coordinate with parameters in definitions. The drawback is: We would lose a lot of helpful information that we could have obtained while exploring the headers. One solution is to put the parameters in /* comments */ in the declarations. Perhaps just don't bother specifying it at all? In my own coding, I follow the rule of leave it out if the type tells you everything you need to know about the purpose. But that's a subjective decision, and therefore dangerous to put in a coding style guide. I think that sometime the type is not enough to know everything you need, so having the name gets you closer (of course, if the name is representative enough). Daniel.
Re: cygwin results
On Thursday 21 August 2003 11:23, Tanton Gibbs wrote: I just wanted to let the list know that with the following configure options --cgoto=0 --jitcapable=0 --execcapable=0 Just to let you know --jitcapable=0 implies --execcapable=0. I had 100% pass rate on all cygwin tests. Cool. Tanton Daniel.
Re: [PATCH] Win32 compilation fix
On Thursday 14 August 2003 18:24, Mattia Barbon wrote: Puts #ifdefs as per the rest of i386/jit_emit.h. Regards Mattia Applied, Thanks. Daniel.
[CVS ci] EXEC and libparrot.so
If you want to compile your .pbc to $(EXE) but you don't want blib/lib/libparrot.a included in each one, you can do it by linking the generated .o with blib/lib/libparrot.so (you can try make exec_so EXEC=program_name but I'm unsure if it will work correctly) In order to have this working you must recompile parrot with EXEC_SHARED defined (s. jit/i386/jit_emit.h), I know this should be a command line option instead of a compile time one, I'll fix that. Daniel.
Re: packfile and EXEC
On Wednesday 13 August 2003 05:07, Leopold Toetsch wrote: I started extending the packfile functions towards multiple code segments. First is still some cleanup, but I already have troubles with the EXEC stuff :-( I could not reproduce the error here. The debugger doesn't really like this file. Anyway, what assumptions does EXEC have WRT the packfile, e.g. fixed order first const_table then bytecode or such? No, it just stores the offset of the bytecode. What info does EXEC need, to write out the object file? From the packfile, the offset of the bytecode and the size of constant table. EXEC should probably get a set of callback functions (s. pf_register_standard_funcs) for each of the segment types. leo Daniel
Re: packfile and EXEC
On Wednesday 13 August 2003 12:28, Daniel Grunblatt wrote: On Wednesday 13 August 2003 05:07, Leopold Toetsch wrote: I started extending the packfile functions towards multiple code segments. First is still some cleanup, but I already have troubles with the EXEC stuff :-( I could not reproduce the error here. Just checked in a patch that should solve it, but it's temporary since it's overwriting something somewhere :), I'll track it down. Daniel.
[CVS ci] EXEC ARM
Now EXEC works for ARM (linux) too.
[CVS ci] MIPS JIT
I've checked in what I did last year to make the JIT work on MIPS, it's not finished but IMHO it's a good start, so if anyone wants to continue or gimme an account in one (which I don't have anymore) I would be glad. Daniel.
Re: [CVS ci] Exec
On Friday 08 August 2003 14:16, Nicholas Clark wrote: On Fri, Aug 08, 2003 at 01:48:17PM -0300, Daniel Grunblatt wrote: Now Exec works exactly like the jit, I have checked in the missing restart, fixed some bugs at Parrot_jit_store_retval and make exec_start call runops instead of calling run_compiled directly, so now all test are successful. Woohoo! Does this mean that you've delivered your grant deliverables? I think so, yes. Nicholas Clark Daniel.
[CVS ci] Exec
Now Exec works exactly like the jit, I have checked in the missing restart, fixed some bugs at Parrot_jit_store_retval and make exec_start call runops instead of calling run_compiled directly, so now all test are successful. Have fun. Daniel.
Re: Packfile stuff
On Monday 04 August 2003 14:03, Dan Sugalski wrote: Here's some stuff we need to add to the packfile format and the sub header to get things ready for more language work. Packfiles need to have a symbol table. A series of name/type/location tuples so we can have global names that map to values in the bytecode, either variables or subroutines. When the bytecode is loaded, we need to put those symbols in the symbol table and construct the backing PMCs. Guess what you really want is a symbol table (with name/type) and a rellocation table (symbol number/location), to avoid having the name repeated, right? Daniel
Re: JIT bug with restoretop
On Sunday 03 August 2003 15:27, Simon Glover wrote: On 3 Aug 2003, Luke Palmer wrote: This fix has worked fine with JIT until now, so I suspect the problem is elsewhere. Bug confirmed here (although I need a slightly longer string to trigger it). Here's a stacktrace: I couldn't reproduce it here, but from your bt I supposed that jit_info-objfile was getting something (!= NULL) while running under jit, as it was not initialized correctly, so I fixed that. Could you confirm if the bug's still there? Simon Daniel
Re: cvs commit: parrot embed.c
On Thursday 31 July 2003 14:31, Brent Dax wrote: Daniel Grunblatt: +PIO_eprintf(interpreter, Parrot VM: Platform JIT_ARCHNAME + is not EXEC-capable.\n); An unprefixed constant like JIT_ARCHNAME should not be available to embedders. If it is, something's wrong. I don't have a copy of the source with me, and I'm writing this offline, so I can't tell you what the correct constant is. Fixed, thanks. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Daniel.
[CVS ci] Exec argument.
I have checked in a patch to make the following work: ./parrot -o life.o examples/assembly/life.pbc So, don't use test_main anymore. I made this storing the pointer to the -o argument in the interpreter string register 0 to make it visible from inside the core, instead of adding another pointer the the interpreter structure. s. embed.c:302 Daniel.
Re: [perl #23159] Parrot SIGSEGV in scratchpad_find
On Tuesday 29 July 2003 21:10, chromatic wrote: On Tuesday, July 29, 2003, at 02:41 PM, Simon Glover wrote: Therefore the decision was taken that we should not guarantee that Parrot should never segfault when fed bad assembler; the creation of invalid assembler is a compiler bug, and should be fixed at the compiler level. If people write PBC directly, perhaps the assembler could do a few checks. It may not be a good idea. It's just an idea. Another idea (not mine and I can't recall from whom) is to write a safe interpreter where every single check of those Jos propose is done, may be this could be done by adding #if SAFE_INTERPRETER checks and a configure option, I know this will make the interpreter really slow, but safe. -- c Daniel.
Re: make fails on MacOS X 10.2.6
On Monday 28 July 2003 20:46, Tim Howell wrote: ?tches from a few days ago to allow executable creation, the current CVS no longer compiles properly on my MacOS X 10.2.6 box. The error I get is: exec_save.c:319:16: #if with no expression make: *** [exec_save.o] Error 1 The following patch seems to fix things, although I don't know if this is the best way to do it: --- exec.hMon Jul 28 16:37:58 2003 +++ exec.h Mon Jul 28 16:38:17 2003 @@ -25,7 +25,7 @@ # define EXEC_A_OUT # endif # if EXEC_OS == DARWIN -# define EXEC_MACH_O +# define EXEC_MACH_O 1 # endif # if (EXEC_OS == FREEBSD) || (EXEC_OS == LINUX) # define EXEC_ELF No, it's not, I'll apply a patch for this and other stuff shortly. Daniel.
[Cvs ci] EXEC on linux/PPC (was make fails on MacOS X 10.2.6)
On Monday 28 July 2003 20:53, Simon Glover wrote: On Mon, 28 Jul 2003, Tim Howell wrote: ?tches from a few days ago to allow executable creation, the current CVS no longer compiles properly on my MacOS X 10.2.6 box. The error I get is: exec_save.c:319:16: #if with no expression make: *** [exec_save.o] Error 1 The following patch seems to fix things, although I don't know if this is the best way to do it: Wouldn't a better solution be to turn the #if into an #ifdef? Yes Simon --- exec_save.c.old Mon Jul 28 15:26:08 2003 +++ exec_save.c Mon Jul 28 19:50:54 2003 @@ -316,7 +316,7 @@ #endif /* EXEC_ELF */ -#if EXEC_MACH_O +#ifdef EXEC_MACH_O /* This is a hack. */ Parrot now emits an executable on linux/PPC, enjoy. Daniel.
Re: [perl #23115] powerpc linux support
On Thursday 24 July 2003 22:02, Arcady Goldmints wrote: # New Ticket Created by Arcady Goldmints # Please include the string: [perl #23115] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23115 Contrary to popular belief, linux does run on things other than x86, and people with powerpc machines do use OSs other than Darwin. It seems, however, that the parrot configure system does not detect my platform as JIT-capable, even though I have a strong suspicion that it would work anyway. However, I don't understand the configure system well enough to get it to let me use JIT. Also, the executable file generator (jit/ppc/exec_dep.h) only supports Darwin Mach-O files, and not powerpc linux which uses ELF. Arcady The JIT is working. I'll see what it takes to make EXEC work too. Daniel.
Re: cvs commit: parrot/jit/ppc exec_dep.h
Yes, it's already fixed, thanks. On Friday 25 July 2003 17:55, Garrett Rooney wrote: Daniel Grunblatt wrote: +# endif +# if EXEC_OS == DARWIN +# define EXEC_MACH_O +# endif +# if (EXEC_OS == FREENBSD) || (EXEC_OS == LINUX) # define EXEC_ELF # endif Umm, I think you mean FREEBSD there ;-) -garrett Daniel.
[COMMIT] Parrot emits an executable
I have checked in a first attempt to make parrot generate an executable. It works fine on x86 - OpenBSD/linux/FreeBSD and should also work on NetBSD For PPC (Darwin) it generates code correctly just for programs that use *only* fully jitted opcodes. It should work with or without JIT_CGP. After building parrot you should make exec_start.o that is used to start running the compiled code. Then you can use it like this: # ./test_main -o t.pbc This will generate exec_output.o (I know that -o must require an argument I just don't know which is the correct way to actually make the argument visible from insede the core, should I just add a pointer in the interpreter and a subroutine to embed.c? or what?) # cc -o whatever exec_output.o exec_start.o blib/lib/libparrot.a -lm -lutil (or whatever your system require) It's not finished, vtable and nci stuff is missing. This are some of the things I did in order to make this work: * Added an interpreter structure as a global variable. * Make all the opcodes in core_ops.c global, not static, I add a rellocation every time a non-JITted opcode is called and need the linker to know about this functions. * Put the program bytecode (the pbc) as part of the obj, as pbc2c.pl does since I need the address of the bytecode in the JITted code and in x86 (at least in BSD) the bytecode is the same than in the pbc, I know this might not be 100% correct since if a pbc generated at a 64bit architecture or with a different endianess will be unpacked differently and this won't work, but I'll look at this later. * Added the opcode_map too, this is need to make the restart and the not jitted opcodes that change the program control flow work, the real adresses are fixed at runtime, I'll see if I can do something to make the linker take care of this, I'm sure this is possible yet. * The constant table is also added and every time the bytecode unpacker need to add a constant this memory is used instead of allocating new memory. Now, every time the jit emits an instruction that has the address of a Parrot regiter, the interpreter, the bytecode or a constant I must add a rellocation at the exact address of the 4 bytes that will be the adress, for this I assume that the last 4 bytes of the emited instruction holds this address adding the rellocation at native_ptr - 4, but this is not correct for macros that emits more than 1 instruction (like the floating point ones) hence I made a horrible hack at jit2h.pl which change the displacement from -4 to, say, -6. Another way I see to make this is adding a list of macros with their displacement? (if the macro is not in the table it's -4) or what? Enjoy. Daniel Grunblatt.
Re: [COMMIT] Parrot emits an executable
On Thursday 24 July 2003 15:14, Simon Glover wrote: On Thu, 24 Jul 2003, Daniel Grunblatt wrote: I have checked in a first attempt to make parrot generate an executable. It works fine on x86 - OpenBSD/linux/FreeBSD and should also work on NetBSD It's not working for me on Linux/x86 -- the build is failing with: In file included from exec.c:20: include/parrot/exec_dep.h: In function `Parrot_exec_save': include/parrot/exec_dep.h:383: `ELFOSABI_LINUX' undeclared (first use in this function) include/parrot/exec_dep.h:383: (Each undeclared identifier is reported only onceinclude/parrot/exec_dep.h:383: for each function it appears in.) make: *** [exec.o] Error 1 Looking in elf.h, these are the only ELFOSABI... constants defined: #define EI_OSABI7 /* OS ABI identification */ #define ELFOSABI_SYSV 0 /* UNIX System V ABI */ #define ELFOSABI_HPUX 1 /* HP-UX */ #define ELFOSABI_ARM97 /* ARM */ #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */ I'm using a 2.4 kernel, libc v2.2.4 gcc v2.96 Could you send me the output of readelf -h core_ops.o? Thanks. Simon Daniel.
Re: [COMMIT] Parrot emits an executable
On Thursday 24 July 2003 15:48, Juergen Boemmels wrote: Daniel Grunblatt [EMAIL PROTECTED] writes: I have checked in a first attempt to make parrot generate an executable. This is very cool. Thanks. It works fine on x86 - OpenBSD/linux/FreeBSD and should also work on NetBSD Not at the moment. My Linux-system (an SUSE 7.3 or 8.0) has a /usr/include/elf.h but it does not define ELFOSABI_LINUX. This file only contains #define EI_OSABI7 /* OS ABI identification */ #define ELFOSABI_SYSV 0 /* UNIX System V ABI */ #define ELFOSABI_HPUX 1 /* HP-UX */ #define ELFOSABI_ARM97 /* ARM */ #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */ For PPC (Darwin) it generates code correctly just for programs that use *only* fully jitted opcodes. It should work with or without JIT_CGP. About to solve this. Nope with Configure.pl --cgoto=0 this fails. Attached patch is what I needed to get it to compile, and make it pass make test. Applied, thanks! After building parrot you should make exec_start.o that is used to start running the compiled code. Then you can use it like this: # ./test_main -o t.pbc This will generate exec_output.o (I know that -o must require an argument I just don't know which is the correct way to actually make the argument visible from insede the core, should I just add a pointer in the interpreter and a subroutine to embed.c? or what?) Put the name of the outputfile in the interpreter structure. [...] bye boe Daniel.
Re: [COMMIT] Parrot emits an executable
On Thursday 24 July 2003 15:55, Juergen Boemmels wrote: Magic: 7f 45 4c 46 01 01 01 00 -- 00 00 00 00 00 00 00 00 OS/ABI:UNIX - System V Patch is in, please resync and try it. boe Daniel
Re: [COMMIT] Parrot emits an executable
On Thursday 24 July 2003 16:13, Simon Glover wrote: On Thu, 24 Jul 2003, Daniel Grunblatt wrote: On Thursday 24 July 2003 15:55, Juergen Boemmels wrote: Magic: 7f 45 4c 46 01 01 01 00 -- 00 00 00 00 00 00 00 00 OS/ABI:UNIX - System V Patch is in, please resync and try it. It's now dieing with: In file included from exec.c:22: include/parrot/exec_dep.h: In function `Parrot_exec_normal_op': include/parrot/exec_dep.h:80: `cgp_core' undeclared (first use in this function)include/parrot/exec_dep.h:80: (Each undeclared identifier is reported only once include/parrot/exec_dep.h:80: for each function it appears in.) exec.c: In function `Parrot_exec': exec.c:77: `cgp_core' undeclared (first use in this function) make: *** [exec.o] Error 1 Still, we're making progress :-) No, it was the patch for the HAVE_CGOTO that should have been HAVE_COMPUTED_GOTO, bad me, fixed. Simon Daniel.
Re: cvs commit: parrot/jit/ppc jit_emit.h
Back in. On Tuesday 08 July 2003 11:32, Sean O'Rourke wrote: On 7 Jul 2003, Daniel Grunblatt wrote: cvsuser 03/07/07 13:20:40 Modified:jit/ppc jit_emit.h Log: * 2 instructions instead of 3 to load a 32 bit integer. I'm not sure this is a win, since loading small constants used to take only a single instruction (it's easy to put that back in, though). /s Daniel.
Re: Native code
On Tuesday 27 May 2003 21:25, Bill Atkins wrote: Am I correct in assuming that Parrot's JIT will eventually be able to produce directly-executable files, like .exe's? Yes, you are. Bill Daniel.
Re: Using imcc as JIT optimizer
On Thursday 20 February 2003 18:14, Leopold Toetsch wrote: Tupshin Harper wrote: 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? ;-) It only may be equally fast, that's it :) Nahh, you know it can be faster... may be in a couple of years ;-D Cool idea, if I understand correctly, and I am in awe of how fast the bloody thing is already. That's integer/float only. When it comes to objects, different things matter. -Tupshin leo
Re: Odd JIT timings
On Friday 24 January 2003 04:43, Dan Sugalski wrote: I just gave a run of examples/assembly/mops_p.pasm, getting some performance numbers. Here's an interesting timing. no jit: 24.9 seconds with jit: 33.6 seconds This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86. Someone care to check it out and poke around a bit? CG vs JIT (running with non jitted opcdes) wins CG, always. Daniel Grunblatt.
Re: [perl #19729] [PATCH] SPARC JIT support for restart
Applied, thanks. Daniel Grunblatt. On Sunday 05 January 2003 01:10, Jason Gloudon (via RT) wrote: # New Ticket Created by Jason Gloudon # Please include the string: [perl #19729] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19729 This patch adds JIT support for restart and similar ops.
Re: [perl #19610] [PATCH] New language support: Ook!
On Monday 30 December 2002 21:30, Leopold Toetsch wrote: Jerome Quelin (via RT) wrote: # New Ticket Created by Jerome Quelin # Please include the string: [perl #19610] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19610 - currently I'm just printing on stdout the resulting parrot code, I lack an eval instruction in Parrot. Dan, Leo? :-) Here is the solution of our perl6 bootstrapping problem, I'll make an Ieval ops ... May be you can use PDB_eval (If it's still around)
Re: [CVS ci] more JIT changes: register usage array, block allocation..
On Friday 29 November 2002 05:59, Leopold Toetsch wrote: Recent changes to jit: Register usage is now kept in an array per register type and is calculated for non jitted sections too. Register usage can be per section (a sequence of either jitted or nonjitted ops not separated by branches) or per basic block. This allows later to avoid some register loads, when there are preserved registers.[1][2] There are some commented out trials, to optimize register load/stores, but we have to solve at least [1] before going on here. All allocated memory in jit.c is now freed (except for REQUIRES_CONSTANT_POOL, which I don't know, what it does). There are now more tunable defines in jit_emit.h, where per architecture settings are kept: - preserved registers - dont allocate only once used registers - allocate regs per section or per block - align jump targets[3] All have reasonable defaults, which map the old behaviour, so no changes to architecture files should be needed currently. [1] we currently have no information, that e.g. Cpopi changes the parrot registers. For all other ops we have the ARGDIR flags. Proposed change for pop opcodes: set ARGDIR_OUT on the opcode. [2] when we know, that an external opcode doesn't throw an exception, we could avoid saving registers too. [3] I don't know, if it would be needed. I had some drastic slow down in mops.pasm, when there was an odd branch target, but this was not the reason actually, code size (or where the loop is located) seems to be the culprit, s. end of jit/i386/jit_emit.h - does anyone know, what's goin on here? The problem is that we do want to allocate a hardware register for a Parrot register that is used only once in the section since the section can be executed more than once, if you don't mind I want to remove ALLOCATE_REGISTERS_ALWAYS. Daniel Grunblatt.
Re: [CVS ci] more JIT changes: register usage array, block allocation..
On Sunday 01 December 2002 18:04, Leopold Toetsch wrote: Daniel Grunblatt wrote: The problem is that we do want to allocate a hardware register for a Parrot register that is used only once in the section since the section can be executed more than once, if you don't mind I want to remove ALLOCATE_REGISTERS_ALWAYS. I do mind, until all platform concerns are sorted out. On my Athlon the inner loop in mops.pasm is as fast with one memory access as with two registers. But that's not true on my Intel PIII nor on my PI 233. I get a 50% speed up on both. We probably really want to allocate registers for RISC platforms where we can, but not on i386, where a register is a rare ressource. It doesn't harm to keep it. And platforms can turn it on or off. Keep it for what? If there is any other thing in the section that deserves a register more than it, that's OK, but if there won't be anything else using it why will we keep it? Daniel Grunblatt. leo
Re: [RFC] unified core.jit
On Wednesday 20 November 2002 04:41, Leopold Toetsch wrote: Or praeprocessor magic, redifining the Parrot_jit_ops to Parrot_jit_native OK. I just committed a renaming for the ppc. and others in the meantime - good. Are these _load _store different or will they just become _mov. (The displacement-suffix is IMHO not needed on the surface. True true I'll fix that now. I'm thinking of a structure like this: generic.jit ... 3 operand machine with op_r_r_r ... op_m_m_m risc.jit ... 3 register machine, 2 scratch for memory ops cisc.jit ... 2 register machine, 1 scratch $arch.jit ... overriding if necessary and when present generic.jit implements the register MAPping and could probably be autogenerated from core.ops. risc.jit provides macros for preparing the scratch registers for the memory operands, cisc.jit similar. $arch.jit could implement anomalies like i386 shift ops. I don't really know if we should spent too much time on this instead of creating an intermediate language to write opcodes on it. Daniel Grunblatt.
Re: [RFC] unified core.jit
I would do a cisc.jit and a risc.jit to avoid the #ifdef forest.
The problem is when you want to implement an opcode like div, which is easy in
ppc but not in arm ideas?
I was sort of going in that direction, mips/core.jit is almost like
ppc/core.jit (If everything is on schedule I'll find some time to finish it
on december).
Daniel Grunblatt.
On Tuesday 19 November 2002 10:04, Leopold Toetsch wrote:
Currently all architecures have there own core.jit. These are very
similar, e.g. checking for MAPped registers, but differ depending on
the processor architecure: basically we have 3 register machines
(alpha, arm, ppc, sparc) and a 2 register machine (i386).
My proposal is to write a universal core.jit, which provides the basic
functionality.
e.g.
Parrot_add_i_i_i {
if (MAP[1] MAP[2] MAP[3]) {
#ifdef jit_emit_add_rrr_i /* 3 reg machine */
jit_emit_add_rrr_i(MAP(2), MAP(3), MAP(1));
#else
jit_emit_mov_rr_i(MAP(2), MAP(1));
jit_emit_add_rr_i(MAP(3), MAP(1));
#endif
}
...
The implementation of these jit_emit_ops would stay in jit_emit.h.
Proposed naming of ops:
jit_emit_op_rmi_in(...)
op operations mov, add, sub, mul, ...
rmi register, memory, immediate, for all parameters
(source, dest) or (source, source, dest)
in integer (or pointer...) or number
jit_emit_mov_rm_n(reg, mem)
(store processor reg to parrot num_reg at mem)
jit_emit_mov_mr_i(mem, reg)
(load processor reg from parrot int_reg at mem)
The regs would be taken from a list of processor regs, either the
MAPed ones, or 1 or 2 scratch registers, depending on architecture.
jit_emit_jmp_p(cond, offset)
jit_emit_call_p(offset)
Jump to or call parrot funcs at offset.
cond : cond_always, cond_lt,le,gt,ge,eq,ne
jit_emit_push_rm(.., SP_diff)
jit_emit_call_c(addr)
jit_emit_call_vtable(mem_of_pmc_reg, int n)
jit_emit_add_SP(SP_diff)
jit_emit_ret
Push (or whatever) params on stack, preparing for a native call,
correct SP after return.
With these ops, all the current functionality could be in one file,
all the register mapping would be centralized.
If something doesn't fit, it could be undefined for this architecture,
the implementation would then be in jit_emit.h.
Comments welcome
leo
Re: [RFC] unified core.jit
On Tuesday 19 November 2002 11:54, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
The problem is when you want to implement an opcode like div, which is
easy in ppc but not in arm ideas?
I don't know arm, but this belongs to jit_emit.h, how it's done there is
a different issue.
what if we just don't want to implement that opcode in this specific
architecture?
But can we have a united syntax for {c,r}isc.jit. The problem currently
is, that moves or other ops are sometimes written as op(src, dest),
sometimes exactly the other way round.
I really want this have sorted out. I'm currently writing tests
(jit/i386 is failing a lot of them, due to wrong move directions: e.g.
add_i_i_i, sub_i_i_i)
Proposed naming of ops:
jit_emit_op_rmi_in(...)
op operations mov, add, sub, mul, ...
rmi register, memory, immediate, for all parameters
(source, dest) or (source, source, dest)
rmid register, memory, immediate, displacement
We could do it like parrot (dest, src, src) too, but I want really a
unique naming convention.
leo
Cool, let's do it like parrot.
I just committed a renaming for the ppc.
I believe that Parrot_end will have to call jit_emit_end() that will reside in
jit_emit.h and will be just like Parrot_end is now since every calling
convention is different.
Daniel Grunblatt.
Re: Quick note on JIT bits
On Thursday 14 November 2002 05:14, Leopold Toetsch wrote: Dan Sugalski wrote: I'm about to do exceptions, and as such I wanted to give a quick warning to everyone who does Odd Things. (Which would be in the JIT, mainly :) Because of the way exceptions are going to work, we need to make sure that the code emitted for each individual opcode is self-contained, relative to the system stack. That is to say, when an opcode is done it can't leave any cruft on the system stack, and it shouldn't expect there to be any information on the system stack. This would mean, that current jit/i386 is not ok, because it pushes a parrot Interp* on the stack in Parrot_jit_begin and leaves it there ... That's just a speed hack that will go away when the moment comes. The exception system's going to be based on setjmp/longjmp[*], with a setjmp done just before entering the runloop, and longjmps done when an exception is thrown. The low-level exception handler will then unwind the interpreter stacks until it finds an exception handler, at which point it'll enter the runloop at the point the exception handler dictates. but reentering the (jitted) runloop is just like Parrot_jit_begin + jump to current_pc, so it would be ok. ... So recursive calls to parrot functions can't recursively use the system stack or anything, as that'll get unwound by the low-level exception scheme and Bad Things Will Happen. And we wouldn't want that... I don't see any recursive calls. But anyway, when on (re)entering the runloop everything gets setup as it ought to, an exception is a noop. What I'm missing here? The real problem is different IMHO and we had this already with perl 6 exceptions[1]: resuming after an exception may theoretically happen on an arbitrary opcode, which might be e.g. in midst of a jitted section, where parrot registers live in processor registers. What JIT needs to know is the location of the resume opcode, to mark it as a jump target properly, so that processor registers can be setup correctly. Well, any opcode could be a target, so I suggest to build something like a section entrance code that given the PC could load the apropiate registers and jump to the middle of a jitted section. Yes, it will be slow but we are talking about exceptions here. More problems arise here: The exception handler might use parrot registers, which might live (or better might have lived) in processor registers, which the longjmp already has destroyed. So we IMHO need to mark each OP with a flag, if it might throw an exception and restore all processor registers to parrot registers before doing this OP. Since there isn't any jitted opcode throwing an exception (and all registers are saved back to parrot register before calling C code), and if there were any opcode jitted throwing an exception it must save the registers back before doing so. [1] imcc marks the address of a set_addr OP as branch target, so that this basic block wouldn't be removed by dead code detection and the register allocator does know what to do. When a arbitrary opcode can jump out of the current block and resume elsewhere, the register allocator can't assign the same registers to these variables. So we have 3 levels, where we might have troubles: - JIT: processor registers - IMCC: parrot registers - HL: lexicals leo Daniel Grunblatt.
Re: Quick note on JIT bits
On Thursday 14 November 2002 10:32, Leopold Toetsch wrote: Daniel Grunblatt wrote: On Thursday 14 November 2002 05:14, Leopold Toetsch wrote: What JIT needs to know is the location of the resume opcode, to mark it as a jump target properly, so that processor registers can be setup correctly. Well, any opcode could be a target, so I suggest to build something like a section entrance code that given the PC could load the apropiate registers and jump to the middle of a jitted section. Yes, it will be slow but we are talking about exceptions here. There must be some code, that installs the exception handler. This code has the address of the exception handler, which JIT has to know too. Being prepared to enter at arbitrary places in JIT would inhibit processor register usage totally, or wouldn't be any win. Either I didn't make my self clear (sorry) or my understanding of exceptions is wrong ... probably both. When, say, div throws an exception it will longjmp to the handler, that handler will know where to continue the execution of the program, right? so after doing its job it will have to call a function that given a PC will load the cpu registers as needed and jump into the jitted code again but if there was no exception the jitted code executes as usual. So we IMHO need to mark each OP with a flag, if it might throw an exception and restore all processor registers to parrot registers before doing this OP. Since there isn't any jitted opcode throwing an exception ... div by zero, modulo (div currently only PPC but...) (and all registers are saved back to parrot register before calling C code), ... which I want to avoid for callee saved registers ... and if there were any opcode jitted throwing an exception it must save the registers back before doing so. So, it would be useful to know, which op code might throw an exception. Certainly. Daniel Grunblatt. leo Daniel Grunblatt.
Re: [CVS ci] JIT bug fix
On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote: I could localize a long outstanding bug in JIT causing 4 perl6 tests to fail. When an opcode was a branch target as well as a branch source, the branch target got lost, causing wrong basic blocks, implying missing register loads ... I wonder who was the #%$# that introduced that bug . D'OH! :) All perl6 tests are now ok on JIT too. YAY! Thanks. leo
Re: [CVS ci] JIT bug fix
On Wednesday 13 November 2002 11:48, Leopold Toetsch wrote:
Daniel Grunblatt wrote:
On Wednesday 13 November 2002 08:06, Leopold Toetsch wrote:
I could localize a long outstanding bug in JIT causing 4 perl6 tests to
fail.
I wonder who was the #%$# that introduced that bug . D'OH! :)
Wow, Daniel, the lost son himself ;-)
:)
:
So I immediately have a question (or some):
I'm currently studying jit.c and I'm wondering, it it wouldn't be better
to allocate registers for a whole basic block, and only store/load the
used registers for non JITed sections when necessary. These normally
don't have a lot of IRegs, so we could save a bunch of store/load's.
Oh yes, the optimizer doesn't do any cross section analisis yet, I'll fix
that.
see:
http://groups.google.com/groups?selm=20020805215944.GB301%40Bagpuss.unfortu.n
et
And 2), when doing this, I would change
char intval_map[INT_REGISTERS_TO_MAP] =
{ emit_EDI, emit_EBX, emit_EDX, emit_ECX };
to use callee saved regs first (ebx, edi, esi), and then (edx, ecx),
which would mean, that the first 3 registers wouldn't be globbered by
external functions. The current usage of esi could be done by ebp, I
think. This would need some defines, how many/which registers are callee
saved (like CALL_USED_REGISTERS in gcc/config/*).
What do you think of this?
Good idea.
Daniel Grunblatt.
leo
Re: [CVS ci] JIT - i386
You will see it running as fast as mops.c compiled with -O3 if you change REDO: sub I4, I4, I3 for REDO: dec I4 But that's obviously part of a higher level optimizer. On Wednesday 13 November 2002 15:10, Leopold Toetsch wrote: Watch the mops ;-) leo
Re: [perl #16767] [PATCH] pdb improvements
On Mon, 26 Aug 2002, Steve Fink wrote: # New Ticket Created by Steve Fink # Please include the string: [perl #16767] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16767 - eliminates a bunch of seg faults from bad input - allow passing command-line arguments to the program - allow printing indexed aggregates indexed by integers (eg 'p P0[0]') (other key types need implementing) - makes pdb exit on EOF (ctrl-d on unix) - removed some code duplication, other cleanups CC'ing this to Daniel Grunblatt since it's his baby I'm molesting. -- attachment 1 -- url: http://rt.perl.org/rt2/attach/35709/28946/2a6256/pdb.patch Applied, thanks. (Had to make some changes because I committed some stuff yesterday, I would have applied your patch before doing them but sadly I get p6 email between 1 and 6 hours late.) Daniel Grunblatt.
Re: [perl #16741] languages/parrot_compiler fixups
On Sun, 25 Aug 2002, Mike Lambert wrote: # New Ticket Created by Mike Lambert # Please include the string: [perl #16741] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16741 The below patch fixes the languages/parrot_compiler/ code to work again with the new keyed syntax. It correctly compiles languages/parrot_compiler/sample.pasm and parrot executes it fine. The only change I'm unsure about it is the use of -e instead of -e'' to make activestate perl happy. ie, I'm not sure if it breaks other platforms. Thanks, Mike Lambert -- attachment 1 -- url: http://rt.perl.org/rt2/attach/35605/28863/5e145e/fixup.diff Applied, thanks. Daniel Grunblatt.
Re: is MANIFEST up-to-date?
On Mon, 26 Aug 2002, Andy Dougherty wrote: Currently, a fresh checkout of the cvs tree contains 2215 files, but only 497 of them are listed in MANIFEST. Most are the icu/ files, but there are scattered others as well. I'm unsure if all of them are supposed to be in MANIFEST yet (e.g. is icu a work-in-progress?) but could those who have recently added files to the distribution please check if MANIFEST is up-to-date for those files? I think I have added all the missing files. (not icu) Daniel Grunblat.
[COMMIT][PDB] Condition breakpoint watchpoints.
I just added condition breakpoints and watchpoints, now you can do: (pdb) b 4 if S14 = parrot See docs/debugger.pod for details. Is it worst to allow something like this?: if (((S14 == I0) (I4 = N3) (N3 4.5 N7)) || (I5 == 32)) Daniel Grunblatt.
Re: Prototypes
On 13 Aug 2002, Piers Cawley wrote: Melvin Smith [EMAIL PROTECTED] writes: At 06:56 PM 8/12/2002 +0100, Simon Cozens wrote: Here's a more interesting question: which parts of Parrot are enshrined, and which are prototypes, ready to be thrown away? For instance, I'd say much of languages/* is all proof-of-concept prototype stuff; imcc may not be. The assembler I'd call a prototype. The regex engine? The GC? ... On that topic, given that the reference assembler is too slow for on-the-fly assembly, I already decided that imcc should get its own C based assembler. Now that the C (XS) interface is gone, it means we will be duplicating code. I'm not saying the Perl based assembler is a BAD thing, but I think time spent tuning the reference assembler is wasted when it could be spent writing a really fast one in C. There's a small, mad part of me that wonders if parrot would now support an assembler that was implemented in Parrot. Then we'd know that the assembler was at least as portable as parrot itself... Something like languages/parrot_compiler/ but working, right? Daniel Grunblatt.
Re: Prototypes
On Tue, 13 Aug 2002, John Porter wrote: Piers Cawley wrote: I'd also like to be able to generate parrot code from within parrot and immediately execute it... Something like that will be needed for eval() anyway, right? Yes, like PDB_eval() may be... Daniel Grunblatt.
Re: debugger.pod
On Fri, 2 Aug 2002, Aldo Calpini wrote: hello everybody, here is my rough draft of the documentation for the Parrot debugger. please review it (expecially the boilerplate stuff like TITLE, HISTORY, etc. -- I don't know if I have properly followed convention) (and if there is one) and tell me if this should be sent as a patch. Applied, thanks. Daniel Grunblatt.
Re: [PATCH] hash init (Version 5)
On 12 Aug 2002, Jason Greene wrote: One more safety check (fixes another crash bug). Hopefully this is the last patch patch. Applied, thanks. Daniel Grunblatt.
Re: [perl #16144] [PATCH] quotematch speedup
On Mon, 12 Aug 2002, Simon Cozens wrote: It's my opinion that it went from there back to pure-Perl because people here are happier handling pure Perl than XS. Jeff may have to correct me on that. I moved it back to pure-Perl because there were something like half of the tinderboxes failing to assemble anything. Probably I should have gone the other way and fix it. Daniel Grunblatt.
Re: Prototypes
On 12 Aug 2002, Simon Cozens wrote: Here's a more interesting question: which parts of Parrot are enshrined, and which are prototypes, ready to be thrown away? For instance, I'd say much of languages/* is all proof-of-concept prototype stuff; imcc may not be. The assembler I'd call a prototype. The regex engine? The GC? ... The assembler is a bit outdated, it shouldn't be too difficult to bring it up to date, I just don't have enough time latetly. But it did work fine and is easy to extend it. Why do you think it should be thrown away? Daniel Grunblatt.
Re: [perl #16144] [PATCH] quotematch speedup
On 12 Aug 2002, Simon Cozens wrote: [EMAIL PROTECTED] (Daniel Grunblatt) writes: I moved it back to pure-Perl because there were something like half of the tinderboxes failing to assemble anything. Ah, right. Yeah, the tinderboxes are good slaves but really bad masters. True, but I was writing the register allocator for the jit and needed to assemble bytecode on the alphas, just went the way I found easiest for me. Daniel Grunblatt.
Re: Prototypes
On 12 Aug 2002, Simon Cozens wrote: [EMAIL PROTECTED] (Daniel Grunblatt) writes: The assembler is a bit outdated, it shouldn't be too difficult to bring it up to date, I just don't have enough time latetly. But it did work fine and is easy to extend it. Why do you think it should be thrown away? It's in Perl? Oh, no, I was talking about languages/parrot_compiler/. Sorry. Daniel Grunblatt.
Re: Prototypes
On 12 Aug 2002, Simon Cozens wrote: [EMAIL PROTECTED] (Daniel Grunblatt) writes: Oh, no, I was talking about languages/parrot_compiler/. Sorry. Oh, I hadn't seen that. I can't work out what it is; it seems to be a device for generating Couldn't find operator errors. Is there any, dare I say it, documentation for it? I did say it was outdated. No there is no documentation, and there won't be any from me in the near future. Daniel Grunblatt.
Re: [COMMIT] Register allocator for the JIT
On Wed, 7 Aug 2002, Nicholas Clark wrote: I'd not thought of this. You're right, but I think the trade off is the cumulative time you save each time the JITted routine is called, versus the time you took to track usage. I guess inside frequently called functions it could become worthwhile. The JITted routine is called only once, right? Er, yes, D'oh. Good point. I was thinking in terms of the JIT being run per subroutine, but actually it's run per block of bytecode. Except that 1: If I understand the plan, loading any sort of perl module (use Foo.pm;) could cause parrot to load pre-compiled bytecode for that module, rather than the module. In which case, parrot is going to have multiple discontinuous blocks of bytecode in memory, with calls between them. So I assume that the JIT will be JITting the perl script first, then as and when each module is loaded, that gets JITted. 2: BEGIN blocks. (As in, they need to run as soon as the closing } is seen, which means that certainly bytecode, if not JITted bytecode, is going to get run in chunks in a script that uses a BEGIN block) 3: regexps are going to compile to bytecode, and I was assuming that in turn that bytecode was going to get JITted, and called into once per regexp match Right. 4: We may want to create fat bytecode files, with pre-JITted (ie compiled) code next to the bytecode for CPU(s) of the machine the file is mounted to. That's an idea, we can also make native executables. It would be useful if the bytecode had a way for the bytecode generator to give a hint about how hard any sort of runtime optimiser should try to optimise a function. So we'd only do this sort of thing for (say) repeatedly run regexps. In some time we can try to do some profiling on the fly to decide where to optimise. If I follow the recent work on imcc correctly, then it is already trying to determine where loops are to avoid spilling registers inside loops (by spilling them outside. Is this the waterbed theory of graph colouring?) If so, imcc has already done some work about where slightly more JIT effort might pay off, so it seems a shame to throw that out. Yes, that's why we are not going to do any kind of optimization that is not required to be done at runtime, that means, we expect the most optimal bytecode. Daniel Grunblatt.
[COMMIT] PPC JIT
OK, now we have the JIT working on PPC. More opcodes coming. It's not currently using a constant pool but it should. Thanks to Sean for the sync cache code and helping me. Daniel Grunblatt.
Re: ARM Jit v2
On Sat, 3 Aug 2002, Nicholas Clark wrote: I wasn't actually expecting you to apply that :-) It was more a where I am at now informational patch. Sorry :) I think that this patch is at good point to pause and take stock. I believe it JITs just about every integer op (including some i386 isn't JITting yet) Great job! OK, it doesn't JIT the logical xor op, but that one scares me, and I'm unsure how useful it is. I've not done the floating point ops (or anything else) partly because I don't have a good reference for the format of the floating point instructions. [However, it's not that hard, as I have source code to both point emulators supplied with ARM Linux, so I can see the decode code :-)] But more because I'm not sure that it will give such a speed it. I feel I've demonstrated to myself that it will be possible to generate all forms of parrot ops without undue problems. However, I've hardly used any registers in my ops so far (at most 3, but I only actually needed 2) when there are up to 12 at my disposal. I've no real idea which will turn out to be the most useful in real parrot programs, and hence where the effort in JITting will get most reward, so I think it best to wait now and see what is needed most. My other thought is that with the current JIT architecture I'm loading everything from RAM at the start of the ops (1 or 2 instructions), and save it back at the end (1 instruction) with only 1 or 2 instructions need to actually do the work. With 10 registers spare, and 60% of my instructions shifting data around like some job creation scheme for out of work electrons, I think that it might be best to wait and see what we (*) learn from JITs on other platforms, then use that to design a third generation JIT that is capable of mapping parrot registers onto hardware CPU registers. * Er, we is probably just Daniel as I confess I don't feel motivated to attempt to learn other assembly language to write JITs for hardware I don't own. Hey, all you Mac fans, where's the PPC JIT? ducks I'm working on it, as I'm working on the register allocator too. Daniel Grunblatt.
Re: ARM Jit v2
On Thu, 1 Aug 2002, Nicholas Clark wrote: Here goes. This *isn't* functional - it's the least amount of work I could get away with (before midnight) that gets the inner loop of mops.pasm JITted. Applied, many many thanks. including this judicious bit of cheating: because I need if_i_ic JITted but mops only needs backwards jumps (which are easy, and don't require me to write the fixup routine yet) We can wait, no problem. Daniel Grunblatt.
Re: On JITs and regexps (was several threads)
On Tue, 30 Jul 2002, Nicholas Clark wrote: On Tue, Jul 30, 2002 at 01:21:30PM -0400, Dan Sugalski wrote: At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote: On Mon, 29 Jul 2002, Nicholas Clark wrote: As you can see from the patch all it does is implement the end and noop ops. Everything else is being called. Interestingly, JITing like this is slower than computed goto: Yes, function calls are generally slower than computing a goto. Yup. There's the function preamble and postamble that get executed, which can slow things down relative to computed goto, which doesn't have to execute them. This brings up an interesting point. Should we consider making at least some of the smaller utility functions JITtable? Not the opcode functions, but things in string.c or pmc.c perhaps. (Or maybe getting them inlined would be sufficient for us) I'm not sure. Effectively we'd need to define them well enough that we can support n parallel implementations - 1 in C for everyone else, and 1 per JIT architecture. On Tue, Jul 30, 2002 at 03:14:48PM -0300, Daniel Grunblatt wrote: Yes, we can do that, we can also try to go in and out from the computed goto core if available. This sounds rather scary to me. We can try and see, I'm not 100% sure if this will be faster. I've managed to delete a message (I think by Simon Cozens) which said that perl5 used to have a good speed advantage over the competition, but they'd all been adding optimisations to their regexp engines (that we had already) and now they're as fast. My thoughts are: If on a particular platform we don't have a JIT implementation for a particular op then we have to JIT a call to that op's C implementation. Do enough of these (what proportion?) and the computed goto core is faster than the JIT. I think (I could look at the source code, but that would break a fine Usenet tradition) that for ops not in the computed goto core we have to make a call from either JIT or computed goto core, so there's no speed difference on them. *BUG* Also, we are currently failing to distinguish the size of INTVALs and NUMVALs in our JIT names (so this makes 4 possible JIT variants on most CPUs) IIRC there are currently 500 ops in the core, which makes it unlikely that we'll have sufficient people to JIT most ops on most CPUs. So we have the danger of the JIT being slower in the general case. Ok, I don't know if I should say this ... and I'm not saying I'm going to do it, but there is a possibility to make an intermediate language. Daniel Grunblatt.
Re: drive-by-reminder: missing JITs
On Tue, 30 Jul 2002, Jarkko Hietaniemi wrote: Nick Clark is working on ARM, but we are still missing at least the following importantish JIT implementations: * PPC - PowerPC (Motorola) and POWER (IBM) -- I know there's a common instruction set that works both on the consumer PPCs and the HPC (high performance computing) POWER chips. I'm working on this. * MIPS - I know a little bit more about these, but I *suspect there's a simple common instruction set * HPPA - I know very little about these, is there a common instruction set? * IA64 - reports of the IA64 instruction set tell that it combines the elegance of the IA32 CISCy instruction set with the elegance of the HPPA RISCy instruction set... :-) I intend to do nothing on these except raise gui^H^H^Hawareness :-) Or give me an acount? ;) Daniel Grunblatt.
Re: ARM Jit v2
Yes, we can do that, we can also try to go in and out from the computed goto core if available. Daniel Grunblatt. On Tue, 30 Jul 2002, Dan Sugalski wrote: At 10:34 PM -0300 7/29/02, Daniel Grunblatt wrote: On Mon, 29 Jul 2002, Nicholas Clark wrote: As you can see from the patch all it does is implement the end and noop ops. Everything else is being called. Interestingly, JITing like this is slower than computed goto: Yes, function calls are generally slower than computing a goto. Yup. There's the function preamble and postamble that get executed, which can slow things down relative to computed goto, which doesn't have to execute them. This brings up an interesting point. Should we consider making at least some of the smaller utility functions JITtable? Not the opcode functions, but things in string.c or pmc.c perhaps. (Or maybe getting them inlined would be sufficient for us) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Targeting Parrot slides
On Tue, 30 Jul 2002, Leon Brocard wrote: The slides for the talk I presented at the O'Reilly Open Source conference last week in Sad Diego are now available: http://www.astray.com/targeting_parrot/ Note that more Parrot talks are at http://www.parrotcode.org/talks/ FYI The conference went well and I'm sure Dan will get his slides up soon. BTW anyone want to work on getting Parrot to use less memory so it can run on palmtops? ;-) I'm told it will take much more than just reducing the memory it uses. Daniel Grunblatt. Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ Try? Try not. Do, or do not. There is no try
Re: of Mops, jit and perl6
On Sun, 28 Jul 2002, Leopold Toetsch wrote: [lt@thu8:~/src/parrot-007/examples/mops] $ perl mops.pl Iterations:1000 M op/s:2.22 (Iteration count for mops.pl was reduced, patch sent) Summary: Program Mops perl5.005_03 2.2 perl6 0.3 perl6 jit 1.1 parrot interpreted 18 parrot compiled 200 parrot jit363 plain c 366 Remarks: - jit is a lot faster then compiled - plain mops.c is only slightly faster the jit, i.e. 1% - perl6-jit, albeit still totally unoptimized, doesn't compare too bad to perl5 - mops is a silly test ;-) You didn't use -O3 while compiling mops.c, did you? Daniel Grunblatt.
Re: ARM Jit v2
On Mon, 29 Jul 2002, Nicholas Clark wrote: Here's a very minimal ARM jit framework. It does work (at least as far as passing all 10 t/op/basic.t subtests, and running mops.pbc) Cool, I have also been playing with ARM but your approach is in better shape. (I'll send you a copy of what I got here anyway because it's bit more documented and you might want to merge it). As you can see from the patch all it does is implement the end and noop ops. Everything else is being called. Interestingly, JITing like this is slower than computed goto: Yes, function calls are generally slower than computing a goto. I doubt in its current form this is quite ready to go in. Points I'd like to raise 0: I've only implemented generator code fully for 1 class of instructions (load/store multiple registers), partially for a second (load/store single registers, and hard coded the minimal set of other things I needed. I'll replaced these with fully featured versions, now that I'm happy that the concept works 1: The most optimal code I could think of to call external functions sets everything up by loading arguments into registers and function address into PC a single load multiple instruction. (plus setting the return address in the link register, by using the link register as the base register for the load). All that in 1 instruction, plus a second to prime LR for the load. (This is why I like it) However, this is the form of instruction that can trigger bugs on the (very early) K version StrongARMs. (if it page faults midway) Probably the rest of the world doesn't have these (unless they have machines dating from 1996 or so) but I do have one, so it is an important itch for me. ARM_K_BUG is a symbol to define to generate code that cannot cause the bug. 2: This code probably is the ARM assembler version of a JAPH, in that I've not actually found the need (yet) to use any branch instructions. They do exist! It's just that I find I can do it all so far with loads. :-) 3: The code as is issues casting warnings and 3 warnings about unprototyped functions. (which I think can be static) 4: I'd really like the type of the pointer for the native code to be machine chosen. char* isn't the most appropriate type for ARM code - all instructions are word sized (32 bits) and must all be word aligned, so I'd really like to be fabricating them in ints, and writing to an int* in one blat. 5: The symbol TESTING was so that I could #include jit_emit.h in a test C program to check my generator (by spitting a buffer out into a $file, and then disassembling it with objdump -b binary -m arm -D $file 6: ARMs with separate I and D caches need to sync them before running code. (else it all goes SEGV shaped with really really weird backtraces) I don't think there's any official Linux function wrapper round the ARM Linux syscal necessary to do this, hence the function with the inline assembler. I'm not sure if there is a better way to do this. [optional .s file in the architecture's jit directory, which the jit installer can copy if it finds?] 7: Debian define the archname on their perl as arm, whereas building from the source tree gets me armv4l (from uname) hence the substitution for armv[34]l? down to arm. I do have a machine with an ARM3 here (which I think would be armv2) but it is 14 years old, and doesn't currently have Linux on it (or a compiler for RISC OS, and I'm not feeling up to attempting a RISC OS port for parrot just to experiment with JITs) It's probably quite feasible to make the JIT work on everything back to the ARM2 (ARM1 was the prototype and I believe was never used in any hardware available outside Acorn, and IIRC all ARM1 doesn't have is the multiply instruction, so it could be done) Ofcourse I didn't even noticed about all those problem, I'm using TD's ARM. I'll start writing some real JIT ops over the next few days, although possibly only for the ops mops and life use :-) Yay!, the ARM will be the first one with string opcodes jitted, I'm looking forward to see if we get good speed up. [although I strongly suspect that JITting the ops the regexps compile down to would be the first real world JIT priority. How fast would perl6 regexps be with that?] Yes, that should be one of the priorities. Oh, and prepare an acceptable version of this patch once people decide what is acceptable Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
Re: ARM Jit v2
I thing I forgot to tell is that I also have added a constant pool which could be usefull for the ARM too, it's on my local tree,I don't know exactly when I'm going to finish it. Daniel Grunblatt.
Re: [perl #15401] [PATCH] Silence warnings on isxxxx() in debug.c
Applied, thanks. Daniel Grunblatt. On Tue, 23 Jul 2002, Andy Dougherty wrote: # New Ticket Created by Andy Dougherty # Please include the string: [perl #15401] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15401 This patch eliminates 69 warnings of the form debug.c:96: warning: subscript has type `char' from gcc-2.8.1 on Solaris 8. The is() functions take 'int' arguments (since they must operate either on characters or EOF). On Solaris 8, under the default compilation conditions for me with gcc, they are implemented as lookup-tables, with the 'character' used as the index. Hence normal type promotion isn't performed and the 'subscript has type char' warning gets issued. Eventually, parrot may have to face some of the same issues with the is() functions that perl5 did, and it may be appropriate to set up various isALPHA() etc. macros or functions. See perl5's handy.h, particularly the section starting with /* * Character classes. * * Unfortunately, the introduction of locales means that we * can't trust isupper(), etc. to tell the truth. And when * it comes to /\w+/ with tainting enabled, we *must* be able * to trust our character classes. * * Therefore, the default tests in the text of Perl will be * independent of locale. Any code that wants to depend on * the current locale will use the tests that begin with lc. */ This is probably not a big issue in debug.c, however, so the following should suffice for now.
Re: [perl #15335] [PATCH] little change to debug.c (print)
Applied, thanks. Daniel Grunblatt. On Mon, 22 Jul 2002, Aldo Calpini wrote: # New Ticket Created by Aldo Calpini # Please include the string: [perl #15335] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15335 this little patch changes the 'print' debugger command on PMC registers, so that it prints the PMC class next to the register number. eg. before the patch: (pdb) print p 0 PMC Registers: 0 = after the patch: (pdb) print p 0 PMC Registers: 0 = [PerlArray] cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; -- attachment 1 -- url: http://rt.perl.org/rt2/attach/30967/25957/89edff/debug_print_pmc.patch
Re: [PATCH] MANIFEST update
On Wed, 17 Jul 2002, Andy Dougherty wrote: The following patch brings the MANIFEST file up-to-date with recent additions. I haven't committed this in case some other reorganization (e.g. moving stuff to a src/ or dev/ or doc/ directory) is underway. There are also a few minor shuffles as I've re-sorted the MANIFEST. Andy Dougherty[EMAIL PROTECTED] Applied, thanks.
RE: [PATCH] rx.dev
We have one vote for docs/dev. Daniel Grunblatt. On Wed, 17 Jul 2002, Melvin Smith wrote: At 06:14 PM 7/16/2002 -0700, John Porter wrote: Melvin Smith wrote: I put it temporarily in the root dir, which I know is wrong. Where should .dev files go, anyway? Actually, I think that's right. ..dev files live alongside their .c/.h siblings, no? Hmm, looking at the source directory, I'm starting to think maybe that isn't so good, it is pretty busy already. We have one vote for a /dev directory. -Melvin
Re: [perl #15009] [PATCH] test for for loops
Applied.
Daniel Grunblatt.
On Wed, 17 Jul 2002, Sean O'Rourke wrote:
# New Ticket Created by Sean O'Rourke
# Please include the string: [perl #15009]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=15009
This file is intended to be languages/perl6/t/compiler/5.t. It tests
perl6-style for xs; yz - $x; $y, $z { ... } loops. Once a few
patches get into CVS, all 5 subtests should pass.
/s
-- attachment 1 --
url: http://bugs6.perl.org/rt2/attach/30027/25481/1fbd81/5.t
[COMMIT] The assembler doesn't use XS anymore.
The assembler doesn't use the XS stuff anymore, just committed a patch build from Jeff's code. Let's hope to see some more tinderboxes green. Daniel Grunblatt.
[COMMIT] KEY / KEY CONSTANTS
I just changed 'kc' to be an integer constant, because it was the simpliest way to make the warnings go away. If kc should be a string and k too, tell me. Daniel Grunblatt.
Re: [COMMIT] Parrot_Context
On Fri, 5 Jul 2002, Jerome Vouillon wrote: On Thu, Jul 04, 2002 at 05:08:25PM -0400, Melvin Smith wrote: and would also kill the current JIT design. Because it assumes there is only one interpreter ? No, it assumes that the addresses of the registers won't change during the execution of a given bytecode on a certain interpreter. It seems to me it would be just as efficient to keep the interpreter pointer in a register, instead of hardcoding the address of the interpreter. You mean a cpu register, right? If so, of course, but we just don't hardcode the address of the interpreter anywhere, and either way you will need to dereference it, and that's slower, leaves us with 1 less cpu register for the register allocation and requires a total redesing(what is of course the less important thing). Daniel Grunblatt.
Re: Stack and GC
On Fri, 21 Jun 2002, Jerome Vouillon wrote: On Thu, Jun 20, 2002 at 12:26:11AM -0400, Melvin Smith wrote: Given that it seems capturing and restoring a context is the most expensive part, should we make default routines lightweight (execute on caller stack rather than getting their own) and only make continuations and co-routines take most of the penalty? - Default routines should be lightweight. True. - Each co-routine should probably have its own interpreter. We should let programmers choose, not make this mandatory. -- Jerome
Re: .include directive for new assembler
It would be cute if you change the debugger to load all the included files as well. Daniel Grunblatt. On 21 Jun 2002, brian wheeler wrote: I've implemented a .include directive for the new assembler. It basically changes the preprocessor to shift through the source file, and when an include is found, the included file is unshifted to the beginning. Should I commit it? Of course. Brian
Re: .include directive for new assembler
Err, Jeff just told me to see the -E flag. Daniel Grunblatt. On Sat, 22 Jun 2002, Daniel Grunblatt wrote: It would be cute if you change the debugger to load all the included files as well. Daniel Grunblatt. On 21 Jun 2002, brian wheeler wrote: I've implemented a .include directive for the new assembler. It basically changes the preprocessor to shift through the source file, and when an include is found, the included file is unshifted to the beginning. Should I commit it? Of course. Brian
Re: [perl@gloudon.com: [PATCH] packfile reading]
On Wed, 12 Jun 2002, Jason Gloudon wrote: Could someone apply this ? - Forwarded message from Jason Gloudon [EMAIL PROTECTED] - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk Delivered-To: mailing list [EMAIL PROTECTED] Date: Mon, 10 Jun 2002 19:33:56 -0400 From: Jason Gloudon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PATCH] packfile reading User-Agent: Mutt/1.3.25i This fixes the problem with reading .pbc files on win32. Someone may want to write the code to do something useful with the results of stat() when mmap() is not being used. Applied, thanks.
Exceptions sample
Can you let me know if the way I think about exceptions is ok? Thanks, Daniel Grunblatt. set I0,0 set I8,10 try # User exception catch !WRONG_NUMBERS, PRINT_WRONG # Trying to catch an exception that was already catched. catch !NOT_SUCH_FILE, NEVER_MADE_IT print step 1 bsr DIV end_try # For machine generated code this should not be a problem and makes my life easier. # Catching an exception that (may be) was thrown but not catched. catch !NOT_OK, NK NEVER_MADE_IT: print not here end DIV: try # Predefined exception catch !DIVISION_BY_ZERO, RETHROW # The default handler dies, so I just wrap it. catch !NOT_SUCH_FILE, DISCARD print step #2 div I1,I8,I0 open P1,doesn't exists, end_try ret DISCARD: print step #4 ret RETHROW: print step #3 throw !NOT_OK throw !WRONG_NUMBERS ret NK: print step #5 end
Re: [netlabs #590] Can't Print the Sequence slash + zero
--- start of forwarded message --- Date: 7 Jun 2002 21:36:26 - From: Joe Yates (via RT) [EMAIL PROTECTED] Cc: recipient list not shown: ; Subject: Re: [netlabs #590] Ticket Resolved Message-Id: rt-590-3249.7.09000490638196@netlabs Dear Daniel, I hope I'm not being a pain. The response to my report was that This'll be fixed when we've got the Parrot IO support rolled out. Have you any idea how far down the line that's going to be? No, I got no idea, but the problem wasn't in the Parrot IO but in the assembler. Daniel Grunblatt.
Re: [PATCH] Re: Minimum perl version ?
+/* This clashes with 5.005_03's headers. */
+#define na(c) { \
+while(*c !isspace(*c)) \
+c++; \
+while(*c isspace(*c)) \
+c++; }
+
+
Because of the name, right? If so, I'll go and change it, because it's
being used from some other files.
When I first saw all those warnings I couldn't understand why, thank you.
Daniel Grunblatt.
Re: [Win32] jit.c broken
That was me, going to fix, sorry. Daniel Grunblatt. On Fri, 7 Jun 2002, Sebastian Bergmann wrote: jit.c(73) : error C2039: 'has_jit_op' : Ist kein Element von 'Parrot_jit_optimiz er_section' ./include\parrot/jit.h(50) : Siehe Deklaration von 'Parrot_jit_optimizer _section' jit.c(100) : error C2039: 'has_jit_op' : Ist kein Element von 'Parrot_jit_optimi zer_section' ./include\parrot/jit.h(50) : Siehe Deklaration von 'Parrot_jit_optimizer _section' jit.c(105) : error C2039: 'has_jit_op' : Ist kein Element von 'Parrot_jit_optimi zer_section' ./include\parrot/jit.h(50) : Siehe Deklaration von 'Parrot_jit_optimizer _section' NMAKE : fatal error U1077: 'cl' : Rueckgabe-Code '0x2' Stop. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: [netlabs #634] GC Bench: Linked-list for free header list[APPLIED]
On 29 May 2002, Mike Lambert wrote: # New Ticket Created by Mike Lambert # Please include the string: [netlabs #634] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=634 Peter recently submitted a patch to RT that uses a linked-list for free headers. Here are before and after results: before after gc_alloc_new 4.1559994.016 gc_alloc_reuse16.574 12.648002 gc_generations4.025 3.975001 gc_header_new 3.686 3.986 gc_header_reuse 5.5779994.175998 gc_waves_headers 3.8150023.595999 gc_waves_sizeable_data8.3830028.381999 gc_waves_sizeable_hdrs5.668 5.396999 We win on the header-intensive stuff. Not sure why it would be slower on the gc_header_new tests. My best guess is that we know are touching the contents of the buffer header, which we weren't doing before. And when we allocate a bunch of new headers, we have to explcitly free them all, which involves touching the first pointer of every buffer in that memory, as opposed to one pointer in the Parrot_allocated memory we used before. IMO, the gc_alloc_reuse and gc_header_reuse benchmarks more than outweigh gc_header_new. The portion of Peter's patch to do just this change is included below. Mike Lambert Applied, thanks.
Re: [netlabs #648] [PATCH] keyed ops renaming
# New Ticket Created by Simon Glover # Please include the string: [netlabs #648] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=648 The patch below renames the set_keyed and get_keyed ops simply to set, as Jeff suggested, as well as documenting them (slightly). It also adjusts the tests accordingly. All tests still pass. Simon Applied, thanks. (with a perl -p -i -e 's/[gs]et_keyed/set/' *.t first) Daniel Grunblatt.
Re: [netlabs #650] [PATCH] Assembler documentation tweaks
On 1 Jun 2002, Simon Glover wrote: # New Ticket Created by Simon Glover # Please include the string: [netlabs #650] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=650 A few small fixes to the assembler documentation. NB This patch assumes that my previous keyed ops renaming patch has been applied. Simon Applied, thanks.
Re: [netlabs #628] [PATCH] Make hash.c depend on parrot headers
On 27 May 2002, Peter Gibbs wrote: # New Ticket Created by Peter Gibbs # Please include the string: [netlabs #628] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=628 Following patch adds dependencies entry for hash.c to Makefile. Stops things from getting very confusing when changing layout of String and/or Buffer structs! -- Peter Gibbs EmKel Systems Applied, thanks.
Re: [netlabs #627] Parrot Debugger Disassembler
Now I attached all the files :) I also added now the target disassemble, it will emit on stdout the disassemble of a pbc, this output is (should be) ready to assemble. (it might have some issues with strings). Daniel Grunblatt. On 27 May 2002, Daniel Grunblatt wrote: # New Ticket Created by Daniel Grunblatt # Please include the string: [netlabs #627] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=627 While making the Parrot compiler I note that it's quite complicated to debug a Parrot program, so I made this Parrot debugger, it can be used in 2 ways: * ./pdb programfile (make pdb first) * using the ops in debug.ops (debug_init,debug_load and debug_break) You can use the command 'disassemble' if you don't have the pasm, list the source, set breakpoints, watch the registers and the stack, etc. Still todo: * check the user input for bad commands, it's quite easy to make it bang now, try listing the source before loading or disassembling it. * Print the interpreter info. * Make the user interface better (add comands history/completition). * Some other things I don't remember now because it's late. Enjoy, Daniel Grunblatt. debug.tgz Description: Binary data
Re: GC Benchmarking Tests
On Wed, 29 May 2002, Mike Lambert wrote: Hey all, After finding out that life.pasm only does maybe 1KB per collection, and Sean reminding me that there's more to GC than life, I decided to create some pasm files testing specific behaviors. Attached is what I've been using to test and compare running times for different GC systems. It's given a list of builds of parrot, a list of tests to run, and runs each four times and takes the sum of them as the value for that test. Then it prints out a simple table for comparing the results. It's not really robust or easily workable in a CVS checkout (since it operates on multiple parrot checkouts). Included are five tests of certain memory behaviors. They are: gc_alloc_new.pbc allocates more and more memory checks collection speed, and the ability to grow the heap gc_alloc_reuse.pbc allocates more memory, but discards the old checks collection speed, and the ability to reclaim the heap gc_header_new.pbc allocates more and more headers checks DOD speed, and the ability to allocate new headers gc_header_reuse.pbc allocates more headers, but discards the old checks DOD speed, and the ability to pick up old headers gc_waves_headers.pbc total headers (contain no data) allocated is wave-like no data, so collection is not tested tests ability to handle wavelike header usage pattersn gc_waves_sizeable_data.pbc buffer data (pointed to by some headers) is wave-like a few headers, so some DOD is tested mainly tests ability to handle wavelike buffer usage patterns gc_waves_sizeable_headers.pbc total headers (and some memory) allocated is wave-like sort of a combination of the previous two each header points to some data, so it tests the collectors ability to handle changing header and small-sized memory usage gc_generations.pbc me trying to simulate behavior which should perform exceptionally well under a genertaional collector, even though we don't have one :) each memory allocation lasts either a long time, a medium time, or a short time Please let me know if there are any other specific behaviors which could use benchmarking to help compare every aspect of our GCs? Real-world programs are too hard to come by. :) Results of the above test suite on my machine comparing my local GC work and the current parrot GC are coming soon... Enjoy! Mike Lambert PS: If you get bouncing emails from me because my email server is down, I apologize, and I do know about it. My email server is behind cox's firewall which prevents port 25 access. It should be relocated and online again in a few days. Committed all the .pasm under examples/benchmarks/ , thanks.
Re: [netlabs #626] [PATCH] reclaimed fix [APPLIED]
On 26 May 2002, Mike Lambert wrote: # New Ticket Created by Mike Lambert # Please include the string: [netlabs #626] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=626 Looksd like the logic for keeping track of unclaimed buffer data missed a few places. Patch below. Applied, thanks.
Re: JIT ideas
On Fri, 24 May 2002, Aldo Calpini wrote:
but I found another use for the emit_call_abs() function to implement some
string stuff in JIT. as I already said, the speed increase isn't at all
dramatic, but OTOH I have no idea how to do complicate stuff like allocating
memory natively in asm. these are the string ops that I've implemented in
There are some ways to do that but we're not going to use any of them, to
allocate memory you can call mem_sys_allocate(), so if you jit the whole
string api even calling it there will be a big win.
I haven't made extensive testing, but it seems there's a gain of about 10
generations per second with the lifetest. if these changes are welcome, I
will submit a (hopefully proper ;-) patch including other string stuff too.
Great, send it, just make sure to mark all the ops that make a call to a C
function like this:
extern Parrot_concat_s_s_s {
Regards,
Daniel Grunblatt.
Re: [netlabs #619] [PATCH] [REPOST corrected] Memory manager/garbagecollector speedup (sometimes) [APPLIED]
On Fri, 24 May 2002, Peter Gibbs wrote: I managed to send the wrong version of the patch on the previous post! Herewith the correct (I hope) one. Apologies to all. -- Peter Gibbs EmKel Systems Applied, thanks.
Re: [netlabs #620] [PATCH] io.ops : add fdopen
The patch made it to the RT what is enough. Daniel Grunblatt. On 24 May 2002, Tony Payne wrote: Hmm.. patch didn't make it. On Fri, 2002-05-24 at 08:51, Tony Payne wrote: # New Ticket Created by Tony Payne # Please include the string: [netlabs #620] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=620 Here's a patch to add fdopen to io.ops. It's my first parrot patch, so I decided to start tiny. Please let me know if this is appropriate/acceptable. Thanks, ++t
Re: LZW in pasm
On Wed, 22 May 2002, Sean O'Rourke wrote: This is an implementation of LZW compression in Parrot assembly. The fact that pack() can't handle null bytes makes it a bit more complicated (and limited) than it has to be, but for just text files, it seems to work just fine. It's probably a decent stress test for the hash PMC, but especially Exactly how do you want it to handle null bytes? Daniel Grunblatt.
Re: JIT ideas
On Thu, 23 May 2002, Aldo Calpini wrote:
hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode does. it just saves some
push/pop/call/ret instructions. the advantage is that such hack is
portable across platform. implementing a more low-level print
mechanism (involving system calls probably) would require several
#ifdef..#endif, I suppose.
anyway, this implements a new function in jit_emit.h which makes
a call to a C function (an absolute address, that is). this is the
function I've added to jit_emit.h:
void emit_call_abs(Parrot_jit_info *jit_info,
long absaddr, int putback)
{
Parrot_jit_newfixup(jit_info);
jit_info-fixups-type = JIT_X86CALL;
jit_info-fixups-param.fptr = (void (*)(void)) absaddr;
emitm_calll(jit_info-native_ptr, 0xdeafc0de);
emitm_addl_i_r(jit_info-native_ptr, putback, emit_ESP);
}
this is very similar to Parrot_jit_normal_op, except that the
address is stored 'as it is' and the bytes to be added to ESP are
variable.
and this is how print_ic is implemented in core.jit:
Parrot_print_ic {
emitm_pushl_i(NATIVECODE, *INT_CONST[1]);
emitm_pushl_i(NATIVECODE, (long) INTVAL_FMT);
emit_call_abs(jit_info, (long) printf, 8);
}
print_nc looks like this (I needed to define a private long because
simply saying (NUM_CONST[1])+4 doesn't work):
Parrot_print_nc {
long mydouble = (long) NUM_CONST[1];
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, mydouble+4);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, mydouble);
emitm_pushl_i(NATIVECODE, (long) FLOATVAL_FMT);
emit_call_abs(jit_info, (long) printf, 12);
}
also print_sc is similar, except that there isn't a STRINGVAL_FMT
defined in config.h:
Parrot_print_sc {
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, (long) STRING_CONST[1]-bufstart);
emitm_pushl_i(NATIVECODE, (long) %s);
emit_call_abs(jit_info, (long) printf, 8);
}
Don't implement any print op yet, if I didn't understood wrong they are
going to be updated to use the IO system.
another little thing I've done, but I'm not sure if there's need
for this, is having added these lines to jit.c in the build_asm
routine, just before returning:
if (Interp_flags_TEST(interpreter, PARROT_DEBUG_FLAG)) {
fprintf(stderr, *** Parrot VM: JITted code at 0x%08x. ***\n,
jit_info.arena_start);
}
this way when I start 'parrot -j -d something' it tells me where
to find the JIT, and I can goto there directly in the debugger.
it's really a time saver for me.
The -d flag will be use for the parrot debugger, Can't you stop your
debugger at runops_jit?
Daniel Grunblatt.
Re: LZW in pasm
I prefer it to work like this: set S0, set IO,42 pack S0, 4, I0 ,0 length I1, S0 # is 4 pack S0, 4, I0 length I1, S0 # is 8 pack S0, 4, I0, 1 # no segv :) length I1, S0 # is 10004 Patch is already applied. Daniel Grunblatt. On Thu, 23 May 2002, Sean O'Rourke wrote: On Thu, 23 May 2002, Daniel Grunblatt wrote: On Wed, 22 May 2002, Sean O'Rourke wrote: that pack() can't handle null bytes makes it a bit more complicated (and Exactly how do you want it to handle null bytes? Nevermind -- sorry 'bout that. There's a little wierdness in there, but it isn't because of nulls -- I just spaced out reading the pack docs. The strangeness is with the 4-argument version of pack(), which doesn't extend its first argument if the pack destination goes past the end of the string. So you get this: set S0, set I0, 42 pack S0, 4, I0, 0 length I1, S0 # is 0 pack S0, 4, I0 length I1, S0 # is 4 pack S0, 4, I0, 1 # is segv which is completely unrelated to nulls, but still strange. I was thrown off by this result when trying to use the offset version of pack. I attached a patch that (I think) does something with less startle value. /s
Re: PATCHES
On Wed, 24 Apr 2002, Daniel Grunblatt wrote: Folks, From now on, please every time you want to send a patch send it to [EMAIL PROTECTED] so that we can keep track of it and it doesn't get lost in space. Thanks. Daniel Grunblatt. And, please: 1 - Try to send the patch as an attachment, sometimes it's too difficult to apply if you don't. 2 - 'diff -u' blinkI S Y O U R F R I E N D/blink :) Daniel Grunblatt.
Re: [netlabs #610] hash re-adjustment problem (with patch) [APPLIED]
On 22 May 2002, Sean O'Rourke (via RT) wrote: # New Ticket Created by Sean O'Rourke # Please include the string: [netlabs #610] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=610 I believe there is a bug in how the perlhash pmc adjusts its buckets after reallocation. When the allocator hands it a new piece of memory that is aligned differently with respect to sizeof(HASHBUCKET) boundaries (32 bytes on linux-ppc), it will adjust pointers by a multiple of sizeof(HASHBUCKET), causing wierd segfaults. I believe the included patch fixes it. I didn't look for similar issues elsewhere, but the tests all seem to run now. Applied, thanks.
[COMMIT] JIT v2
Folks, Yesterday I checked in the new JIT from Jason Gloudon. Now it does NOT depend on an external assembler and disassembler but instead uses some macros. All tests succesful. The size of the executable have been reduced by ~700K. It should work on most x86/sparc/alpha systems. Jason, Excellent work. Regards, Daniel Grunblatt.
