4 ms·

> But to build a compiler, you need to be able to see the output. A disassembler had to be built along with the compiler. Until very recently the dominant para

by disas 5y ago

> But to build a compiler, you need to be able to see the output. A disassembler had to be built along with the compiler. Until very recently the dominant paradigm, at least for ahead-of-time compilers on Unix, was to emit textual assembler code and run a separate assembler on it behind the scenes. No disassembler needed, you can ask GCC or LLVM based compilers to just give you the intermediate data with -S. > But running obj2asm is a separate process, and the output is filled with all the boilerplate needed to create a proper object file. The boilerplate is rarely of interest, and I’m only interested in the generated code for a function. Sounds like a bug in obj2asm. GNU objdump, for example, has handy -d and -D flags for disassembling only the code for one or all symbols. > One would think that the way to do this would be to have the compiler generate the assembler source code, which would then be run through an assembler like MASM or gas to create the object file. I figured this would be slow and too much work. It was fast enough even for the very first C compilers... <checks calendar> 40 years ago. For actual compilations. Not to mention that when you as a human want to read the assembly code, it doesn't matter how "slow" the -S flag's output is. No matter how "Alpha" you are, the bottleneck will be you, the human. > Instead, the disassembler logic actually intercepts the binary data being written to the object file and disassembles it [...] I am not aware of any other compiler that does this in the same way. The HotSpot JVM has -XX:PrintAssembly and -XX:CompileCommand=ClassName.methodName flags that do this in the same way. Just like the author, I am not aware of any other, other compiler that does this in the same way. Because just like the author I haven't bothered to check. But if I had to bet, I would bet that all major just-in-time compilers do this in the same way.

WalterBright 5y ago
Yes, indeed, there are other ways to look at the assembler output. I've been doing that for 40 years. I heard the same things when D added builtin unittests, and builtin documentation generator. But we discovered that when things are builtin, and very convenient, it changes things dramatically. I suggest you try it before dismissing it. It's changed the way I work, and has started changing the way others do, too. > It was fast enough even for the very first C compilers... <checks calendar> 40 years ago. I actually did write a C compiler 40 years ago. Emitting assembler would mean another round trip to the floppy disk, and one might even have to swap floppies to do it. It would have been slowed to the point of making the compiler uncompetitive. Even if one forgave MASM for being miserably slow, as it had a linear symbol table and was multipass itself. Consider also that in those days, compilers did not run the linker. You compiled the code with one command, and linked with another. Mine (Datalight C) would do both in one step. After seeing that, every other compiler vendor did the same thing. Thanks for the tip on what Hotspot does. That seems to have been added starting with JDK8, after I had stopped working with Java. When I used it, one had to use the debugger.
- 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
disas 5y ago
> the very first C compilers... <checks calendar> 40 years ago Ah. Checking the calendar is not sufficient, one should also be able of doing correct arithmetic. 1972 was 50 years ago, not 40.

by disas 5y ago

WalterBright 5y ago

Yes, indeed, there are other ways to look at the assembler output. I've been doing that for 40 years. I heard the same things when D added builtin unittests, and builtin documentation generator. But we discovered that when things are builtin, and very convenient, it changes things dramatically. I suggest you try it before dismissing it. It's changed the way I work, and has started changing the way others do, too. > It was fast enough even for the very first C compilers... <checks calendar> 40 years ago. I actually did write a C compiler 40 years ago. Emitting assembler would mean another round trip to the floppy disk, and one might even have to swap floppies to do it. It would have been slowed to the point of making the compiler uncompetitive. Even if one forgave MASM for being miserably slow, as it had a linear symbol table and was multipass itself. Consider also that in those days, compilers did not run the linker. You compiled the code with one command, and linked with another. Mine (Datalight C) would do both in one step. After seeing that, every other compiler vendor did the same thing. Thanks for the tip on what Hotspot does. That seems to have been added starting with JDK8, after I had stopped working with Java. When I used it, one had to use the debugger.

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

disas 5y ago

> the very first C compilers... <checks calendar> 40 years ago Ah. Checking the calendar is not sufficient, one should also be able of doing correct arithmetic. 1972 was 50 years ago, not 40.