Re: [perl #21033] [PATCH] Macro support for imcc

2003-02-16 Thread Leopold Toetsch
Nicholas Clark wrote: Does the -a flag on imcc mean that we can run without the macros, and hence run faster? No, the -a option turns on PASM parsing, where macros are enabled. Normally imcc selects the mode with the file extension (.pasm/.imc/.pbc), but when input is coming from STDIN, the

Re: [perl #21033] [PATCH] Macro support for imcc

2003-02-16 Thread Juergen Boemmels
Nicholas Clark <[EMAIL PROTECTED]> writes: > On Sat, Feb 15, 2003 at 12:10:11PM -0500, Dan Sugalski wrote: > > I'd half-wondered if this would ever come up. > > > > Back in the beginning we decided that, while the assembler would > > support macros (over some disagreement) since it was an end-use

Re: [perl #21033] [PATCH] Macro support for imcc

2003-02-16 Thread Juergen Boemmels
Leopold Toetsch <[EMAIL PROTECTED]> writes: > > I just implemented macro expansion in imcc. > > This brings us one step closer to substitude assemble.pl > > ... and additionally adds a nice benefit: > > $ time perl t/harness quick > real0m36.452s > user0m25.170s > sys 0m7.560s > > $

Re: [perl #21033] [PATCH] Macro support for imcc

2003-02-16 Thread Nicholas Clark
On Sun, Feb 16, 2003 at 06:54:28PM +0100, Juergen Boemmels wrote: > Nicholas Clark <[EMAIL PROTECTED]> writes: > > > On Sat, Feb 15, 2003 at 12:10:11PM -0500, Dan Sugalski wrote: > > > I'd half-wondered if this would ever come up. > > > > > > Back in the beginning we decided that, while the assem

Re: [perl #21033] [PATCH] Macro support for imcc

2003-02-16 Thread Juergen Boemmels
Nicholas Clark <[EMAIL PROTECTED]> writes: [...] > You're going to hate me - I think I've got a source tree somewhere where I > did get it to run on 5.005. I certainly had a good go at it. If you asked > about this on list and I missed it, sorry. I had the much simpler solution of just installin

Re: benchmarking - it's now all(-1,0,1,5,6)% faster

2003-02-16 Thread Nicholas Clark
On Tue, Feb 11, 2003 at 09:24:21AM +0100, A. Bergman wrote: > > On måndag, feb 10, 2003, at 23:03 Europe/Stockholm, > [EMAIL PROTECTED] wrote: I've never heard myself called that before :-) > >This is probably the right default for the general case, but it is > >counterproductive for benchmarki

Re: Segfault in substr_s_ic_ic_sc op

2003-02-16 Thread Simon Glover
On Sat, 15 Feb 2003 [EMAIL PROTECTED] wrote: > I've been tinkering with the queens.jako example, trying to make it work > with strings > instead of bit fields. Along the way, I had a parrot segfault aparently > due to substr > and a (null) string register. Its probably my fault such a call was be