Re: core.ops ARGDIR
Angel Faus wrote: > Hi Leo, > > >>This should be - from my (imcc) POV - reflected by these IN/OUT >>settings: >> >>op set(in PMC, in INT) >>op set(in PMC, in STR) >>op set(in PMC, in NUM) >>op set(out PMC, in PMC) # ok, $1 points to $2 now >> >># P[i] = x >>op set(in PMC, in intkey, in x) >># P[KEY] = x >>op set(in PMC, in KEY, in x) >># p[KEY] = P[KEY] >>op set(in PMC, in KEY, in PMC, in KEY) > Shouldn't all this PMC be "inout"? They depend on the previous value > of the PMC, but they also modify it. inout would be ok for me. set Px, Py is probably the only instruction, where $1 is OUT. (ev. assign, but I didn't look at this close enough). > This probably doesn't affect imcc now, but it might be useful in the > future. It does affect imcc (CVS as well as my upcoming patch). Currently there is a würgaround (workaround) in the code. Have a look at e.g. iMOVE(). > -angel leo
Re: core.ops ARGDIR
Hi Leo, > > This should be - from my (imcc) POV - reflected by these IN/OUT > settings: > > op set(in PMC, in INT) > op set(in PMC, in STR) > op set(in PMC, in NUM) > op set(out PMC, in PMC) # ok, $1 points to $2 now > > # P[i] = x > op set(in PMC, in intkey, in x) > # P[KEY] = x > op set(in PMC, in KEY, in x) > # p[KEY] = P[KEY] > op set(in PMC, in KEY, in PMC, in KEY) > Shouldn't all this PMC be "inout"? They depend on the previous value of the PMC, but they also modify it. This probably doesn't affect imcc now, but it might be useful in the future. -angel
Re: core.ops ARGDIR
On Mon, Sep 02, 2002 at 09:49:25PM +0200, Leopold Toetsch wrote: > > This should be - from my (imcc) POV - reflected by these IN/OUT settings: > > op set(in PMC, in INT) > op set(in PMC, in STR) > op set(in PMC, in NUM) > op set(out PMC, in PMC) # ok, $1 points to $2 now Thinking about it, that actually seems correct. This alternative seems wrong: op set(inout PMC, in INT) op set(inout PMC, in STR) op set(inout PMC, in NUM) op set(out PMC, in PMC) # ok, $1 points to $2 now because I'm assuming that the input PMC register for the first three is unchanged. Or can there be situations where an assignment to a PMC changes the value of the register itself? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
core.ops ARGDIR
Hi all, I would like to discuss the intended meaning of ARGDIR_IN/OUT in core.ops (core_ops.c). s. also #16838 and #16895 imcc uses the IN/OUT information for determining the life status of a symbol, which is the base for register allocation, so it's crucial. The meaning in imcc is like: IN ... register is read, (or exists) OUT ... register is written to, i.e. starts a new life cycle when we have a op sequence: 1 set I0, 5 # I0 is alive 2 set I1, I0 # here too, gets read 3 set $I55, $I56 # no use of I0 here N-1 ... # but some temps need a register N set I0, 6 # I0 starts a new life here then - I0 is alive at [1,2] and at [N,..] because it's not read again after 2 and in N, it start's a new life cylce. So the register allocator may use the register I0 between 3 and N-1 for allocation of other temporary variables, which need a register. So similar example with PMCs 1 new P0, .PerlUndef # start life of P0 2 set P0, 5 # call P0's vtable->set_integer_native(5)... 3 ... # no set P0, Py here N-1 ... # no new P0, xx here N set P0, 6 # call same's PO set_integer_native(6) so P0 is alive in the whole instruction sequence [1,N], and may not be used in between. This should be - from my (imcc) POV - reflected by these IN/OUT settings: op set(in PMC, in INT) op set(in PMC, in STR) op set(in PMC, in NUM) op set(out PMC, in PMC) # ok, $1 points to $2 now # P[i] = x op set(in PMC, in intkey, in x) # P[KEY] = x op set(in PMC, in KEY, in x) # p[KEY] = P[KEY] op set(in PMC, in KEY, in PMC, in KEY) Actually current imcc overrides core.ops with these opterations and changes them to "in", and does fail, when core.ops is regarded for these operations and "out" is used. The only other usage of this ARGDIR info is in JIT, where I really, don't know, how (if even for PMCs) it's used there. Comments welcome, TIA leo
