Next: , Previous: , Up: Programming Tools   [Contents][Index]


5.24.5 Examining compiled code

And finally, see and friends show compiled code. Some of the things in the source code are not present in the compiled code (e.g., formatting and comments), but this is useful to see what threaded code or native code is produced by macros and Gforth’s optimization features.

see ( "<spaces>name" –  ) tools “see”

Locate name using the current search order. Display the definition of name. Since this is achieved by decompiling the definition, the formatting is mechanised and some source information (comments, interpreted sequences within definitions etc.) is lost. add further cells to backtrace stack for non-debugging engine exceptions print a backtrace for the return stack addr1..addr2 backtrace for interactive use

xt-see ( xt –  ) gforth-0.2 “xt-see”

Decompile the definition represented by xt.

simple-see ( "name" –  ) gforth-0.6 “simple-see”

Decompile the colon definition name, showing a line for each cell, and try to guess a meaning for the cell, and show that.

xt-simple-see ( xt –  ) gforth-1.0 “xt-simple-see”

Decompile the colon definition xt like simple-see

simple-see-range ( addr1 addr2 –  ) gforth-0.6 “simple-see-range”

Decompile code in [addr1,addr2) like simple-see

see-code ( "name" –  ) gforth-0.7 “see-code”

Like simple-see, but also shows the dynamic native code for the inlined primitives. For static superinstructions, it shows the primitive sequence instead of the first primitive (the other primitives of the superinstruction are shown, too). For primitives for which native code is generated, it shows the number of stack items in registers at the beginning and at the end (e.g., 1->1 means 1 stack item is in a register at the start and at the end). For each primitive or superinstruction with native code, the inline arguments and component primitives are shown first, then the native code.

xt-see-code ( xt –  ) gforth-1.0 “xt-see-code”

Decompile the colon definition xt like see-code.

see-code-range ( addr1 addr2 –  ) gforth-0.7 “see-code-range”

Decompile code in [addr1,addr2) like see-code.

As an example, consider:

: foo x f@ fsin drop over ;

This is not particularly useful, but it demonstrates the various code generation differences. Compiling this on gforth-fast on AMD64 and then using see-code foo outputs:

$7FD0CEE8C510 lit f@     1->1 
$7FD0CEE8C518 x
$7FD0CEE8C520 f@
7FD0CEB51697:   movsd   [r12],xmm15
7FD0CEB5169D:   mov     rax,$00[r13]
7FD0CEB516A1:   sub     r12,$08
7FD0CEB516A5:   add     r13,$18
7FD0CEB516A9:   movsd   xmm15,[rax]
7FD0CEB516AE:   mov     rcx,-$08[r13]
7FD0CEB516B2:   jmp     ecx
$7FD0CEE8C528 fsin
$7FD0CEE8C530 drop    1->0 
7FD0CEB516B4:   add     r13,$08
$7FD0CEE8C538 over    0->1 
7FD0CEB516B8:   mov     r8,$10[r15]
7FD0CEB516BC:   add     r13,$08
$7FD0CEE8C540 ;s    1->1 
7FD0CEB516C0:   mov     r10,[rbx]
7FD0CEB516C3:   add     rbx,$08
7FD0CEB516C7:   lea     r13,$08[r10]
7FD0CEB516CB:   mov     rcx,-$08[r13]
7FD0CEB516CF:   jmp     ecx

First, you see a threaded-code cell for a static superinstruction with the components lit and f@, starting and ending with one data stack item in a register (1->1); this is followed by the cell for the argument x of lit, and the cell for the f@ component of the superinstruction; the latter cell is not used, but is there for Gforth-internal reasons.

Next, the dynamically generated native code for the superinstruction lit f@ is shown; note that this native code is not mixed with the threaded code in memory, as you can see by comparing the addresses.

If you want to understand the native code shown here: the threaded-code instruction pointer is in r13, the data stack pointer in r15; the first data stack register is r8 (i.e., the top of stack resides there if there is one data stack item in a register); the return stack pointer is in rbx, the FP stack pointer in r12, and the top of the floating-pont stack in xmm15. Note that the register assignments vary between engines, so you may see a different register assignment for this code.

The dynamic native code for lit f@ ends with a dispatch jump (aka NEXT), because the code for the next word fsin in the definition is not dynamically generated.

Next, you see the threaded-code cell for fsin. There is no dynamically-generated native code for this word, and see-code does not show the static native code for it (you can look at it with see fsin). Like all words with static native code in gforth-fast, the effect on the data stack representation is 1->1 (for gforth, 0->0), but this is not shown.

Next, you see the threaded-code cell for drop; the native-code variant used here starts with one data stack item in registers, and ends with zero data stack items in registers (1->0). This is followed by the native code for this variant of drop. There is no NEXT here, because the native code falls through to the code for the next word.

Next, you see the threaded-code cell for over followed by the dynamically-generated native code in the 0->1 variant.

Finally, you see the threaded and native code for ;s (the primitive compiled for ; in foo). ;s performs control flow (it returns), so it has to end with a NEXT.


Next: Examining data and code, Previous: Locating exception source, Up: Programming Tools   [Contents][Index]