«

"Boon" <root@localhost> wrote in message
news:48b0559a$0$1281$...
> 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...

"raashid bhatt" <> wrote in message
news:da9241f1-e02b-4943-bd52-...
> 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...

"Lassie" <> writes:
> "Keith Thompson" <kst-> schreef in bericht
> news:...
>> 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) kst- <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"

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

"Keith Thompson" <kst-> schreef in bericht
news:...
> 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.

Bartc wrote:

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

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.

"santosh" <> wrote in message
news:g8r80g$5rg$...
> Bartc wrote:
>
>> "Richard Heathfield" <> wrote 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

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.

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

Keith Thompson wrote:
> 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.

Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late? By wrong, I
don't mean an inaccurate answer that is acceptably close to the true
value; I mean an answer which is unacceptably far away from the true
value.