search for: getrawtext

...not that I'm that fond of XML)? At a higher level, why not expose an API for iterating over (potentially annotated) tokens which can be programmatically inspected. So what you expose to clients is an AnnotatedAsmTok. Given an AnnotatedAsmTok, they can call "getAnnotation()", or "getRawText()". A textual representation which can be read into this form might be useful, but we should provide the parser. I guess what I think needs a bit more explanation is why you chose to go the "markup" route, instead of a normal programmatic API. Maybe you could also include a couple u...

...res about. > At a higher level, why not expose an API for iterating over > (potentially annotated) tokens which can be programmatically > inspected. So what you expose to clients is an AnnotatedAsmTok. Given > an AnnotatedAsmTok, they can call "getAnnotation()", or > "getRawText()". A textual representation which can be read into this > form might be useful, but we should provide the parser. We could. It's just outside the scope of what we're looking to do on the initial implementation. Note that it does get a bit more complicated since we're not just...

The following is a brief proposal for annotated assembly (and disassembly) output. Kevin Enderby and I have been discussing this a bit and are interested in getting broader feedback from interested folks. LLVM Rich Assembly Output LLVM's (dis)assembly output is currently very raw. Consumers have limited ability to introspect the instructions' textual representation or to reformat for

...el, why not expose an API for iterating over >>> (potentially annotated) tokens which can be programmatically >>> inspected. So what you expose to clients is an AnnotatedAsmTok. Given >>> an AnnotatedAsmTok, they can call "getAnnotation()", or >>> "getRawText()". A textual representation which can be read into this >>> form might be useful, but we should provide the parser. >> >> We could. It's just outside the scope of what we're looking to do on the initial implementation. Note that it does get a bit more complicated...

...At a higher level, why not expose an API for iterating over >> (potentially annotated) tokens which can be programmatically >> inspected. So what you expose to clients is an AnnotatedAsmTok. Given >> an AnnotatedAsmTok, they can call "getAnnotation()", or >> "getRawText()". A textual representation which can be read into this >> form might be useful, but we should provide the parser. > > We could. It's just outside the scope of what we're looking to do on the initial implementation. Note that it does get a bit more complicated since we'...

...se an API for iterating over >>>> (potentially annotated) tokens which can be programmatically >>>> inspected. So what you expose to clients is an AnnotatedAsmTok. Given >>>> an AnnotatedAsmTok, they can call "getAnnotation()", or >>>> "getRawText()". A textual representation which can be read into this >>>> form might be useful, but we should provide the parser. >>> >>> We could. It's just outside the scope of what we're looking to do on the initial implementation. Note that it does get a bit more...

...erating over >>>>> (potentially annotated) tokens which can be programmatically >>>>> inspected. So what you expose to clients is an AnnotatedAsmTok. Given >>>>> an AnnotatedAsmTok, they can call "getAnnotation()", or >>>>> "getRawText()". A textual representation which can be read into this >>>>> form might be useful, but we should provide the parser. >>>> >>>> We could. It's just outside the scope of what we're looking to do on the initial implementation. Note that it does get...