4 ms·

> I suggest you try it before dismissing it. It's changed the way I work, and has started changing the way others do, too. Try what? I know (and mentioned) two

by disas 5y ago

> I suggest you try it before dismissing it. It's changed the way I work, and has started changing the way others do, too. Try what? I know (and mentioned) two distinct ways of looking at the assembly code produced by my C compiler. It doesn't matter to me how -S is implemented because even if it's "slow" I am physically unable to count nanoseconds. I also know (and mentioned) that I know how to dump disassembly from HotSpot's memory. Yes, it's useful. > Consider also that in those days, compilers did not run the linker. You compiled the code with one command, and linked with another. Not sure what "those days" you mean. Running a single "cc" command and getting a single executable seems to have been well established by 1978: https://archive.org/details/TheCProgrammingLanguageFirstEdition/page/n13/mode/2up https://archive.org/details/TheCProgrammingLanguageFirstEdit... https://en.wikipedia.org/wiki/Datalight https://en.wikipedia.org/wiki/Datalight says that Datalight was founded in 1983; I have no way of telling whether you had started developing your compiler well before that.

WalterBright 5y ago
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
- mhh__ 5y ago
  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).
- disas 5y ago
  I find cc -S test.c fastest to type.
  - WalterBright 5y ago
    You forgot the: cat test.s
    - disas 5y ago
      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.
      - WalterBright 5y ago
        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.
        disas 5y ago
        <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.

by disas 5y ago

WalterBright 5y ago

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

mhh__ 5y ago
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).
disas 5y ago
I find cc -S test.c fastest to type.
- WalterBright 5y ago
  You forgot the: cat test.s
  - disas 5y ago
    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.
    - WalterBright 5y ago
      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.
      - disas 5y ago
        <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.