This chapter describes what the ITEX C Code Generator is used for, how to run it and the structure of the generated code.
When the C Code Generator has translated TTCN into C code, the code must be adapted with the system that is to be tested. The adaption process is described in Adaption of the Generated Code.
|
Note: ASN.1 support The ITEX C Code Generator supports only a limited subset of ASN.1. See C Code Generator for further details on the restrictions that apply. |
|
Note: UNIX version This is the UNIX version of the chapter. The Windows version is The ITEX C Code Generator (in Windows). |
When developing new systems or implementations of any kind, the developing process is divided into well defined phases. Most commonly, the first phases involve some kind of specification and abstract design of the new system. After a while, the implementation phase is entered and finally, when all parts are joined together, the test phase is activated.
In any case when a system is tested, we want to make sure that its behavior conforms to a set of well defined rules. TTCN was developed for the specification of test sequences. Unfortunately, as very few systems interpret or compile pure TTCN, we need to translate the TTCN notation into a language which can be compiled and executed. In the case of ITEX, the C Code Generator (CCG) translates TTCN to ANSI-C.
Even after the TTCN code has been translated, there are a couple of things that need to be taken care of. In this case, we must adapt the generated code with the system it intends to test. This chapter describes how the ITEX C Code Generator is used. The adaption process is described in Adaption of the Generated Code.
Unfortunately a test sequence description expressed in TTCN can not easily be executed as it is. This is because the test notation is not executable and only few test environments interpret pure TTCN. A different approach to create an executable test suite (ETS), is to translate the formal test description into a language which can be compiled into an executable format.
The ITEX C Code Generator (CCG) translates TTCN into ANSI-C which can be compiled by an ANSI-C compiler. Figure 219 depicts the first step in the process of creating an ETS using the ITEX C Code Generator.
The generated code, called the TTCN runtime behavior, is only one of the two major modules of an ETS.
The second module which is needed includes test support functions which are dependent on the protocol used, the host machine, test equipment, etc. For this reason, it is up to the user to write this second module and in such way adapt the TTCN runtime behavior to the system he/she wants to test.
Figure 219 : Translating TTCN to ANSI-C
|
|
The adaption process is described in Adaption of the Generated Code. Figure 220 displays the anatomy of the final result.
Figure 220 : The anatomy of an ETS
|
|
The C Code Generator (CCG) can be activated either from the ITEX Browser, both as a quick button and a menu command, or from the Organizer when a TTCN test suite is selected.
|
|
When you select Make, the TTCN Make dialog is opened. The dialog contains two important toggle buttuns, Analyze & Generate and Compile & Link. |
Figure 221 : Dialog for starting the ITEX C Code Generator
|
|
If Analyze & Generate is set, the Analyzer will first be called to analyze the test suite before any code is generated. If errors are found, these will be reported and no code will be written to file. The generation phase performed after the analysis phase will only generate code for the parts that need to be re-generated.
If code is generated, that code will reside in the directory specified in this field.
If Compile & Link is set, ITEX will also take care of the making and linking of the generated code. At this point you have the possibility to specify how you want the code to be built. Either you can specify that the default generated makefile is to be used, or your own special makefile. This is done by setting the radio buttons in the field below the Makefile toggle button.
The code generator needs to know what files to link into the executable. Three different possibilities are at hand:
The C Code Generator assumes the first case to be the default one. In this case the Generate empty adaptor files radio button is set. If you do not have adaptor files (adaptor.c and adaptor.h) in the target directory, these will be created, as empty templates, for you. If you already have generated and edited adaptor files these will of course not be overwritten.
If you already have your own compiled adaptor files elsewhere in the file system, these files, as object files, should be listed in the text field below the Use the object files dialog button. Observe that you should use absolute path names for the adaptor files to avoid problems for the makefile to find these files! An absolute path name is a path name that identifies a file uniquely from the root of the files system, for example /home/myhome/myadaptor.o.
Finally, if you want to generate code for simulation, the Use standard kernel radio button should be set with the option Simulation. This is the only available kernel at the moment so no other choice is valid here.
By pressing the CCG Options button in the Make dialog, the dialog depicted in Figure 222 will be displayed.
Figure 222 : Setting extra CCG options
|
|
makeopts in the target directory. This file is used to define settings used by the makefile. You have the flexibility to choose compiler and add extra information for the make process.You can also choose the names of the files you want to use. This is done in the fields in the lower part of the CCG options dialog.
s_type.c.s_constr.c.s_dyn.c.If the Make button is pressed, the code generator will only generate code for the parts that really need to be re-generated.
If the Full Make button is pressed, everything will be regenerated again.
When the generation phase is started, a new log window will be displayed where information about the code generator actions will be displayed. In Figure 223 such a log window is displayed.
Figure 223 : Log window displaying execution of the CCG
|
|
Figure 219 shows how ANSI-C code is generated from a TTCN test suite. The generated code alone is not executable as it needs the test support functions module (see Figure 220).
In the case of the code generated from the CCG we also need a set of static functions which handle TTCN basics and other internal events. Even if these functions are vital for the successful compilation and execution of the generated code, the user should not have to worry about this part. These functions are gathered in a small set of static files which are compiled by the generated makefile and linked with the rest of the code.
As an example, the file list below displays the file structure of generated code. As can be seen in this example, template adaptor files were created by the CCG (as can be seen by looking at the time stamps for these files).
-rw-rw-r-- 1 user 524 Feb 26 10:41 Makefile -rw-rw-r-- 1 user 7911 Feb 26 10:41 adaptor.c -rw-rw-r-- 1 user 988 Feb 26 10:41 adaptor.h -rw-rw-r-- 1 user 2492 Feb 26 10:41 ccgmkst -rw-rw-r-- 1 user 10217 Feb 26 10:41 s_aux.c -rw-rw-r-- 1 user 5334 Feb 26 10:41 s_aux.h -rw-rw-r-- 1 user 26811 Feb 26 10:41 s_constr.c -rw-rw-r-- 1 user 2415 Feb 26 10:41 s_constr.h -rw-rw-r-- 1 user 11225 Feb 26 10:41 s_decl.c -rw-rw-r-- 1 user 1069 Feb 26 10:41 s_decl.h -rw-rw-r-- 1 user 73273 Feb 26 10:41 s_dyn.c -rw-rw-r-- 1 user 1199 Feb 26 10:41 s_dyn.h -rw-rw-r-- 1 user 11583 Feb 26 10:41 s_type.c -rw-rw-r-- 1 user 2104 Feb 26 10:41 s_type.h
The makefile is the file containing a definition of how the code should be compiled and linked.
The adaptor.h and adaptor.c files are the files that contain the adaptation code. If code is generated for the first time, these files will be generated by the code generator with empty function templates for the user to implement. On the other hand, if these files are present in the target directory the user does not have to worry about getting them overwritten.
The ccgmkst is a file used by the code generator to know the status of the generated files. It is used to allow the code generator to calculate which files need to be re-generated and which do not.
The s_aux.c and s_aux.h files are files containing auxiliary functions and definitions used when running the code.
The s_type.c and s_type.h files contain code dealing with type definitions derived from the definitions in the test suite.
The s_decl.c and s_decl.h files contain code dealing with declarations derived from declarations in the test suite.
The s_const.c and s_const.h files contain code for the constraints defined in the test suite.
The s_dyn.c and s_dyn.h files contain information derived from the dynamic part in the test suite.
We will now take a look at a simple example of the makefile. The following makefile is the generated makefile for the simple example in The Code Files.
##
## Name: Makefile
##
## Creator:
## CCG
##
## Description:
## This file is generated by the ITEX Code Generator.
## Please do NOT edit the file or your changes will go away!!
##
staticdir = $itexlib/ccg
include $(staticdir)/makeopts
objs = \
s_aux.o \
s_type.o \
s_decl.o \
s_constr.o \
s_dyn.o \
adaptor.o
staticobjs = \
$(staticdir)/gci.o \
$(staticdir)/static.o \
$(staticdir)/valrep.o
default: $(objs) $(staticobjs)
$(CC) -o Phones $(objs) gci.o static.o valrep.o
Observe that the makefile knows which objects are local and which are static. The static files are fetched from the ITEX installation directory.
The second command row in the makefile includes a makeopts file. Below is an example of how such options file could look like.
CC = gcc CINCLUDES = -I$itexlib/ccg CFLAGS = -ansi $(CINCLUDES)
As can be seen we can define the compiler to be used and also which flags to use to have a correct compilation.
We are now ready to deal in greater detail with the adaptation phase which is the final phase to create an executable test suite. The adaptation process is described in Adaption of the Generated Code.