>>>>> "RG-S" == Rafael Garcia-Suarez <rgarciasuarez@free.fr> writes: RG-S> op_seq seems to be used only as a flag : "has this OP been RG-S> optimized by now" ... RG-S> So we could theorically replace op_seq by two boolean flags, as RG-S> far as the core and the bytecode compiler backend are concerned. PJ> I use it in Devel::Cover in conjunction with the address of the op PJ> in order to (almost) uniquely identify the op. Without this when PJ> ops get freed and the address is reused they cannot be told apart. PJ> I believe that Devel::Dprof also suffers from this problem, though PJ> maybe there is a better solution. I wonder how well a <address, checksum of all the OP's fields> pair would work. Not perfectly, in theory, but neither does op_seq, in theory, because of wrap-around. RG-S> B::Concise also uses it to identify ops. B::Concise's use could be replaced, though, and it would probably be a net improvement. We could just make another pass, and fill in a hash table mapping OP addresses to sequence numbers of our own devising (or <address, checksum> pairs, if it's important for B::Concise's output to be consistent over time as OPs are reallocated, which doesn't happen much in my use of it). This would avoid the ugly hack that we currently have to do to find the base of the sequence numbers we're using. If someone is feeling a bit ambitious, I think replacing op_seq with a few flags could be a significant win. Assuming it's only 2 bits, and recalling that op_type only needs 9 bits, I think we could squeeze op_type, op_seq, op_flags and op_private into 32 bits with some space left over. Assuming fields are naturally aligned, I think this would save a word per OP on most platforms, and OP flags are a high-demand resource it would be nice to have more of. -- StephenThread Previous | Thread Next