What assembler code is generated by C instruction X?
| Hello net.land:
| I need to find out what assembler code is generated by compilers/optimizers.
| The first thing that comes to mind is: compile x programs and look at the
| assembler output. This is highly inefficient for various reasons: much of
| the code would be duplicated (who needs to wade through the assembler
| generated by passing a parameter by reference 200 times?), a real program
| converts to possibly thousands of lines of assembler and some C instructions/
| constructs will most likely be missing.
This problem is essentially unsolvable in the general case. You
didn't restrict the bounds to a particular machine or set of compiler
implementations, so you have to consider every possible compiler that
calls itself an optimizing compiler, and you have to check every
release, since new optimizations are added all of the time. In
addition for multiple target compilers, you have to consider each
target serparately (I've gotten radically different code from GCC
depending on the machine dependent portions).
| The next thing that comes to mind is a bare bones program whose whole purpose
| is to use each C instruction/construct once, with function and/or variable
| names such that the particular item can be quickly located in the (many)
| lines of assembler generated. This would make it relatively easy to
| connect assembly code with the C instruction that generated it, for any
| compiler/cpu type, without extraneous garbage in the way.
| Has anybody seen something like this? I'd rather not duplicate effort if
| someone has even parts of this. Taking care of every case of indirection,
| double indirection, types, sizes etc... is likely to be not a trivial
As pipelined and/or superscaler chips come out, this is can be
impossible because the compilation system may interleave instructions
from different statements. For example on the MIPS system, there is a
1 cycle delay from the load until the value appears in a register, and
multiple cycles for multiply. Thus, the simple code:
a = b * c;
d = e + f;
Produces the following interleaved instructions:
[foo.c: 4] 0x0: 8f8e0000 lw t6,0(gp) ; b
[foo.c: 4] 0x4: 8f8f0000 lw t7,0(gp) ; c
[foo.c: 5] 0x8: 8f990000 lw t9,0(gp) ; e
[foo.c: 4] 0xc: 01cf0019 multu t6,t7 ; (hi,lo)<- b*c
[foo.c: 5] 0x10: 8f880000 lw t0,0(gp) ; f
[foo.c: 5] 0x14: 00000000 nop
[foo.c: 5] 0x18: 03284821 addu t1,t9,t0 ; e+f
[foo.c: 5] 0x1c: af890000 sw t1,0(gp) ; d
[foo.c: 4] 0x20: 0000c012 mflo t8 ; b*c
[foo.c: 4] 0x24: af980000 sw t8,0(gp) ; a
[foo.c: 4] 0x28: 00000000 nop
[foo.c: 6] 0x2c: 03e00008 jr ra ; return
[foo.c: 6] 0x30: 00000000 nop ; delay slot
| Such a program could be the "training" part for a universal de-compiler.
| Once the assembler output of a specific compiler/cpu type has been generated
| from this program, the de-compiler could then re-generate the original
| C source (within limits). Part 2 would obviously be more difficult to
| implement and I suspect such a thing only exists now for specific cpu
| types (and for significant $s too). In any case I'm only interested in the
| "training" part now.
I suggest instead using the symbolic debug information. If your
compiler does not support full optimization and debugging, consider
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?