------- Additional Comments From shap at eros-os dot com 2007-12-08 02:27 ------- Hmm. Thank you for pointing that out.
Actually, M68000PRM specifies that if that field is 0 then the operation is a no-op. While the encoding is hypothetically legal, the definition of the assembly language syntax for caches on page 3-3 does not define any syntax for legally specifying that the no-op was the intended cache. On the whole, I'm inclined to think that any instruction actually specifying this field as zero is a bug, and doing something clever in the disassembler here may not be called for. The worst that will happen is that an instruction that shouldn't have been specifiable in legal assembly input will decode as INTOUCH in the disassembler. In all honesty I prefer your approach, but I'm not clear how to express it within the mechanisms of the current opcode tables. Also, I'm not clear (that is: I do not know) whether the object file format provides sufficient information to know what the target CPU was at dissassembly time. If it does not, then I think it's better to allow the syntactically invalid M68000 instruction to decode as INTOUCH. Opinion? -- http://sourceware.org/bugzilla/show_bug.cgi?id=5457 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
