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 ClarkThread Previous | Thread Next