Re: Best Compiler

ask4code wrote:
> why i thought GCC support assembly?

Yes; But the GCC compiler actually itself uses the GAS assembler to do
it...hence, the comments that have been mentioned about GAS are -
indirectly - comments about GCC using GAS too...

In very simplified form, the following roughly happens when using GCC:

C++ source code -> GCC -> assembly code -> GAS -> object code -> LD ->
final program

Note that if you supply GCC with assembly source code, then GCC skips
the first part and sends it straight to GAS to process...if you supply
GCC with object code (or a library file, which is just a collection of
object code all rolled into one "archive" file, anyway) then it
automatically passes this onto LD...

As such, the "GCC" command is considered to be a "compiler
driver"...that is, there are actually many programs involved - such as
GAS, LD and possibly other utilities and programs, depending on what
you're asking GCC to do exactly - but GCC automatically starts these
programs for you...

But it is equally possible, of course, to "by-pass" using GCC in this
and simply send your source code straight to GAS (and then send the
output to LD for "linking")...by manually calling GAS and LD directly...

GCC itself simply sends any assembly to GAS automatically...hence, as I
say, what has been said about GAS here also basically applies to "GCC
inline assembly" because, in the end, GCC simply sends such assembly to
GAS to process, anyway...

GCC's "inline assembly", though, is a little bit more
complicated...though it is GAS that processes the assembly, in the end,
GCC's "asm" keyword does have extra "extensions"...but all these
basically relate to "integrating" the assembly with the C / C++ (extra
parameters about which registers are and aren't trashed: Allows the C
compiler to make more "intelligent" choices with the C code it
generates, so that it doesn't "clash" with the "inline assembly"
code...as, of course, the C / C++ code itself ends up as assembly code
too, once the compiler processes it...so, "behind the scenes" it too is
using registers and playing around with the stack...the "extensions" on
the GCC "inline ASM" keyword are basically a means to make the two
"integrate" together better...you can "inform" the C compiler about what
the assembly code does and doesn't "trash", so that it can make better
choices that don't "clash" or "conflict" or require it to take "safe"
(but usually crap and slow) actions to avoid a "clash")...

Anyway, this extra complication with the GCC "inline assembly", as
mentioned, is to do with the "integration" of the ASM code with the C /
C++ code (and see the GCC "man" pages or similar documentation about the
specifics)...otherwise, though, "GCC assembly" _IS_ GAS...it uses the
same GAS syntax and it simply gets sent by GCC to GAS for processing...

GCC isn't actually one single program...it's a "collection" of programs
that are used together to do the job...but you don't ordinarily notice
this, usually, because the GCC command line automatically starts up
whatever other programs it needs to start - GAS, LD, etc. - to get the
job done...so, you only have to type out the one GCC command line...but,
in fact, "behind the scenes", GCC automatically starts up other programs
on your behalf...

[ Note that this is, in fact, how GCC is so "versatile" and works for so
many platforms...it separates the "back end" stuff (the machine specific
utilities, usually called "binutils") from the other parts...so there's
no need to completely re-write a new GCC compiler for a new machine from
scratch but just a case of adding new "back ends" and utilities for the
"machine specific" parts...also, this same "decoupling" is how GCC
equally well supports other languages besides C and C++, by, this time,
changing the "front end" part instead...it's a pretty smart design
they've got there and (also being "open source" that anyone can add onto
it helps a great deal) no compiler comes close to GCC "range" of
supported languages and processors... ]

But, yes, anyway...the comments about GAS so far basically apply to GCC
too...because GAS _IS_ the assembler that GCC calls to get all its
assembly work done...if using "GCC inline assembly" then it's basically
"GAS with a few extra complications"...GAS syntax and sent to GAS for it
to process...the "extra complications" are to do with "integrating" your
"inline assembly" with the C / C++ code (I've done next to nothing with
this mechanism - but look at it once - so ask someone else about the
exact details 'cos I don't know 'em ;)...

As such, depending on what you want, it's probably advisable to cleanly
separate your C / C++ code and your assembly code...you know, create "C
/ C++ only" source files and "GAS only" source files which "call" into
each other, rather than putting the two together in the same
file...there's nothing wrong with doing so and you can do so (and maybe,
for what you're doing, you sometimes have to do that)...but you'll
probably find that it's much easier, more understandable and, basically,
simpler to keep the two separated (it doesn't "compromise" either - as
the C compiler might need to "shuffle registers" and other things to
make your "Inline ASM" sit comfortably next to the C code it generates -
and tends to simply be "more readable" when it's just one file with
"pure C / C++" and another file with "pure ASM" and never the twain
shall meet...you can mix and match but, in practice, it's usually better
NOT to do so, unless you really don't have a choice :)...

The "biggie" with GAS is that its syntax is based on so-called "AT&T
syntax", which is a "generic" syntax that's the same for all processors
(remembering that GCC / GAS run on a large amount of machines besides
x86s that this "same style of syntax regardless of processor" thing was
considered a "good idea" for those reasons)...and many people don't
particularly like this syntax style...especially if you're used to the
so-called "Intel syntax" style because, basically, AT&T syntax is
"backwards" compared to Intel syntax (and you have to explicitly put the
"size" of the operand into the mnemonic and other little "niggles" that
annoy people who prefer Intel syntax into not liking AT&T syntax much
;)...

There is a ".intel_syntax" directive with GAS, which makes it use a
Intel style of syntax...but I've personally never tried that so I don't
know if it's much use or not, in practice...also, if you're NOT actually
used to Intel syntax already, then, well, both syntaxes will be "alien",
so learning AT&T or Intel syntax won't make the slightest bit of
difference to a "learner" (other than that Intel syntax is used in
"examples" far, far more than AT&T syntax)...plus, _ALL_ assemblers have
different syntax from other assemblers, anyway...if you do a lot of
assembly coding (or just hang around here to look at people's "example
code" from many different assemblers) then you'd end up probably
learning a few of the different syntax styles, anyway...

Beth :)


.

Relevant Pages

  • Re: Assembly format translator from GCC Gas syntax to Intel for Intel and AMD
    ... which contain GAS format inline stuff such as: ... Does anyone know of a Gas ==> INTEL format translator for assembly? ... Would you not just be more prudent using a Windows port of gcc such as ... the assembler normaly distrubuted alongside gcc is AS ...
    (comp.lang.asm.x86)
  • Re: questions from a newbie
    ... the code is already generated by the assembler. ... thanks so much again), and since I'm not tied to gas, as I won't use ... inline assembly with gcc, or at least I can opt, I wonder if anybody ... most people find NASM's approximated Intel syntax much more ...
    (alt.lang.asm)
  • Re: about connect
    ... To be portable across Linux, BSD, Solaris, etc. - all running on an x86 ... can get real `as' code out of gcc, which is what I'm gonna look at now. ... alone, and it looks quite powerfull actually, can give gas all what it ... hardcode gas into autoconf, ...
    (alt.lang.asm)
  • Re: questions from a newbie
    ... the code is already generated by the assembler. ... way instead of the compiler optimizing 'around' inline assembly code, ... thanks so much again), and since I'm not tied to gas, as I won't use ... inline assembly with gcc, or at least I can opt, I wonder if anybody ...
    (alt.lang.asm)
  • Re: Is Betov trying to rip off the FASM source ?
    ... GCC without optmization turned on will compile the C ... the contribution to the compilation time ... afforded by using gas as a back end is effectively nothing. ... Except those shared libraries are not available for every platform on ...
    (alt.lang.asm)