C Compilation..

Discussion in 'C Programming' started by raashid bhatt, Aug 23, 2008.

  1. is there any standards that tell us how c code has to be compiled into
    machine code
    raashid bhatt, Aug 23, 2008
    #1
    1. Advertising

  2. On 23 Aug 2008 at 8:13, raashid bhatt wrote:
    > is there any standards that tell us how c code has to be compiled into
    > machine code


    Yes. Most processor vendors will provide extensive documentation with
    advice and guidelines for writers of optimizing compilers. For example,
    Intel provides all this for free on the web:
    http://www.intel.com/products/processor/manuals/
    Antoninus Twink, Aug 23, 2008
    #2
    1. Advertising

  3. > No. C code need not even *be* compiled into a particular machine's machine
    > code. Often it is not - it is compiled (translated) into a particular
    > machine's assembly language instead. It could even be compiled into some
    > completely different language.


    yes i agree , and C is perhaps a Compiled language. But when people
    say C code is faster than any language but i will not be true if we
    use diffrent compilers(as u said there is not standard of compiled
    code)
    raashid bhatt, Aug 23, 2008
    #3
  4. On 23 Aug 2008 at 9:59, Richard Heathfield wrote:
    > - any performance problems are more likely to be a consequence of the
    > solution (i.e. your program isn't written as efficiently as it might
    > be) than of the translation.


    You'd know /all/ about that.

    > In any case, correctness is far more important than speed.


    False dichotomy. You seem to take the foolish approach that speed
    doesn't matter at all, and choosing an O(n^2) algorithm when an O(n)
    algorithm is available and in fact simpler and clearer doesn't bother
    you in the least. Why? Because you've turned "portability" into an
    obsession, and nothing else matters.
    Antoninus Twink, Aug 23, 2008
    #4
  5. In article <>,
    Richard Heathfield <> wrote:

    >> is there any standards that tell us how c code has to be compiled into
    >> machine code


    >No.


    Yes, several in fact..

    The C standard doesn't say anything about it, but other standards
    specify the conventions for procedure call, linking to external
    variables, and so on, for many of the operating systems that C is used
    on. If you're writing a C compiler that's going to be widely used,
    you probably need to follow these standards.

    -- Richard
    --
    Please remember to mention me / in tapes you leave behind.
    Richard Tobin, Aug 23, 2008
    #5
  6. raashid bhatt

    jacob navia Guest

    raashid bhatt wrote:
    > is there any standards that tell us how c code has to be compiled into
    > machine code


    In most operating systems, the compiler that compiles the operating
    system is the one that decides how the format layout, interface
    specifications, etc are to be done.

    Under Microsoft windows, it is Microsoft's compiler that specifies
    implicitely how things should be done.


    This is documented in:

    Microsoft Portable Executable and Common Object File Format Specification

    Microsoft Corporation
    Revision 6.0 - February 1999

    In that document are the full specifications for object files,
    executable files, and library formats.

    What the interface specifications is concerned (parameter passing,
    register a&ssignments, etc) those are specified in several pages
    mostly in the DDK (Driver Development Kit).

    Agner Fog (www.agner.org) wrote a document that makes the big
    tour of many different compilers in windows and shows the differences
    between them.

    The Linux world runs under the gcc evil empire, since it is gcc
    that compiles the linux kernel. The specification is called:

    SYSTEM V. APPLICATION BINARY INTERFACE.
    Intel386 Architecture Processor Supplement. Fourth Edition

    For 64 bit Linux you have:

    System V Application Binary Interface.
    AMD64 Architecture Processor Supplement. Draft Version 0.92, 2004.
    18.2 ABIs.

    Obviously there are many operating systems, and I can't tell you
    about all of them.

    An interesting one is AIX, the IBM Unix version. Documentation for
    the calling conventions and register assignments is difficult to find,
    but there is a good document called:

    The Power PC Compiler Writer’s Guide
    Edited by:
    Steve Hoxey Faraydon Karim Bill Hay Hank Warren

    This spells you the essential details for making a correct
    program under this processor/OS.



    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Aug 23, 2008
    #6
  7. raashid bhatt

    jacob navia Guest

    Richard Heathfield wrote:
    > Richard Tobin said:
    >
    >> In article <>,
    >> Richard Heathfield <> wrote:
    >>
    >>>> is there any standards that tell us how c code has to be compiled into
    >>>> machine code
    >>> No.

    >> Yes, several in fact..

    >
    > Oh, I'm sorry. Perhaps you could enlighten us with some references?
    >


    I gave many references in my reply to the OP.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Aug 23, 2008
    #7
  8. In article <>,
    Antoninus Twink <> wrote:
    >On 23 Aug 2008 at 9:59, Richard Heathfield wrote:
    >> - any performance problems are more likely to be a consequence of the
    >> solution (i.e. your program isn't written as efficiently as it might
    >> be) than of the translation.

    >
    >You'd know /all/ about that.
    >
    >> In any case, correctness is far more important than speed.

    >
    >False dichotomy. You seem to take the foolish approach that speed
    >doesn't matter at all, and choosing an O(n^2) algorithm when an O(n)
    >algorithm is available and in fact simpler and clearer doesn't bother
    >you in the least. Why? Because you've turned "portability" into an
    >obsession, and nothing else matters.


    Yes. I think that whatever you may think of Heathfield's ideas and
    posting style, even the most die-hard sycophants will have to admit that
    he really put his foot in it this time.

    You simply have to realize that in the real world, customers pay the
    bills *and* customers don't give a darn about "how ya did it". They
    care that it works and works well. No real world customer is going to
    prefer a "100% portable" solution that is so slow that, for all
    practical purposes, it can be said to simply not work. Nor is any real
    world customer going to answer in anything other than the obvious way
    when asked "So, Mr. Customer who is paying my bills, I can make this
    code run faster - making you look better to your bosses - but at the
    cost of making it not quite so aesthetically pleasing to the denizens of
    this Usenet newsgroup called (amazingly enough) 'comp.lang.c'. Whaddya
    think? Should I do it?"

    Mind you, all of the above is spoken as one who really does take pride
    in my work, likes to make my code aesthetically pleasing, and is
    actually somewhat miffed to find that my customers really don't give a
    darn about "how ya did it". But that's reality - a domain in which few
    clc regulars have had to function in, in decades.

    Maybe AT should re-post his little dialog between CBF and his
    hypothetical customer. Was quite illuminating.
    Kenny McCormack, Aug 23, 2008
    #8
  9. Richard Heathfield wrote:
    > Richard Tobin said:
    >
    >> In article <>,
    >> Richard Heathfield <> wrote:
    >>
    >>>> is there any standards that tell us how c code has to be compiled
    >>>> into machine code

    >>
    >>> No.

    >>
    >> Yes, several in fact..

    >
    > Oh, I'm sorry. Perhaps you could enlighten us with some references?


    Start with:
    http://en.wikipedia.org/wiki/Application_binary_interface

    However, none if this would be topical in comp.lang.c...

    Bye, Jojo
    Joachim Schmitz, Aug 23, 2008
    #9
  10. In article <>,
    Richard Heathfield <> wrote:

    >In any case, correctness is far more important than speed.


    Not always. For some purposes, as someone used to have in their
    signature, "late answers are wrong answers".

    -- Richard
    --
    Please remember to mention me / in tapes you leave behind.
    Richard Tobin, Aug 23, 2008
    #10
  11. In article <>,
    Richard Heathfield <> wrote:

    >>>> is there any standards that tell us how c code has to be compiled into
    >>>> machine code


    >>>No.


    >> Yes, several in fact..


    >Oh, I'm sorry. Perhaps you could enlighten us with some references?


    The System V ABI for x86 is the best-known example.

    -- Richard
    --
    Please remember to mention me / in tapes you leave behind.
    Richard Tobin, Aug 23, 2008
    #11
  12. In article <>,
    Richard Heathfield <> wrote:

    >I would have thought that a standard that tells us how C must be compiled
    >into machine code would be very topical. I am yet to be convinced that
    >such a standard exists, however. Richard Tobin seems to think that one
    >does, so I await his reply with interest.


    It looks as if you'll be disappointed, because I was thinking of the
    same class of standards that others have mentioned.

    -- Richard

    --
    Please remember to mention me / in tapes you leave behind.
    Richard Tobin, Aug 23, 2008
    #12
  13. raashid bhatt

    Bartc Guest

    "Richard Heathfield" <> wrote in message
    news:...
    > Richard Tobin said:


    >> The System V ABI for x86 is the best-known example.

    >
    > Thank you.
    >
    > It appears to be a 258-page document. Could you possibly help me out by
    > telling me whereabouts in that document I can find the bit that tells us
    > how C code has to be compiled into machine code?
    >
    > It would be fun to be disingenuous, with the punchline being that C
    > doesn't
    > have to be compiled into machine code in the first place, and therefore
    > there can't be a standard telling us it does have to be. But that's not
    > what I'm getting at here. I am assuming for the purpose of this discussion
    > that our objective is to compile C code into machine code, and the
    > question before us is whether any recognised standard exists that tells us
    > how this must be done.
    >
    > You have suggested the System V ABI for x86, but I'm doubtful on two
    > grounds. Firstly, on first glance I can only find the term "machine code"
    > once in the entire document, and that part didn't seem to have anything to
    > do with translating C. Perhaps you could set me straight there.


    ABIs are not necessarily tied to one any language which may explain why C
    was not singled out (I haven't seen the document).

    But, if you were tomorrow giving the task of translating C source to binary
    x86 code for System V, you might suddenly find this document becoming a lot
    more interesting.

    Yes (or, No), C doesn't need translating to machine code, but usually is, by
    some process or other. In that case the conventions for talking and linking
    to other software can become important, if that's what the OP was on about.

    (Myself, I've mostly ignored any such conventions when I've done similar
    work.)

    --
    Bartc
    Bartc, Aug 23, 2008
    #13
  14. Richard Heathfield wrote:
    > Joachim Schmitz said:
    >
    >> Richard Heathfield wrote:
    >>> Richard Tobin said:
    >>>
    >>>> In article <>,
    >>>> Richard Heathfield <> wrote:
    >>>>
    >>>>>> is there any standards that tell us how c code has to be compiled
    >>>>>> into machine code
    >>>>
    >>>>> No.
    >>>>
    >>>> Yes, several in fact..
    >>>
    >>> Oh, I'm sorry. Perhaps you could enlighten us with some references?

    >>
    >> Start with:
    >> http://en.wikipedia.org/wiki/Application_binary_interface

    >
    > Thank you for the reference. I didn't notice anything on that page
    > about standards for translating C into machine code.
    >
    >> However, none if this would be topical in comp.lang.c...

    >
    > I would have thought that a standard that tells us how C must be
    > compiled into machine code would be very topical. I am yet to be
    > convinced that such a standard exists, however. Richard Tobin seems
    > to think that one does, so I await his reply with interest.


    Probably because these are language independant.

    Bye, Jojo
    Joachim Schmitz, Aug 23, 2008
    #14
  15. raashid bhatt

    jacob navia Guest

    Richard Heathfield wrote:
    > Richard Tobin said:
    >
    >> In article <>,
    >> Richard Heathfield <> wrote:
    >>
    >>>>>> is there any standards that tell us how c code has to be compiled
    >>>>>> into machine code
    >>>>> No.
    >>>> Yes, several in fact..
    >>> Oh, I'm sorry. Perhaps you could enlighten us with some references?

    >> The System V ABI for x86 is the best-known example.

    >
    > Thank you.
    >
    > It appears to be a 258-page document. Could you possibly help me out by
    > telling me whereabouts in that document I can find the bit that tells us
    > how C code has to be compiled into machine code?
    >


    Look Heathfield, if you can't read it's nobody problem but yours;

    Take for instance this C code. I add line numbers for reference

    (1) int heathfield(short cbfalconer,double jkuyper)
    (2) {
    (3) }

    Here we have in line 1 a function that returns an integer
    and receives two arguments: a short and a double.

    Now, in the *real* world, we have to specify in which machine
    register the argument is returned, and in which machine
    register the arguments are passed if at all.

    The C standard doesn't mention at all this, for obvious reasons.
    An ABI then, is a standard thet allows programs compiled by
    different vendors and even in different languages to cooperate
    by means of a common interface.

    The ABI mentioned above specifies how are arguments passed in
    machine code to the function, and how the result is stored
    when the function exits.

    In line 2 we have an opening brace, i.e. a function prologue.
    This is specified too, as well as line 3, the function epilogue.


    > It would be fun to be disingenuous, with the punchline being that C doesn't
    > have to be compiled into machine code in the first place, and therefore
    > there can't be a standard telling us it does have to be.


    Yeah, C can be interpreted by Heathfield and co.
    Instead of buying a computer, I can send my program to
    Heathfield, he will parse it, and then
    calculate everything with paper and pencil.


    > But that's not
    > what I'm getting at here. I am assuming for the purpose of this discussion
    > that our objective is to compile C code into machine code, and the
    > question before us is whether any recognised standard exists that tells us
    > how this must be done.
    >


    There are as many standards as operating systems and processors.
    For combination of OS and processor, there is a standard.
    For instance for the Solaris operating system, there is an ABI for
    the x86/32 bits, SPARC 32 bits, Sparc 64 bits, and x86/64 bits.


    > You have suggested the System V ABI for x86, but I'm doubtful on two
    > grounds. Firstly, on first glance I can only find the term "machine code"
    > once in the entire document,


    Obviously all the assembly examples in the ABI are not machine code.
    For instance in page 40 we have

    epilogue:
    popl %ebx /restore local register
    popl %esi /restore local register
    popl %edi /restore local register
    leave /restore framepointer
    ret /pop return address

    This is not machine code since if I search for
    "machine code" without bothering to read
    the document I will not find it

    :)

    > and that part didn't seem to have anything to
    > do with translating C. Perhaps you could set me straight there.
    >


    Yes, not difficult to "set you straight". Learn to read.

    > Secondly, I see no claim within the document itself to be a standard, and
    > the frontispiece doesn't bode well:
    >
    > "Information in this document is subject to change without notice and does
    > not represent a commitment on the part of The Santa Cruz Operation, Inc."
    >
    > If it's subject to change without notice, it's hard to see how it can
    > reasonably be called a standard.
    >



    This is the way those standards are done. We are not speaking about ISO
    here, nor about C89...



    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Aug 23, 2008
    #15
  16. On 23 Aug 2008 at 17:13, jacob navia wrote:
    > Look Heathfield, if you can't read it's nobody problem but yours;


    As usual, Heathfield is playing his pathetic word games.

    > This is the way those standards are done. We are not speaking about ISO
    > here, nor about C89...


    He is deliberately interpreting "standard" as "ISO standard", even
    though it's obvious to every other poster in this thread, and indeed
    every reasonable person, that that isn't what the OP meant. He knows
    this full well, but will continue to play along telling everyone else
    their idiots because they won't play by his silly rules.

    Word games - SMOKE and MIRRORS. This is Heathfield's "contribution" to
    clc.
    Antoninus Twink, Aug 23, 2008
    #16
  17. Richard Heathfield <> writes:
    > Richard Tobin said:
    >> In article <>,
    >> Richard Heathfield <> wrote:
    >>
    >>>In any case, correctness is far more important than speed.

    >>
    >> Not always. For some purposes, as someone used to have in their
    >> signature, "late answers are wrong answers".

    >
    > Wrong answers are wrong answers, too. Getting them quicker doesn't make
    > them righter.


    You're both right. Sometimes speed is simply part of the
    requirements. (And sometimes it isn't.)

    *Sometimes* getting the right answers too late isn't much better than
    getting wrong answers. For example, a system that produces a 100%
    accurate forecast of tomorrow's weather but takes a week to run might
    as well have been wrong. But it could be a good starting point either
    for a faster system that does the same thing, or for understanding how
    weather works, which can be scientifically valuable in itself even if
    it doesn't give you useful forecasts.

    Of course, faster is better if all else is equal; nobody has suggested
    otherwise. But all else isn't always equal.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 23, 2008
    #17
  18. raashid bhatt

    Boon Guest

    Jacob wrote:

    > The Linux world runs under the gcc evil empire, since it is gcc
    > that compiles the linux kernel.


    Evil empire? GCC conforms to the System V ABI as you point out.
    Boon, Aug 23, 2008
    #18
  19. raashid bhatt

    Lassie Guest

    "Antoninus Twink" <> schreef in bericht
    news:...
    > On 23 Aug 2008 at 17:13, jacob navia wrote:
    >> Look Heathfield, if you can't read it's nobody problem but yours;

    >
    > As usual, Heathfield is playing his pathetic word games.
    >
    >> This is the way those standards are done. We are not speaking about ISO
    >> here, nor about C89...

    >
    > He is deliberately interpreting "standard" as "ISO standard", even
    > though it's obvious to every other poster in this thread, and indeed
    > every reasonable person, that that isn't what the OP meant. He knows
    > this full well, but will continue to play along telling everyone else
    > their idiots because they won't play by his silly rules.
    >
    > Word games - SMOKE and MIRRORS. This is Heathfield's "contribution" to
    > clc.


    That's what I was thinking. When he said: "Richard Tobin seems to think that
    one does, so I await his reply with interest".

    You already knew what he would say if Tobin would come up with an ABI spec.
    Lassie, Aug 23, 2008
    #19
  20. raashid bhatt

    jacob navia Guest

    Boon wrote:
    > Jacob wrote:
    >
    >> The Linux world runs under the gcc evil empire, since it is gcc
    >> that compiles the linux kernel.

    >
    > Evil empire? GCC conforms to the System V ABI as you point out.


    Well, that was a joke... Microsoft is the evil empire, gnu people say.
    So I called them as they call others.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Aug 23, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris P
    Replies:
    0
    Views:
    439
    Chris P
    Oct 28, 2003
  2. Weng Tianxiang

    Re: Compilation error reason???

    Weng Tianxiang, Jul 23, 2003, in forum: VHDL
    Replies:
    1
    Views:
    1,573
    Mike Treseler
    Jul 24, 2003
  3. YesMann

    Compilation error

    YesMann, Aug 8, 2003, in forum: VHDL
    Replies:
    2
    Views:
    930
    YesMann
    Aug 8, 2003
  4. Vincent
    Replies:
    3
    Views:
    689
  5. C__chp
    Replies:
    4
    Views:
    503
    Puppet_Sock
    Feb 15, 2008
Loading...

Share This Page