develooper Front page | perl.perl5.porters | Postings from February 2004

Re: op_seq (was: Freeing code)

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
February 23, 2004 06:34
Subject:
Re: op_seq (was: Freeing code)
Message ID:
20040223143401.GL46380@plum.flirble.org
On Sat, Feb 21, 2004 at 02:31:47AM +0100, Paul Johnson wrote:
> Here's something I've had on my TODO list for slightly over a year.  I
> sent a test patch last year, fishing for comments, but no one bit.  So
> here's the real thing.
> 
> op_seq uses sixteen bits, as does op_type.  op_seq only needs to hold
> three states, and op_type only needs nine bits.  This means that we
> could store all the information we need in eleven bits, save sixteen
> bits per op and still have five bits spare for future use.

You don't mention in this summary that your patch then (appears to) use that
saved space for:

+ *	op_opt		Whether or not the op has been optimised by the
+ *			peephole optimiser.
+ *	op_static	Whether or not the op is statically defined.
+                *	This flag is used by the B::C compiler backend
+                *	and indicates that the op should not be freed.

Which confuses me because then you report:

> The attached patch does just that.  All the tests still pass on my i386
> linux box and the memory requirements of the following program are
> reduced by almost 2.5%.

This is good. There won't be memory reduction on any platform which requires
structs containing 4 byte values to be 4 byte aligned, so it's not going to
be a universal saving.

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About