C Compilation..

R

raashid bhatt

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

raashid bhatt

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)
 
A

Antoninus Twink

- 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.
 
R

Richard Tobin

is there any standards that tell us how c code has to be compiled into
machine code
[/QUOTE]

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
 
J

jacob navia

raashid said:
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.
 
K

Kenny McCormack

You'd know /all/ about that.


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.
 
R

Richard Tobin

Richard Heathfield said:
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
 
R

Richard Tobin

Richard Heathfield said:
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
 
B

Bartc

Richard Heathfield said:
Richard Tobin said:

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.)
 
J

Joachim Schmitz

Richard said:
Joachim Schmitz said:


Thank you for the reference. I didn't notice anything on that page
about standards for translating C into machine code.


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
 
J

jacob navia

Richard said:
Richard Tobin said:


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...
 
A

Antoninus Twink

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.
 
K

Keith Thompson

Richard Heathfield said:
Richard Tobin said:

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.
 
B

Boon

Jacob said:
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.
 
L

Lassie

Antoninus Twink said:
As usual, Heathfield is playing his pathetic word games.


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.
 
J

jacob navia

Boon said:
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top