search for: annotatedasmtok

...devolve into a pile of regex insanity. Why not use an existing standardized markup, like XML (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&...

...annotation system that a client can easily strip off while paying attention to the bits and pieces it cares 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 o...

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

...can easily strip off while paying attention to the bits and pieces it cares 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 t...

...em that a client can easily strip off while paying attention to the bits and pieces it cares 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...

...p off while paying attention to the bits and pieces it cares 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...

...ng attention to the bits and pieces it cares 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. >>>> >>&gt...