Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In those days was indeed 1983. None of the many C compilers I had access to at the time could do it in one command. Everyone I showed it to was surprised and pleased that it could be done in one command. I was in the DOS world, not Unix. Very few DOS programmers had any experience with Unix, or any access to a Unix machine. This was long before Linux.

> Try what? I know (and mentioned) two distinct ways of looking at the assembly code produced by my C compiler

Do you find:

    cc -c test.c
    objdump -d test.o
faster or slower to type than:

    dmd -c test.c -vasm
especially when using command completion? For me, it's no contest, especially when doing it repeatedly, and with command completion.

Besides, I like the concise output of -vasm:

    foo:
    0000:   89 F8                    mov       EAX,EDI
    0002:   01 C0                    add       EAX,EAX
    0004:   C3                       ret
better than objdump's:

    test.o:     file format elf64-x86-64


    Disassembly of section .text:

    0000000000000000 <foo>:
       0:   55                      push   %rbp
       1:   48 89 e5                mov    %rsp,%rbp
       4:   89 7d fc                mov    %edi,-0x4(%rbp)
       7:   8b 45 fc                mov    -0x4(%rbp),%eax
       a:   01 c0                   add    %eax,%eax
       c:   5d                      pop    %rbp
       d:   c3                      retq


For all but the smallest work I don't think it actually makes any difference. I always dump the disassembly to a file so I couldn't care less where it comes from, when debugging real code at least.

Testing the code generator is a different question, which I hope will be helped by vasm since I've actually had to move demonstrations off dmd and onto GCC since the code was so bad (in particular bad register allocation, I'm not that bothered about redundant cmp-s).


I've always preferred MASM output compared to whatever it is GNU does by default.


I find

    cc -S test.c
fastest to type.


You forgot the:

    cat test.s


For actual analysis as opposed to cutesy blog post demos I'd actually use

    vi test.s
But if you insist on doing things the hard way on stdout, GCC has got you covered as well. Add -o - to the command line.


Then I get:

        .file   "test.c"
        .text
        .globl  fn
        .type   fn, @function
    fn:
    .LFB0:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret
        .cfi_endproc
    .LFE0:
        .size   fn, .-fn
        .ident  "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4"
        .section        .note.GNU-stack,"",@progbits
No thanks.


<shrug> At this point we have reduced your blog post's message from "Look at this amazing new feature! It's so novel and unique! All other compiler developers are complete idiots!" to "Sometimes when I read assembly code I'm not interested in debug information.". I am happy to concede this point.


There is rather a lot of garbage in those .s files for things like debuginfo, stray comments the GCC developers accidentally put in their asm output, linker commands, etc.

On the other hand it properly shows relocations (like global variable references) which disassemblers tend to get wrong.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: