C Compilation..

[raashid bhatt]

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

[Richard Heathfield]

raashid bhatt said:

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

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. Or it might not be compiled at all (C
interpreters exist).

In any case, such a standard would be impractical. There are just too many
kinds of machine out there, and too many kinds of machine code, for such a
standard to be practical.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Antoninus Twink]

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/

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

[Richard Heathfield]

raashid bhatt said:

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

Well, a language doesn't really have a speed. Nevertheless, C
compiler-writers do tend to be rather good (on the whole) at not getting
in your way - any performance problems are more likely to be a consequence
either of the problem (i.e. it's inherently a slow task) or the solution
(i.e. your program isn't written as efficiently as it might be) than of
the translation.

In any case, correctness is far more important than speed. Any fool can get
the wrong results quickly: int main(void) { return 0; } will do it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Malcolm McLean]

"raashid bhatt" <ra**********@gmail.comwrote in message news:

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

C is fast because, generally, it is easy to write an optimising compiler for
it. Most C statements map quite naturally to only a few assembler
instructions.
However if you use an old C compiler that maybe doesn't make full use of the
computer's instruction set, the code will be slower than a competing
language run under a new environment. Theoretically you could also have a
bad C compiler, but in practise such compilers aren't released.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Antoninus Twink]

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.

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

>
In any case, correctness is far more important than speed. Any fool can
get
the wrong results quickly: int main(void) { return 0; } will do it.

Often there's a tension. For instance video games that run with a good frame
rate with poorly normalised vectors for lighting versus ones that run slower
but have more accurate lights.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Tobin]

In article <86******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

[Malcolm McLean]

"Antoninus Twink" <no****@nospam.invalidwrote in message news:

On 23 Aug 2008 at 9:59, Richard Heathfield wrote:

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

Algorithms are inherently portable. Of course an O(N) library might be
available for one particular platform, and be too difficult to reimplement
with reasonable effort. Hence there could be a choice between a portable
O(N^2) and a non-portable O(N) solution. But this is rare.

Most people naturally assume that the reason for writing portable code is to
run the same code on different machines. Whilst this is a benefit, the real
reason is to separate the logic from the IO. Logic is portable, IO tends to
be very platform dependent. The struture of the program benefits
considerably from this.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Richard Heathfield]

Malcolm McLean said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message

>>
In any case, correctness is far more important than speed. Any fool can
get
the wrong results quickly: int main(void) { return 0; } will do it.

Often there's a tension. For instance video games that run with a good
frame rate with poorly normalised vectors for lighting versus ones that
run slower but have more accurate lights.

That's a requirements issue, not a correctness issue. As you say, it's a
trade-off - if you can make the lighting model reality more accurately, or
provide a frame rate that increases realism by increasing smoothness, but
not both, then you have to choose, and that choice is really up to you, or
rather to whoever it is that is specifying the program (which might be
you, of course).

By correctness I mean that the behaviour of the program should be such that
it meets the requirements laid down for it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Richard Tobin said:

In article <86******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>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?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

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]

Richard Heathfield wrote:

Richard Tobin said:

>In article <86******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

[Kenny McCormack]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

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

[Joachim Schmitz]

Richard Heathfield wrote:

Richard Tobin said:

>In article <86******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>>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/Applica...nary_interface

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

Bye, Jojo

[Richard Tobin]

In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>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]

In article <-q******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>>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 Heathfield]

jacob navia said:

Richard Heathfield wrote:

>Richard Tobin said:

>>In article <86******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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.

Yes, I saw that just now. Nevertheless, I'm interested to see what Richard
Tobin has to say on the question of standards for translating C into
machine code, and perhaps other people will be interested, too, to hear
his take on the subject.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Joachim Schmitz said:

Richard Heathfield wrote:

>Richard Tobin said:

>>In article <86******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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/Applica...nary_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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Richard Tobin said:

In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Tobin]

In article <pa******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>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 Heathfield]

Richard Tobin said:

In article <-q******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>>>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?

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.

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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Richard Tobin said:

In article <pa******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

Ah, I see. (Forget my parallel rely, then.) If the example you have given
is typical of that class of documents, I don't see how that class applies
to the OP's question.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:26******************************@bt.com...

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

[Joachim Schmitz]

Richard Heathfield wrote:

Joachim Schmitz said:

>Richard Heathfield wrote:

>>Richard Tobin said:

In article <86******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>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/Applica...nary_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

[jacob navia]

Richard Heathfield wrote:

Richard Tobin said:

>In article <-q******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

[Antoninus Twink]

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.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Richard Tobin said:

>In article <lp******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>>>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) ks***@mib.org <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"

[Boon]

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.

[Lassie]

"Antoninus Twink" <no****@nospam.invalidschreef in bericht
news:sl*******************@nospam.invalid...

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.

[jacob navia]

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

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:

Richard Heathfield wrote:

>Richard Tobin said:

>>In article <-q******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>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;

As usual, you choose to be insulting just because you're talking to
Richard Heathfield.

It's a 258-page document. Do you expect him, or anyone else, to read
the whole thing just to answer a question? Sheesh.

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

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

I presume that doesn't appear in the ABI.

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.

So the ABI specifies how C code interfaces with other code, and that
certainly affects the generated code in some circumstances. But
that's nowhere near what the OP was asking about, namely "standards
that tell us how c code has to be compiled into machine code".

The ABI presumably says that the first argument, if it's of certain
types, is passed by copying it to some specified register (for
example; I don't know the details). That specifies the *effect* of
the generated code. My guess is that it doesn't mandate any
particular machine instructions to accomplish that effect. I would
expect that two compilers that achieve the same effect using different
instruction sequences would both satisfy the ABI's requirements.

Perhaps I've guessed incorrectly. (I'm not going to take the time to
download and read a 258-page document.) Perhaps, for some reason, it
really does mandate specific instruction sequences (if so, it would be
difficult to detect an implementation that violates such a requirement
by using a different instruction sequence to achieve the same effect).
But even if that's the case, I doubt that the ABI says anything about
*internal* code, i.e., for C code that doesn't interact with anything
outside the program.

You presented an example of a function that takes two arguments and
does nothing with them, an example specifically restricted to what the
ABI covers. What about something like this?

unsigned long factorial(unsigned long n)
{
if (n <= 1) return n;
return n * factorial(n - 1);
}

Assume that the compiler can determine that this function isn't called
from outside the compilation unit that contains it.

The ABI specifies how the function is to be called, how the argument
is to be passed to it, and how the returned value is to be made
available to the caller, but does it say *anything* else about the
machine code generated for this function? Does it specify whether
"n - 1" is computed using a subtraction or a decrement instruction?

Does it either require or forbid tail recursion optimization? Does it
require "n <= 1" to be computed using an integer comparison operator,
or can the compiler generate code to evaluate "!(n & ~1)"?

An ABI specifies how generated code interfaces with other code. It
*might* specify the actual generated machine code to accomplish this,
though I don't see why it would need to do so. It *doesn't* specify
in general what machine code is generated for C source code, which is
what the OP was asking about.

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

You don't do sarcasm well.

C can be compiled into some intermediate form and interpreted. That's
not a common implementation strategy, but it's perfectly legal.

>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

:-)

Are you suggesting that unless Richard takes the time to sit down and
read the entire 258-page document, he shouldn't comment on it?

Somebody else made the extraordinary claim (or at least implied it)
that this document specifies how to generate machine code from C.
It's up to the person making that claim, or to those supporting the
claim, to justify 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.

Good advice. Please follow it.

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

Nor are we speaking about standards for generating machine code, which
was the original question.

The answer to the original question is "No.". There may be some
standards that specify some aspects of the generated machine code for
some systems.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"

[Kenny McCormack]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
....

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

On a good day...

[Philipp Klaus Krause]

Malcolm McLean schrieb:

>
"raashid bhatt" <ra**********@gmail.comwrote in message news:

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

C is fast because, generally, it is easy to write an optimising compiler
for it. Most C statements map quite naturally to only a few assembler
instructions.
However if you use an old C compiler that maybe doesn't make full use of
the computer's instruction set, the code will be slower than a competing
language run under a new environment. Theoretically you could also have
a bad C compiler, but in practise such compilers aren't released.

Well, even between today's compilers there can be huge differences. For
example http://sdcc.wiki.sourceforge.net/Philipp%27s+TODO+list has a
comparison of some current C compilers for the Z80 and there are code
size differences in excess of 300% for some functions.

Philipp

[Flash Gordon]

jacob navia wrote, On 23/08/08 18:13:

Richard Heathfield wrote:

>Richard Tobin said:

>>In article <-q******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

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

Only *if* the compiler does not inline the function. An ABI does not
specify whether or not functions can be inlined in general (I'm thinking
static functions here), although obviously it implicitly defines this
for exported functions.

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.

Agreed.

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.

Agreed for exported functions.

<snip>

I agree that an ABI *is* a standard, even if it is not an ISO (or ANSI
or some other national body) standard. However, it only specifies a
small part of the machine code generated for any given program. It does
not, for example, specify the instruction to use to increment a variable
by 1 or how to determine which local variables should be held in
registers, these and many other issues in translating C (or any other
language) to machine code are left up to the ingenuity of the compiler
writers.
--
Flash Gordon

[Flash Gordon]

Malcolm McLean wrote, On 23/08/08 11:00:

>
"raashid bhatt" <ra**********@gmail.comwrote in message news:

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

C is fast because, generally, it is easy to write an optimising compiler
for it. Most C statements map quite naturally to only a few assembler
instructions.

Nowhere near as relevant as it used to be. Modern optimisers (or even
optimisers from 10 years ago) will drastically rearrange code so it
looks nothing like the original code.

However if you use an old C compiler that maybe doesn't make full use of
the computer's instruction set,

This is very common with modern compilers. Most people want their
application to run on more than just the latest processor in the series,
and if you support the previous version of a processor you cannot use
the instructions added in the new version!

the code will be slower than a competing
language run under a new environment. Theoretically you could also have
a bad C compiler, but in practise such compilers aren't released.

Oh, there are bad C compilers around, they just are not the most used
compilers.
--
Flash Gordon

[Flash Gordon]

Malcolm McLean wrote, On 23/08/08 13:04:

>
"Antoninus Twink" <no****@nospam.invalidwrote in message news:

>On 23 Aug 2008 at 9:59, Richard Heathfield wrote:

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

Algorithms are inherently portable.

I generally find algorithms *very* portable. So much so that I've ported
algorithms between different languages and processors without ever
having to change the algorithm.

Of course an O(N) library might be
available for one particular platform, and be too difficult to
reimplement with reasonable effort.

If the algorithm was implemented properly in the first place it is
normally extremely simple to port. The exception comes when the
algorithm assumes that more of some resource (e.g. memory) is available
than is available on the new target.

Hence there could be a choice
between a portable O(N^2) and a non-portable O(N) solution. But this is
rare.

OK, so give an example of an *algorithm* that is not portable and say
*what* prevents it from being portable.

Most people naturally assume that the reason for writing portable code
is to run the same code on different machines. Whilst this is a benefit,
the real reason is to separate the logic from the IO. Logic is portable,
IO tends to be very platform dependent. The struture of the program
benefits considerably from this.

I agree that this is a major additional benefit.
--
Flash Gordon

[Philipp Klaus Krause]

Flash Gordon schrieb:

If the algorithm was implemented properly in the first place it is
normally extremely simple to port. The exception comes when the
algorithm assumes that more of some resource (e.g. memory) is available
than is available on the new target.

>Hence there could be a choice between a portable O(N^2) and a
non-portable O(N) solution. But this is rare.

OK, so give an example of an *algorithm* that is not portable and say
*what* prevents it from being portable.

LZW decompression isn't really portable to the ColecoVision since LZW
builds a dictionary at run-time, which thus has to reside in RAM. This
dictionary gets relatively large, so LZW isn't usable on the
ColecoVision with it's 1 KB of RAM.

There exist algorithms which are not portable to the Colossus computer,
since the instruction set of Colossus was not Turing complete.

Philipp

[Walter Banks]

Philipp Klaus Krause wrote:

LZW decompression isn't really portable to the ColecoVision since LZW
builds a dictionary at run-time, which thus has to reside in RAM. This
dictionary gets relatively large, so LZW isn't usable on the
ColecoVision with it's 1 KB of RAM.

LZW was implemented on Coleco Vision during development. I can't
remember the typical of maximum RAM limits on Coleco Vision but
executables were loaded from tape to RAM and executed.

w..

[Lassie]

"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...

As usual, you choose to be insulting just because you're talking to
Richard Heathfield.

It's a 258-page document. Do you expect him, or anyone else, to read
the whole thing just to answer a question? Sheesh.

You dont have to read it to understand what kind of standard this is
especially if you have some practical experience in programming.

>

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

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

I presume that doesn't appear in the ABI.

it does. return value, parameters, function calls etc.

So the ABI specifies how C code interfaces with other code, and that
certainly affects the generated code in some circumstances. But
that's nowhere near what the OP was asking about, namely "standards
that tell us how c code has to be compiled into machine code".

It is, this is the way to go for that platform. You can view it as UB if a
compiler tries to be smart and does things completely different from other
compilers on the same machine. This code will not work together with other
binaries anymore. But I'm sure you wont view it like that, otherwise you
wouldnt be right anymore. Disagreement for the sake of argument.

The ABI presumably says that the first argument, if it's of certain
types, is passed by copying it to some specified register (for
example; I don't know the details). That specifies the *effect* of
the generated code. My guess is that it doesn't mandate any
particular machine instructions to accomplish that effect. I would
expect that two compilers that achieve the same effect using different
instruction sequences would both satisfy the ABI's requirements.

So the ABI says that a return value must be passed in the EAX register. How
many "instruction sequences" can you think of that write and read from that
register?

[cr88192]

"Boon" <root@localhostwrote in message
news:48**********************@news.free.fr...

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.

the System V ABI is also an Evil Empire...
for example, consider the SysV / AMD64 ABI, with its elaborate and
complicated register-based calling convention, making it difficult to target
with all but the most elaborate of compilation techniques...

we should just be glad that they did not try to replace ELF with some
similarly complicated beast (such as, not only making ELF64 to replace
ELF32, but also merging it with DWARF at some fine level, making it
impossible to process the files absent having to deal head-on with DWARF's
encoding issues...).
OTOH, for 32-bit code, the conventions are far simpler, and much easier to
target.

now, of course, I "could" potentially target x86-64 using a hack similar to
how I handled "first-class function calls" on x86-64, basically building an
argument list in memory, and then using a signature string to pack/unpack
this buffer to/from the correct registers and stack positions (via wonky
assembler code), but this would suck performance wise.

I also lost motivation and so never did finish the newer SSA-based compiler
core (would probably be able to target it directly, but I lost motivation
since I primarily just develop on Win32 anyways...).
actually, I personally find the convention both annoying and silly, since
the design as such that, much of the time, internal overheads (trying to get
everything shuffled around, ... for any non-trivial functions) are likely to
exceed any such gains from using these regs and this layout anyways (or,
FFS, they could have at least left free-spots/holes on the stack, like in
the PowerPC conventions, ...).

this shuffling may well cost some, making the convention, in general, slower
than simply upscaling the 32-bit x86 cdecl convention would have been...

the sad thing is that Linux adopted this convention as is, and now people
have to live with it.
now, of course, it could also be possible to use multiple conventions
(allowing a simpler internal convention, and generate ugly patch stubs to
deal with interfacing them), but this introduces a good deal more issues
(performance, issues when using function pointers, ...), or a case similar
to in Win32, where many functions have to be declared with specific calling
conventions (__cdecl, __stdcall, ...).

on Linux this would mean customized system headers, or maybe wrapping all of
the native system headers with something like this:

in stdio.h:
extern __sysv {
#include <OS/include/stdio.h>
}

....
so, yes, maybe all this is an evil empire...

[cr88192]

"raashid bhatt" <ra**********@gmail.comwrote in message
news:da**********************************@z6g2000p re.googlegroups.com...

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

not really.

there are standards for C.

there are standards which tell how out machine code is to be structured
(various ABIs, instruction set architectures, ...).

but, between these extremes, people are allowed to do pretty much anything
they can make work...
for example, whether their compiler internally uses a stack-based process,
SSA, ... doesn't usually matter that much...

[Keith Thompson]

"Lassie" <zh*@woaini.comwrites:

"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...

>As usual, you choose to be insulting just because you're talking to
Richard Heathfield.

It's a 258-page document. Do you expect him, or anyone else, to read
the whole thing just to answer a question? Sheesh.

You dont have to read it to understand what kind of standard this is
especially if you have some practical experience in programming.

>>

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

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

I presume that doesn't appear in the ABI.

it does. return value, parameters, function calls etc.

I meant that that specific code, with identifiers "heathfield",
"cbfalconer", and "jkuyper", doesn't appear in the ABI.

>So the ABI specifies how C code interfaces with other code, and that
certainly affects the generated code in some circumstances. But
that's nowhere near what the OP was asking about, namely "standards
that tell us how c code has to be compiled into machine code".

It is, this is the way to go for that platform. You can view it as UB
if a compiler tries to be smart and does things completely different
from other compilers on the same machine. This code will not work
together with other binaries anymore. But I'm sure you wont view it
like that, otherwise you wouldnt be right anymore. Disagreement for
the sake of argument.

Not at all.

My point, which you conveniently snipped, is that the ABI presumably
doesn't specify what machine code should be generated from C code in
all circumstances. It merely defines the behavior, and *maybe* the
actual machine code, for the interaction between the generated code
and other code in the system.

[snip]

Re-read the original question that started this thread. Do you really
think the OP was asking about ABIs?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"

[Philipp Klaus Krause]

Walter Banks schrieb:

>
Philipp Klaus Krause wrote:

>LZW decompression isn't really portable to the ColecoVision since LZW
builds a dictionary at run-time, which thus has to reside in RAM. This
dictionary gets relatively large, so LZW isn't usable on the
ColecoVision with it's 1 KB of RAM.

LZW was implemented on Coleco Vision during development. I can't
remember the typical of maximum RAM limits on Coleco Vision but
executables were loaded from tape to RAM and executed.

w..

You're thinking of the Coleco Adam (the computer). The Coleco Adam has
enough RAM for LZW. The ColecoVision (the video game console) doesn't.
The ColecoVision executes directly from ROM chips in the cartridge.

Philipp

[Lassie]

"Keith Thompson" <ks***@mib.orgschreef in bericht
news:ln************@nuthaus.mib.org...

Re-read the original question that started this thread. Do you really
think the OP was asking about ABIs?

The OP is not experienced in C, I believe he didnt know himself what he was
asking. But as far as his question concerns, ABI answers it pretty much yes.
It's not a 100% C to machine instruction standard no, but they cover a lot
of binary interfacing yes.

[santosh]

Bartc wrote:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:26******************************@bt.com...

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

Though it's called the System V ABI, it's actually applicable to all x86
machine code, whatever be the source language. It simply allows binary
level interoperability between programs compiled from different
languages and compilers.

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

Even when I write in assembler I usually stick to the main guidelines of
the ABI, since this allows me to make use of many use Standard library
functions.

[Bartc]

"santosh" <sa*********@gmail.comwrote in message
news:g8**********@registered.motzarella.org...

Bartc wrote:

>"Richard Heathfield" <rj*@see.sig.invalidwrote in message

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

Though it's called the System V ABI, it's actually applicable to all x86
machine code, whatever be the source language. It simply allows binary
level interoperability between programs compiled from different
languages and compilers.

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

Even when I write in assembler I usually stick to the main guidelines of
the ABI, since this allows me to make use of many use Standard library
functions.

For x86-32, the guidelines can be summarised as follows: when calling
Windows functions: push the parameters right to left, and the callee adjusts
the stack on return. When calling C (I've found), do the same, except the
caller adjusts the stack. Oh, and when Windows (and, I think, C) calls
/your/ functions, you need to save most of the registers.

And... that's it. I've never had a need to look at any 258- or 377-page
documents (largely through ignorance of their existence).

x86-64 seems a lot more intricate, but even then, if I was still working at
that level, I think I could still do whatever I wanted (I used to push left
to right, with the last/only parameter passed via a register), /except/ when
calling, or being called by, an external function.

--
Bartc

[Antoninus Twink]

On 24 Aug 2008 at 8:31, Keith Thompson wrote:

Re-read the original question that started this thread. Do you really
think the OP was asking about ABIs?

To turn the tables, do you really think the OP was asking about ISO
Standards?

My own opinion is that the word "standard" as the OP used it was
deliberately vague, and ABIs fit it well enough as an answer. As you'll
see from my first followup to the OP, I interpreted his question
differently, but discussing ABIs is a perfectly valid response too to a
broad and not-very-well-specified question.

[Walter Banks]

Philipp Klaus Krause wrote:

Walter Banks schrieb:

Philipp Klaus Krause wrote:

LZW decompression isn't really portable to the ColecoVision since LZW
builds a dictionary at run-time, which thus has to reside in RAM. This
dictionary gets relatively large, so LZW isn't usable on the
ColecoVision with it's 1 KB of RAM.

LZW was implemented on Coleco Vision during development. I can't
remember the typical of maximum RAM limits on Coleco Vision but
executables were loaded from tape to RAM and executed.

w..

You're thinking of the Coleco Adam (the computer). The Coleco Adam has
enough RAM for LZW. The ColecoVision (the video game console) doesn't.
The ColecoVision executes directly from ROM chips in the cartridge.

Philipp

Your right I was thinking of ADAM. My apologies.

w..