C++ source code compilation

[Rui Maciel]

wrote:

An object files' purpose is to be read by a piece of software known as a
linker. An object file contains pointer tables and stuff like that and it
cannot be read by any machine cpu.
Object code has been well documented. Just search the web for the
appropriate documets for ELF and COFF files to find out the deifnition of
two common object files.

I've asked you about your definition of machine code and object code.
Instead you wrote about object files and their file formats. Could you now
provide your definition of machine code along with your definition of object
code?


Rui Maciel

 

[gwowen]

I've asked you about your definition of machine code and object code.
Instead you wrote about object files and their file formats.  Could younow
provide your definition of machine code along with your definition of object
code?

Do not feed the troll. He's already unleashed one blast of homophobic
abuse on one person in this thread (and countless others at other
times) and yet people go on feeding him -- what on Earth makes you
think he'll react coherently or intelligently to you.

 

[88888 Dihedral]

An object files' purpose is to be read by a piece of software known as a
linker. An object file contains pointer tables and stuff like that and it
cannot be read by any machine cpu.
Object code has been well documented. Just search the web for the
appropriate documets for ELF and COFF files to find out the deifnition of
two common object files.

Yes, object files free in tinny C and portable C are somewhat different
from MSVC in using most machine instructions to produce object files
to be linked to run on ARMS, PPC, MIPS, PS3CELL(8cores), WII and etc..

 

[John Bokma]

Do you want to suck Leigh the ****** jonstons dick you little fuckin
hoofter?

Don't cooment on me again unless you undestand what your fuckin talking
about you little fuckin ******.

You couldn't have made a stronger case to justify the warning. Off you
go.

 

[Jorgen Grahn]

He is right. GCC is notoriously organized in front-ends, which translate
any given programming language into an intermediate language which is
supported by GCC (it appears to support at least 3 intermediate languages),
and back-ends, which translate code written in those intermediate languages
into machine code for a specific target platform.

This approach may appear an "unnecessary complication" at first. Yet, this
approach means, at least in theory, that you only need to write a new GCC
front-end in order to get your new programming language to be supported in
every platform supported by GCC, and it also means that you only need to
write a new GCC back-end in order to offer support for each and every
programming language supported by GCC in a brand new target architecture.

Also, by relying on an intermediate implementation it is also possible to
perform all sorts of code optimization on a single piece of data and yet
reap benefits from that optimization when writing code in any programming
language supported by GCC and when targetting any platform supported by GCC.

I am aware of all this, but passing through the stage "x86 assembly
source code" (which was what someone suggested, in the part you
snipped) brings none of the benefits you mention. I don't think it's
done.

/Jorgen

 

[Juha Nieminen]

asm is the closest thing to cpu intructions, what i call opcodes. And I more
or less agree that anything you can do in C++ can be done in asm but I
wouldn't be too fast to jump into an argument about that.

But the main point is that the compilation process nothing to do with
machine code, the compiler comiles to object code. So asm doesn't come into
the equation.

Is that your way of saying "I was wrong, you are right"?

 

[Juha Nieminen]

Could you do a favor to other people (whose killfiles are working) and
restrain yourself from answering Paul's posts?

Why?

If he spouts complete nonsense and nobody rectifies it, a third-party
reading the thread might end up believing it. After all, if he makes a
claim and nobody responds to it, the claim must therefore be correct and
accepted by everybody else, doesn't it?

The purpose of killfiles is to filter out spam.

 

[Juha Nieminen]

Yes it is that ridiculous to suggest that machine code is and object code is
the same thing.

You see what you did there? The original claim was "object files contain
machine code". Now you have changed it to "an object file and machine code
are the same thing".

 

[Ian Collins]

Why?

If he spouts complete nonsense and nobody rectifies it, a third-party
reading the thread might end up believing it. After all, if he makes a
claim and nobody responds to it, the claim must therefore be correct and
accepted by everybody else, doesn't it?

The purpose of killfiles is to filter out spam.

As well as idiots.

 

[Tobias Müller]

Hi Juha and Leigh,

Could you do a favor to other people (whose killfiles are working) and
restrain yourself from answering Paul's posts?

Thanks!
Paavo

If you subtract all that profanity, Pauls arguments are usually not even
that bad. I mean, he is actually right. A compiler produces object code.
Object code however may contain (and usually does) a special form of
machine code (relocatable, not directly executable). So both are right and
there is really no need for such stupid "discussions" that just drive away
people (especially the new ones) from this list.

I know, Paul has a bad reputation, but it does not feel right to "warn"
other people (that don't know him already) from responding to him. He will
probably write something anyway, so give him a chance to write something
useful.

Tobi

PS: Paavo, I just used your post as a starting point, but you're obviously
not the one that I meant with most of the comments.

 

[gwowen]

I know, Paul has a bad reputation, but it does not feel right to "warn"
other people (that don't know him already) from responding to him.

So don't do it then. I, however, have no qualms about warning people
about sociopaths.

 

[gwowen]

  The purpose of killfiles is to filter out spam.

Killfiles predate spam.

 

[Juha Nieminen]

If you subtract all that profanity, Pauls arguments are usually not even
that bad. I mean, he is actually right. A compiler produces object code.
Object code however may contain (and usually does) a special form of
machine code (relocatable, not directly executable).

You could make the same argument from executable files as well. In most
modern operating systems an executable file is not something that is simply
loaded into memory and executed without modification. Instead, executables
are loaded and modified by a dynamic linker (which is, basically, a routine
that loads the contents of the executable and then modifies it so that far
jumps, shared library calls and system calls point to the proper places).

The executable file still contains machine code. Just because some
*addresses* inside this machine code are modified at the loading stage
doesn't make it less machine code.

An object file is typically no different. It's just a different routine
(in this case usually a static linker) which does the modifications (in order
to build the final executable binary).

 

[Rui Maciel]

wrote:

I just told you that object code is already well defined in several
different formats, it's not place to define it.

Machine code is code that can be read by a processor.

I've asked you what was your definition of what object code is, and instead
of providing your personal definition of what object code is, you opted to
talk about file formats used to define object files, completely avoiding the
question which has been repeatedly made.

So, as you've pointed out that your definition of machine code is "code that
can be read by a processor", are you actually able to provide your personal
definition of what object code actually is?


Rui Maciel

 

[Juha Nieminen]

Absolute bollocks and total bullshit.

Nicely argumented. (You probably don't even know what a dynamic linker is.)

Plonk.

Do you know how many times you have said that in response to a post of
mine, yet you still haven't done it?

 

[Juha Nieminen]

No both are not right. Object code is not machine code, it may contain code
that resembles machine code but it's not machine code as it cannot be read
by any cpu on this planet.

I think I know what happened here. When someone said that an object file
contains compiled machined code, you erroneously thought that he meant that
an object file is directly executable as-is. Thus in your typical sociopath
manner you loudly and proudly objected to the notion.

Later you perhaps realized your mistake (in other words, object files
do typically contain compiled machine code, which the linker uses to build
the final executable), but now it's too late, you can't admit your mistake
and now you are, as usual, making a fool of yourself trying to weasel
yourself out of yet another situation, but only digging a deeper and
deeper hole.

This became pretty clear when you opposed the claim that executable files
are also modified at startup by the OS (using a so-called dynamic linker,
which sets far jump and system function addresses appropriately), and hence
are in this sense somewhat similar to object files. If you had made a
wikipedia search for "dynamic linker" and read the article instead of
spouting nonsense, you would have saved yourself yet another instance of
embarrassment, but of course that kind of behavior is impossible for you.

 

[Juha Nieminen]

This is of course as incorrect as saying the sky is not blue. An object file
is not machine code because for a start its format and layout are not
suitable for being read by any cpu.

That's your mistake. You equate "produces machine code" with "creates
a file that can be run as-is by the CPU".

Not even .exe files are like that. They require a dynamic linker in
order to run. Both object files and executable files contain machine code.

plonk

You keep using that word. I don't think you understand what it means.

 

[Juha Nieminen]

and now you are, as usual, making a fool of yourself trying to weasel
yourself out of yet another situation, but only digging a deeper and
deeper hole.

Btw, I'm curious to see how long it will take before you start a new
thread where you try to defend your mistake and insult everybody with
namecalling. My bet is that at most 48 hours.

 

[88888 Dihedral]

"Paul"


I think I know what happened here. When someone said that an object file
contains compiled machined code, you erroneously thought that he meant that
an object file is directly executable as-is. Thus in your typical sociopath
manner you loudly and proudly objected to the notion.

Later you perhaps realized your mistake (in other words, object files
do typically contain compiled machine code, which the linker uses to build
the final executable), but now it's too late, you can't admit your mistake
and now you are, as usual, making a fool of yourself trying to weasel
yourself out of yet another situation, but only digging a deeper and
deeper hole.

This became pretty clear when you opposed the claim that executable files
are also modified at startup by the OS (using a so-called dynamic linker,
which sets far jump and system function addresses appropriately), and hence
are in this sense somewhat similar to object files. If you had made a
wikipedia search for "dynamic linker" and read the article instead of
spouting nonsense, you would have saved yourself yet another instance of
embarrassment, but of course that kind of behavior is impossible for you.

Are you talking about trivial terms or names in writing compilers for
virtual machines ?

 

[Nick Keighley]

Actually compilers [...] probably produce a kind of "intermediate" form
[...] which is then optimized and compiled into asm.

or directly into machine code.
---------------------------------------------------

Compilers to not output machine code or asm , a compilers output is object
code.

Is this an other idiot thats gonna try and argue that machine code is object
code ?

It is a view I hold but I'm not going to argue it with you.
Perhaps I include "linker" in "compiler" if it makes you happy.