I don't.

I write separate asm and C files.

Assemble the asm files.

Compile the C files.

Then link all of the corresponding object files generated.

Can you post the command to link all objects with gcc/g++ ?

A quick google gave me the following links:

http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
http://www.ibiblio.org/gferg/ldp/GCC...bly-HOWTO.html

for your viewing pleasure.

But separate ASM files are more convenient for what I do, and also I use NASM (which uses Intel syntax), while GCC uses GAS (which uses AT&T syntax).

I was at one point faced with the same question as you.. "What is the difference between C and C++?"

Well, C++ is C with some extra features (C++ is C = C + 1). You can write programs that will compile under g++ that are written exclusively with C libraries.

The difference between C and C++ in this way is that C is -

#include <stdio.h>
#include <string.h>

whereas C++ is

#include <cstdio>
#include <cstring>
#include <c - then - other header file minus .h extension>


Also you have "namespace"s, which allow you to access member functions of a class without the requirement of a scope resolution operator.

So, without "using namespace std;" in your source file, to print something with C++'s cout function, you would have to type -

std::cout << "stuff" << endl;

whereas with "using namespace std;"

you only have to type cout << "stuff" << endl;



On top of that you have inline functions, a cleaner way of passing values by reference, and a system of reading/writing input that is somewhat different than C. By which I mean the "string" class, which I have yet to prefer over the standard null terminated string. (my expertise is very much still a work in progress.)


inline functions are similar to macro definitions in that when you use a macro name as a function call, the code represented by the macro name is written in place of the function call. Inline functions do the same thing assuming that they can perform successfully, otherwise they behave just like a regular function. (the purpose is to avoid the function calls during run time that would be better served as just being code in a program, without the overhead of the function call.)


The "most" defining feature of C++ is the reversal, renaming, and expansion of the structure. By reversal I mean, in

struct demonstration_structure{

int everything_is_public_in_a_structure_except;


private:

int things_that_come_after_private;

};

whereas in a CLASS

class demonstration_class{

int everything_is_private_in_a_class;

public:

int except_everything_that_comes_after_public:
};


I would suggest learning C first, because just about all the "Beginning C++" books I've seen mostly cover C, but without the attention to the detail that a C book would give (for example, the book 'The C Programming Language' contains 90% of the features in "Beginning C++", which is my college book, with better examples and better explanations).

On top of that, C++ is C with some new stuff thrown in. In this respect, C is C++'s "base class", and C++ is the "derivative class".

The base class contains all of C. The derivative class contains everything the base class is + some more.


NOTES on the Linus letter - I imagine he isn't entirely incorrect, though I can consider the C vs C++ debate to be nothing unlike the glock vs 1911 debate in that both platforms work as intended, but some people can't handle one, the other, or both for some reason. From that point, people build emotions around their decision, and all meaningful conversation is lost from that point forward.

If you had to ask (meaning you didn't already know the basics and where to find the advanced info) you shouldn't try to use the info graemef linked.

When you read through that, you'll see it looks pretty hard. A lot of gnu documentation looks hard for something that is actually easy, so people try the small subset they think they understand and generally get away with it. Embedded asm is at least as hard as that documentation makes it look. Most people who try it, try the small subset they think they understand and get unreliable and confusing results.

I don't agree with MTK358's choice regarding NASM vs. gas, nor 32 bit vs. 64 bit. But I think his choice of separate asm files rather than embedded is the only sane way to learn asm.

Someday, if you are an expert asm programmer, you might want to also learn the embedded asm syntax.

http://uncyclopedia.wikia.com/wiki/C%2B%2B

What do you mean?

Hi -

I agree with Johnsfine:

1. For many reasons, I'd recommend GAS over NASM. It's a "value judgement", there is no one "right or wrong answer"; but I agree that, "in general", GAS is probably the "better choice".

2. Mtk358 - I don't understand the reference to "32 bit vs 64 bit" either.
But just to be sure we're all on the same page...
My experience is that you can do either 32-bit or 64-bit development with equal ease on any 64-bit Linux. You just can't mix'n'match 32- and 64-bit objects in the same executable

3. I agree that putting *all* of your assembly code in a *separate* file is a Good Idea. The same is true for mixing Assembly with C/C++, or mixing C and C++, or mixing C and FORTRAN: separate source files are just cleaner. Even when you *can* mix'n'match different languages in the same source file ... usually, you probably *shouldn't*

'Hope that helps .. PSM

PS:
I stand by the snarky comment I made about C++ above I agree that in skilled hands, C++ can be an excellent tool. I *don't* agree that C++ is necessarily more efficient than a lot of other languages ... even C++ programs written by good developers. And I think we *all* agree that C++ is complex, and that's it's too easy for a naive developer to make serious coding errors ... and not even realize it.

IMHO...

I don't know, I am also not quite sure which is better. I just know that GAS looks very cryptic compared to NASM.

It would be nice to have a good comparison somewhere.

At least the instructions are still all the same

No matter what I tried I could not get 32-bit ASM code to work on my 64-bit desktop.

You haven't yet tried to understand how/where from the linker pick libraries while linking.

That was regarding the choice to learn X86 assembler instead of X86_64 assembler, because tutorials are available for X86. I think that is like looking for your keys under the lamppost because the light is better there instead of looking for your keys where you dropped them.

Does that include Arch?

My experience is that you can do either 32-bit or 64-bit development with equal ease on any 64-bit Linux that I have tried so far. That does not include Arch.

Look at
http://www.linuxquestions.org/questi...-linux-801349/
We were at:
A) Don't know how to install a 32 bit libgcc.a on 64 bit Arch
B) Don't know how to use 32 bit libgcc_s.so instead of libgcc.a (though I had some idea on that which I don't think MTK358 followed up. Bottom of post 14 in that other thread.)

But it says nowhere how to do x86_64 assembler.

It's more like "looking for the keys under the lamppost instead of where you dropped them because it's pitch black away from the lamppost!".

You didn't tell me how to obtain the necessary files, preferably in Arch package format. If using a different distro would be much more practical, then maybe I'll be willing to do an Arch/(Some other more ASM programming freindly distro) dual boot.

So GAS does intel syntax, too?