Displaying 3 results from an estimated 3 matches for "stringmemoryobject".
2009 Aug 18
0
[LLVMdev] X86 Disassembler
...t64_t". Is there a good reason for this? If not, please change
them back.
4. If you have a class that's completely contained within a .cpp file,
go ahead and define it in an anonymous namespace and mark it
"VISIBILITY_HIDDEN". Like this:
namespace {
class VISIBILITY_HIDDEN StringMemoryObject : public MemoryObject {
...
5. In "readBytes" in StringMemoryObject, you're returning a "-1", but
the method's return type is "uint64_t". Do you *really* want to return
0xfffffffffffU, or is "-1" a sentinel value of some sort? If the
latter, pe...
2009 Aug 18
2
[LLVMdev] X86 Disassembler
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
2009 Aug 19
3
[LLVMdev] X86 Disassembler
...ed by the local process's notion of uintptr_t.
> 4. If you have a class that's completely contained within a .cpp
> file, go ahead and define it in an anonymous namespace and mark it
> "VISIBILITY_HIDDEN". Like this:
>
> namespace {
> class VISIBILITY_HIDDEN StringMemoryObject : public MemoryObject {
> ...
I used VISIBILITY_HIDDEN for both StringMemoryObject and
X86DisassemblerEmitter::X86DEBackend.
I wrapped StringMemoryObject in an anonymous namespace.
I didn't wrap X86DEBackend because it's already nested.
> 5. In "readBytes" in StringMemor...