search for: handle_operand

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

...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, you use the large macro: HANDLE_OPERAND. Could you make it an inlined function instead? It could take a pointer to a member function for the method it wants to call. Debugging large macros is impossible. :) 17. I'm confused by the C files in lib/Target/X86. Why aren't they C++ files? Okay. That's all I found for now....

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

...t, > "llvm_report_error". :-) Fixed to use errs(). > 15. Prefer pre-increment/decrement for variables: > > http://llvm.org/docs/CodingStandards.html#micro_preincrement Learned a new one there. Thanks! > 16. In X86RecognizableInsn.cpp, you use the large macro: > HANDLE_OPERAND. Could you make it an inlined function instead? It > could take a pointer to a member function for the method it wants to > call. Debugging large macros is impossible. :) I factored the code out into a function. There are still macros to keep things pretty, but they just wrap the func...