On Jun 9, 2012, at 12:47 PM, Chris Lattner wrote: > > On Jun 8, 2012, at 11:52 AM, Chad Rosier wrote: > >> The attached patch etches out a new code path for MS style inline assembly >> in the Parser, Sema, AST, and CodeGen. This is _largely_ a WIP! >> >> The idea is to translate the MS style inline assembly into IR that is >> equivalent to the GNU style inline assembly. That way the backend doesn't >> need to be modified (nor does our assembler implementation). I was hoping >> to make further progress on this today, so please take a look if you have a >> quick second. > > Cool, I'm glad to see this get started. While this style of asm is annoying > to implement, I really like it that users of the compiler don't have to worry > about operand constraints (which they're extremely likely to get wrong and > then blame the compiler when something changes). > > Can you talk a bit about the envisioned design here? How does the lexing of > the asm work? How does name lookup of variables plug into the lexing? Will > this be completely x86 specific, or could we (in principle) extend it to > support all targets that are interested?
Bob, Eric and I are still hashing things out (i.e., semi-flying by the seat of our pants), but I can give you an idea of what we're thinking. Interpret this both as a warning and a solicitation for input. :D Ideally, we would like for the front-end to interface with MC. llvm-gcc used a table-driven approach that was independent from the backend; this is understandable because MC didn't exist at that time. However, we'd like to avoid this because it reduces code duplication and moves us toward something that can be supported for all targets. The specific design of the interface is still an open question and that somewhat dictates how the name lookup is handled. Most of the lookup should be done in Sema (IMO). Eli has expressed concerns with how to represent the AST data structures, so I'm hoping to tackle this next. For the most part, I suspect much of this will lots of incremental commits as we continue to hash out a plan. Sorry for being so vague, but this is definitely a WIP. > I really like that the backend won't have to change for this. Do you > envision the assembler switching to ".intel_syntax" before emitting one of > these, or do you envision the trick that gcc/llvm-gcc's uses, where it > completely rewrites all syntax into AT&T style (including operands)? Or at the very least we can minimize the changes. :) I'm inclined to push for the former, but this is certainly debatable. Devang added support for MS/Intel syntax, but my understanding is that it's fairly untested. This is likely the path of least resistance as the rewriting is non-trivial. Chad > > -Chris > > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
