#28 [2.1 release] resolving pseudo operands

[Brian Mokrzycki]

I believe i've run into an issue in the way ArchC tries to resolve pseudo ops to op_userdef operand_types. As a simple example I have the following in my ISA description.

....

ac_asm_map reg {
"r"[0..31] = [32..63]
}

ac_asm_map freg {
"f"[0..31] = [0..31]
}

fadd.set_asm("fadd %freg, %freg, %freg", rz, rx, ry);

pseudo_instr("fsub %freg, %freg, -%freg") {
"fadd %0, %1, %2";
}
....

When generating the opcodes.table using bmdsfg the opcode.table that is generate selects the wrong operand id for the user defined freg type. Basically because the matching algorithm found in get_compatible_oper_id only matches on operand_type rather than operand_type & operand string, it matches the to the first operand in the global operand_list that matches only the operand_type, which happens to be type "reg" not "freg". The offending code can be found in acbinutils/opcodes.c

I plan on changing this function to match on both operand_type & operand string, in additional I believe this function should also have state information so that each operand in the pseudo instruction doesn't return with the same value. This is how non-pseudo instructions are resolved. I'm not sure why this is the case, perhaps it has something to do with processor modeling?

Cheers,

-Brian

[Brian Mokrzycki]

I modified to code to work the way I think it's supposed to work. Take a look that the patch for this. BTW, it would be nice if the code was posted and maintained in sf.net SVN server. The only think in there is a README...

[Brian Mokrzycki]

Patch to src/acbinutils/opcodes.c