Assembler Code

With Imagix 4D, you can examine C, C++ and Java source code that is used together with code implemented in other languages, such as FORTRAN or assembler.

The Imagix 4D analyzer will process just the C, C++ and Java source files, along with any associated files they include or import. Calls to functions implemented in other files using other languages are handled just like calls to library functions; you can examine the declaration of the function and every instance where it was called, but can't see the definition of and hierarchy beneath the function itself.

When properly configured (see `Language Extensions'), the Imagix 4D C/C++ analyzer handles inline assembler that has been identified through the keyword asm or _asm. The analyzer skips over the assembler code and continues analyzing at the end of the assembler block.

Since assembler code is usually used for implementing performance-critical functions at the bottom of the calling hierarchy, this is often satisfactory. However, you may decide you want to browse to the actual assembler code for the functions called from your C or C++ source code. If so, you can create datafiles containing the information necessary for browsing, and import these datafiles into Imagix 4D.

Consider the following assembler code:

PFPROC          TRAP08
                PUSHF
                CALL    DWORD PTR CS:[OLD08]
                CLI
                PUSHM   <ES,BX>
                LES     BX,CS:InDOS
                CMP     BPTR ES:[BX],0
                POPM    <BX,ES>
                IRET
ENDPROC
PFPROC          TRAP28
                MOV     CS:TryPop,FALSE
                MOV     CS:InPop,TRUE
                STI
                CALL    START
                CLI
                MOV     CS:AllowPop,TRUE
                MOV     CS:InPop,FALSE
                JMP     DWORD PTR CS:OLD28
ENDPROC
To enable browsing, you need to provide the file and line number for where the function definitions occur in assembler code. Assuming that TRAP08 and TRAP28 were invoked in the C code as _asm_Trap08 and _asm_Trap28 respectively, then you'd create a .vdb file consisting of the following lines:

GD /#root/usr/examples
GD /#root/usr/examples/asm
GF /#root/usr/examples/asm/foo.asm
SP /usr/examples/asm
</#root/usr/examples/asm/foo.asm
Gf ./_asm_Trap08
Sl 2
Gf ./_asm_Trap28
Sl 13
>
The first line indicates that a new symbol is being generated (G), that the symbol is a directory (D), that the symbol is contained in the current symbol /#root/usr, and that the symbol's name is examples. The second line repeats this for the next directory level, asm.

Line three also repeats this, except that the symbol is a file (F), named foo.asm.

The fourth line sets (S) the path (P) attribute of the current symbol, foo.asm, to /usr/examples/asm.

The fifth line starts with a <, indicating that a new replacement section is starting, and that the section focuses on the symbol /#root/usr/examples/asm/foo.asm. The /#root signifies the start of the path, and should be followed by the normal path name. Under Windows, you might use a path such as /#rootc:/examples/func_ptr/foo.c.

Line six indicates that a new symbol is being generated (G), that the symbol is a function (f), that the symbol is contained in the current section for the symbol foo.asm (./), and that the new symbol's name is _asm_Trap08.

The seventh line sets (S) the line number (l) attribute of the current symbol, _asm_Trap08, to 2, meaning that _asm_Trap08 is defined at line 2 of whatever file it is defined in.

Lines eight and nine repeat the process, specifying the definition and line number for the next function.

Line ten terminates the current section, foo.asm.