Re: OpsFile hints - one more (perlish) task
I've been all over the ops2c system recently filling in the
documentation (it'll get committed this weekend sometime) so number 2
is something I can certainly do.
BTW is there a reason for the colon at the start of the hints?
Mike
On 27 Mar 2004, at 08:15, Leopold Toetsch wrote:
Opcodes normally have a specifier that indicates, if a register is
written to or only used, e.g.
null (out PMC)
An Cout register gets a new value at that point, the register
allocator can reuse this register because the old contents got
discarded. This information is necessary for the register allocator.
Now we have some opcodes, that implicitely set new values on a range
of registers or silently use a register (it has to exist).
clearp # set P0..P31 to PMCNULL
poptopi # set I16..I31 from I register stack
callmethod # use existing P0, P2, S0
callmethodcc # use existing P0, P2, S0, create new P1
There are currently some hacks inside imcc[1], to handle some of these
opcodes but opcodes change faster then the code, so I'd rather have
this autogenerated from e.g.:
op clearp () :base_core,out=P0-P31
op callmethodcc :object_base,in=P0,P2,S0,I0-I4,out=P1,I0-I4
I'm not sure yet, if register stack store operations do need a hint:
pushbottomp# doesn't care if a register is valid or not
OTOH the equivalent pop definitely sets all P0..P15.
So that's part one - annotate the opsfiles.
2) is parse this information and generate bitmasks for the
Cop_info_t structure defined in Finclude/parrot/op.h.
That would be something like:
int {in,out}_{I,S,P,N}_argdir; # 1 bit per register per in/out
per kind
Thanks,
leo
[1] s. imcc/instructions.c: 87 ff
Re: OpsFile hints - one more (perlish) task
Michael Scott [EMAIL PROTECTED] wrote: I've been all over the ops2c system recently filling in the documentation (it'll get committed this weekend sometime) so number 2 is something I can certainly do. Great, thanks BTW is there a reason for the colon at the start of the hints? Hysterically yes, s. perldoc Opcode. If Ponie ever needs it, we have some syntax for opcode classes. Mike leo
OpsFile hints - one more (perlish) task
Opcodes normally have a specifier that indicates, if a register is
written to or only used, e.g.
null (out PMC)
An Cout register gets a new value at that point, the register
allocator can reuse this register because the old contents got
discarded. This information is necessary for the register allocator.
Now we have some opcodes, that implicitely set new values on a range of
registers or silently use a register (it has to exist).
clearp # set P0..P31 to PMCNULL
poptopi # set I16..I31 from I register stack
callmethod # use existing P0, P2, S0
callmethodcc # use existing P0, P2, S0, create new P1
There are currently some hacks inside imcc[1], to handle some of these
opcodes but opcodes change faster then the code, so I'd rather have this
autogenerated from e.g.:
op clearp () :base_core,out=P0-P31
op callmethodcc :object_base,in=P0,P2,S0,I0-I4,out=P1,I0-I4
I'm not sure yet, if register stack store operations do need a hint:
pushbottomp# doesn't care if a register is valid or not
OTOH the equivalent pop definitely sets all P0..P15.
So that's part one - annotate the opsfiles.
2) is parse this information and generate bitmasks for the Cop_info_t
structure defined in Finclude/parrot/op.h.
That would be something like:
int {in,out}_{I,S,P,N}_argdir; # 1 bit per register per in/out
per kind
Thanks,
leo
[1] s. imcc/instructions.c: 87 ff
