<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>I have included Chris's previous comments below.<br><div><br><div><div>On Aug 22, 2009, at 4:31 PM, Chris Lattner wrote:</div><blockquote type="cite"><div>The MCDisassembler API is also somewhat strange to me. Right now it is designed to analyze a memory region when constructed and contain them. It seems that there is a more useful low level API which would look something like this:<br><br>class MCDisassembler {<br>public:<br><br> virtual ~MCDisassembler();<br><br> /// DisassembleInstruction - Disassemble the first instruction in the specified region, printing the disassembled instruction to the specified raw_ostream, and returning the size of the instruction in bytes. On error, this returns zero and fills in ErrorInfo with a human readable description of the error.<br> virtual unsigned DisassembleInstruction(MemoryObject ®ion, raw_ostream &OS, std::string &ErrorInfo) = 0;<br><br>}<br><br>Having this sort of stateless API means that higher level clients (which are stateful) can be built on top of them without adding overhead to clients who don't care about the state.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><blockquote type="cite"><div>Instead of doing something like this, the X86 disassembler should register itself as part of the "Target" API the same way that asmprinters, MCAsmInfo, targets, etc do. The X86 specific disassembler should go in lib/Target/X86/Disassembler. Take a look at how the Target/X86/AsmParser stuff registers itself for a good example.<br></div></blockquote></div><br></div></div></body></html>