On Thu, Sep 05, 2002 at 08:15:28AM -0400, Dan Sugalski wrote: > At 1:28 PM +0200 9/5/02, Leopold Toetsch wrote: > >Dan Sugalski (via RT) wrote: > > > >We need to nail down what the directions mean. > > > > > >This is, what I'm trying to do since quite a time. > > > >... The IMCC and JIT folks are the ones that care here. > > > >Here is the IMCC folks speaking ;-) > > Sorry. I've been pathetically behind in my p6i mail lately. > > If in means no change, inout means register is the same but the > string/pmc may have mutated itself, and out means the register is > changed, then I'm cool with it. Go ahead and commit the patch.
I believe applying the patch is the right thing, because it's progress on where we are, but I think (not fully formed yet) that we would benefit from finer granularity on what can get modified > Do be aware that *reading* from a PMC can potentially alter it, so: > > add inout P1, in P2, in P3 > > isn't necessarily a safe thing to assume. This is the "does a 'const' method mean that the memory representation of an object does not change, or only that the publicly accessible representation is unchanged" question, isn't it? [IIRC the question at one time was whether a const method in C++ could change the underlying object, providing the values returned by all public methods would not change as a result] The upshot of my thoughts is that I believe that the ops would benefit from having out (if not in as well) being broken down into (at least) 1: the value in the register did/didn't change 2: the value of the thing referenced by the register did/didn't change (possibly 2a and 2b being that the internals of the object didn't/might've changed) So then JITs, imcc and other things would know the difference between what these two do add inout_val P1, in P2, in P3 set out_reg P1, in P2 Nicholas Clark
