On 21/08/15 17:38, Jeffrey Walton wrote: > On Fri, Aug 21, 2015 at 9:56 AM, David Brown <david@xxxxxxxxxxxxxxx> wrote: >> On 21/08/15 15:24, Jeffrey Walton wrote: >>> I'm trying to compile some C code with inline assembly. I already have >>> the ASM code, so I don't need anything generated. Effectively, all I >>> need to do is map a C variable to an ASM symbolic name so I can use >>> the variables directly in MASM-like fashion. >> >> There are a number of issues here. I am not a particular expert on >> inline assembly, and the experience I have is all on embedded targets >> rather than x86. But maybe I can be of some help, so you know what to >> look for in the gcc manuals or general web search. >> >> First, gcc supports two inline assembly syntaxes for the x86. The >> default one (due to tradition on *nix and inertia) is AT&T, and it has a >> number of differences from the Intel assembly syntax used by MASM. You >> have two options - learn (or copy from the web) the difference so that >> you can use AT&T syntax in such inline assembly (this is the best >> option, I think, since it is the default syntax). Or learn the >> settings, command-line options, pragmas, or whatever it takes to enable >> MASM syntax in gcc. I have no idea what these might be, since I don't >> use them myself, but I bet the gcc documentation can give you a hint :-) > > We have to be careful here. Clang has its own integrated assembler, > and it does not fully support Intel assembly. You sent a question to the gcc-help list about using inline assembly - the assumption is that you are using /gcc/, not clang. If you want something that is directly compatible between different tools, you'll have a lot more work - you are probably best figuring out some conditional compilation flags that work despite clang's insistence on defining __GNUC__. And you would certainly get better answers if you say what you are trying to do, rather than adding constraints as an afterthought! <snip> > What should be done for earlier versions of GCC that don't provide > cpuid.h? And what if its a different compiler that's not fully > compatible with GCC (Clang comes to mind because it defines __GNUC__, > but it can't consume the same set of programs GCC can). Finally, minor > hair splitting, but what do we do when it does not provide an accurate > result, like __builtin_cpu_supports > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55307). > Again, if you need something that works across a range of tools or versions, say so. Otherwise the assumption here will be that you are using a reasonably modern version of gcc - and people will answer you accordingly. I recommend you look at the source for cpuid.h, and examine the functions and inline assembly therein. I can't say whether it will work on other compilers, but it should at least give you a starting point for inline assembly. And as Andrew Haley suggested, take a step back and figure out what you are really trying to achieve, and then ask about it - there may be many other ways to solve the task in hand. But when you give us half a solution, people can only guess what the question might have been.
