ASM is easier than believed

[Colonel Kernel]

In what sense could C possibly be more powerful then assembly? It might have many other good sides, but nothing is more powerful then pure asm.

I'm sure that C and assembly are Turing-equivalent. But then again, Brainfuck probably is too -- that doesn't mean it's more expressive or "powerful".

There are things you can only do in assembler, so in that sense it's more "powerful" than C. But you can express complex things with much less code in C (and even moreso in other high-level languages), making it more "powerful" in that sense than assembler. It depends on your needs and your point of view.

Personally, I think everytime this debate comes up, people stop comparing programming languages and start comparing their genitals, but that's just my opinion...

[Solar]

Ah, the old ASM vs. C (vs. C++) argument and which one is the most "powerful" or "efficient" programming language.

Define "powerful". Define "efficient".

It might be "powerful" and "efficient" to twiddle each individual bit of memory using opcodes hand-selected for the specific task.

It might be "powerful" and "efficient" to whip up int main() { printf( "Hello World!\n" ); return 0; } and be done with it.

It might be "powerful" and "efficient" to create classes and templates that enable your co-developers to harness vast functionalities using interfaces that are intuitive to them.

There is no overall best programming language. There are only better and worse choices for a specific task at hand, and some of the reasons involved don't even have anything to do with technical merit, but such profane things as that you already have personell trained in one language but not another.

[bubach]

Personally, I think everytime this debate comes up, people stop comparing programming languages and start comparing their genitals, but that's just my opinion...

lmao. fyi, i actually like c, it's just that my disgust with gcc and at&t syntax knows no limits.

[Brynet-Inc]

GAS has been able to use Intel Syntax assembly for quite awhile now, Not a valid reason anymore..

GCC can even produce Intel syntax assembly, Granted with the appended prefixes:

Code: Select all

gcc -S -masm=intel -c new.c -o output.asm

new.c:

Code: Select all

int main(void) { return 0; }

output.asm(Intel):

Code: Select all

.file   "new.c"
        .text
        .globl  main
        .type   main, @function
main:
        push    %ebp
        mov     %ebp, %esp
        sub     %esp, 8
        and     %esp, -16
        mov     %eax, 0
        sub     %esp, %eax
        mov     %eax, 0
        leave
        ret
        .size   main, .-main

output.asm(AT&T):

Code: Select all

.file   "new.c"
        .text
        .globl  main
        .type   main, @function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        movl    $0, %eax
        subl    %eax, %esp
        movl    $0, %eax
        leave
        ret
        .size   main, .-main

Neither syntax's are very.. complicated

[Combuster]

thats still no intel syntax with all the %'s, more like ATT syntax in reverse

[Solar]

You see, it's preferences. I actually like the AT&T syntax for its more explicit qualifiers, and because I am allergic to thinking backwards for the computer's sake. (Same with if ( constant == variable ), I get raging bloodlust when I see that.)

But that's kind of proving my point, isn't it? C is one language, C++ is another. "ASM" is a catch-all name for dozens of different languages, most of them non-trivially different from one another.

It's easier if all you're doing is programming for a hobby. But as soon as you start doing a return-on-investment calculation about your spare time - for example because you have to feed a family or simply because job prospects are looking grim - I, personally, cannot bring myself to investing the countless hours necessary for really mastering e.g. AT&T i386 assembler just to find out my next employer requires SPARC skills or Intel syntax i386. I rather spend the time improving my HLL skills.

I consider this one of the major weaknesses of the ASM language. You simply cannot take your ASM skills elsewhere, they are like an island. People keep telling me that learning LISP makes you a better SW designer, but even that seems like a too long shot for me when I could learn e.g. Python instead.

[XCHG]

I consider this one of the major weaknesses of the ASM language. You simply cannot take your ASM skills elsewhere, they are like an island.

So you mean you can code Linux applications with a Windows C compiler? You have to have a Linux C compiler in order to be able to use Linux API. So a C programmer, to be able to code in different operating systems, downloads a C compiler for that OS. I don't call this knowledge, which is taken to different places. I call this information. You know what compiler you should use and this is not knowledge. Knowledge is in Assembly when you know what value should be put in GPRs and how in order to be able to invoke a specific Linux API or how your parameters should be put in the stack to be able to call Windows API.

This topic is not going to get anywhere and will just end in further debate. But please, don't speak ill of Assembly. Assembly created your beloved language C. Respect your grandparents.

[Solar]

So you mean you can code Linux applications with a Windows C compiler?

XCHG, you missed the point completely. This has nothing to do with Windows vs. Linux.

I did my first steps with C/C++ on the Commodore Amiga / 68k. I had lessons in C/C++ on MSVC / x86. Today I am working as a professional C++ developer on Solaris / SPARC. I am still using the same language, and I could start coding some app for x86_64 without having to look up details of that architecture first. In fact, chances are good I could port stuff I wrote fifteen years ago to any other machine with a mere fraction of the original effort involved. That is the power of HLL.

By no means am I talking ill about assembly. I highly respect people who honed their ASM skill, and I know that they are, in their way, much more advanced programmers than I am. I also am aware that, in the beginning, there was only machine code (not even ASM, but raw hex if you know what I mean).

But as much as you ask me not to speak ill of assembly, I ask you just as much not to disregard the different powers that a high-level language gives you. They are simply two different beasts best employed in two different areas of software engineering. Other parts on the software map yet are best explored using some scripting language. None of these is inherently more or less powerful than the others, just different.

[Brynet-Inc]

thats still no intel syntax with all the %'s, more like ATT syntax in reverse

GCC might not be able to produce code without the prefix's(%'s) automatically.. But it can accept code without them:

Command(Intel):

Code: Select all

gcc -c -S -masm=intel new.c -o output.asm

Command(AT&T - Default):

Code: Select all

gcc -c -S -masm=att new.c -o output.asm

new.c:

Code: Select all

int main(void) { /* returns 0..*/
        asm(".intel_syntax noprefix");
        asm("mov eax, 0");
        asm(".att_syntax");
}

output.asm(Intel):

Code: Select all

        .file   "new.c"
        .text
        .globl  main
        .type   main, @function
main:
        push    %ebp
        mov     %ebp, %esp
        sub     %esp, 8
        and     %esp, -16
        mov     %eax, 0
        sub     %esp, %eax
#APP
        .intel_syntax noprefix
        mov eax, 0
        .att_syntax
#NO_APP
        leave
        ret
        .size   main, .-main

output.asm(AT&T):

Code: Select all

        .file   "new.c"
        .text
        .globl  main
        .type   main, @function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        movl    $0, %eax
        subl    %eax, %esp
#APP
        .intel_syntax noprefix
        mov eax, 0
        .att_syntax
#NO_APP
        leave
        ret
        .size   main, .-main

As you can see, GCC does accept normal Intel Syntax code as long as you remember to switch back to AT&T syntax so code generated after it by the C compiler assembles successfully.

As you can see, It wouldn't be very hard to use GAS to assemble Intel Syntax code even without using C..

I use C.. I like Assembly, I actually think the two play nicely together.. Like very close friends?

[Alboin]

The thing with GCC is, however, that it's so.....AT+T UNIX-like. When I use it, it almost makes me cringe.....even if it can do Intel syntax, it still has that feeling of AT+T.....There's no escaping it...

[mystran]

Can someone please explain what AT&T versus Intel syntax even matter?

I personally can read AT&T faster, having read more of it. I personally can write AT&T and would have to relearn some stuff to be able to write intel syntax.

It used to be the opposite. Back in the days of DOS, if you'd given me AT&T assembler, I'd been lost, while I could easily read Intel syntax.

So it's really just a question of bothering to learn the few differences. For most purposes it's enough to know that:

Code: Select all

 - prefix registers with %, prefix immediates with $, not too different from BASIC
 - source operand first, destination second:
      mov $0, %eax    # move 0 to eax
 - immediate without $-prefix is address:
      mov globalvar,%eax  # load memory at "globalvar" into %eax
 - if your address is in register, put parens around it:
      mov (%eax), %eax  # load memory at "%eax" into %eax
 - if you want both, put register after immediate:
      mov -1(%eax), %eax   # load memory at %eax-1 into %eax
 - if you want two registers, use a comma
      mov -1(%eax,%ebx), %eax # load memory at %eax+%ebx-1 into %eax
 - and finally, you wanna scale the second register
      mov -1(%eax,%ebx,4),%eax # load from %eax+4*%ebx-1 into %eax

The only other thing then, is that you put characters (most often b and l for byte and long) after opcode's name if data size isn't obvious without..

Code: Select all

       movl $0, location     # move long $0 into location
       movb $0, byteloc     # move byte $0 into byteloc

It takes about 3 days of reading and writing that systax before you stop thinging about it.


edit: oh and let me add that GAS actually has a pretty powerful macro language of it's own in addition to allowing you to use C-macros if you want... so it's not like GAS forces you to write like your compiler does.

[bubach]

meh.. it's still a pile of crap. (hi, my name is christoffer and i am a weenie..)

[Zenith]

I will never understand AT&T...

I'll just stick with Intel, thank you very much

[AndrewAPrice]

There was an adventure game made in bf.. Maybe we should branch the language and change the specification so it meets these.

[os64dev]

I will never understand AT&T...

I'll just stick with Intel, thank you very much

Saying that you will never understand something might refer to your intelligence so be carefull with those expressions . I also use to be pro Intel and found the AT&T syntax to be 'unreadable' but when i started to program with GCC and found out how nice AS and CC worked together i force myself to use/learn the AT&T syntax. Though still Intel has my preference because of the assignment order, AT&T seems to be the odd duck of the three:

Code: Select all

make x equal to y:

C/C++: x = y;
Intel: mov eax, edx    /* eax = x and edx = y */
AT&T : mov %edx, %eax  /* eax = x and edx = y */

But each person has his/her own preference..