search for: disassemblert

Hi All, I have faced decoding conflict of DisassemblerTables from TableGen. I have instructions with same encoding and different mnemonic among different architecture versions. I have used Predicates and AssemblerPredicates to distinguish them on Codegen and Assembler but it does not work on Disassembler. When I look at TableGen/FixedLenDecoderEmitter.c...

...enter.h (revision 0) @@ -0,0 +1,72 @@ +//===- Indenter.h - Output indenter -----------------------------*- C+ + -*-===// I'm not a big fan of manipulators like this (as David Greene can tell you ;-). I just added a new raw_ostream::indent method, so now instead of stuff like this: +void DisassemblerTables::emitContextDecision( + std::ostream& o2, + Indenter& i2, ... + o2 << i2.indent() << "struct ContextDecision " << name << " = {" << std::endl; + i2.push(); + o2 << i2.indent() << "{ /* opcodeDecisions */" &...

..._unreachable()" macro as well. 12. You use "std::endl" a lot. This is discouraged by the coding standard: http://llvm.org/docs/CodingStandards.html#ll_avoidendl 13. You use "std::ostream" a lot. Would it be appropriate to use "raw_ostream" instead? 14. In DisassemblerTables::setTableFields, you emit things to "std::cerr". Use "errs()" instead. Or, better yet, "llvm_report_error". :-) 15. Prefer pre-increment/decrement for variables: http://llvm.org/docs/CodingStandards.html#micro_preincrement 16. In X86RecognizableInsn.cpp, y...

...assembler.h is not a good candidate for this, because the number of instructions could potentially be quite large. - numberedInstructions in X86DisassemblerEmitter.cpp is not a good candidate because there are upwards of a thousand instructions in the x86 table. - fInstructionSpecifiers in X86DisassemblerTables.h is not a good candidate either... the number is (again) very large. - fOperands is not a good candidate because is never actually created. It is always set to point to CodeGenInstruction::OperandList. > 8. While we're on that, please use "Instruction" or "Instr&qu...

Dear mailing list: the attached diff implements a table-driven disassembler for the X86 architecture (16-, 32-, and 64-bit incarnations), integrated into the MC framework. The disassembler is table-driven, using a custom TableGen backend to generate hierarchical tables optimized for fast decode. The disassembler consumes MemoryObjects and produces arrays of MCInsts, adhering to the

I believe I have now fixed the 0x64 0xa1 0x00 0x00 0x00 0x00 bug in r199364. On Wed, Jan 15, 2014 at 10:53 AM, Craig Topper <craig.topper at gmail.com>wrote: > To fix it we need to change offset8/offset16/etc to have two suboperands > and update the printer to understand that. Also update the disassembler to > add the segment to the MCInst when its creating it. When I did these

I don't think changing to VEX_4VOp3 to VEX_4V is the right fix. I think the fix is to increment CurOp twice at the start for these instructions so that only the input operands are used for encoding. Also, I just submitted a patch to revert the operand order for these instructions in the assembler/disassembler. Destination register should appear on the right and the mask should appear on the

Yes, there is an easy way to fix this. MRMSrcMem assumes register, memory, vvvv register if VEX_4VOp3 is true and assumes register, vvvv register, memory if VEX_4V is true. I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few places where we assume only the 2nd operand can be tied-to: Desc->getOperandConstraint(1, MCOI::TIED_TO) != -1 (hard-coded index 1) I will fix those