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