Chapter 10  Code generation

When the adequation has been performed, code may be generated for the main architecture.

Warning: To generate code, it is mandatory to define a processor of the main architecture as the main operator (cf. section 6.3.2).

10.1  To generate the code

From the Code menu, choose the Generate Executive(s) option. The generated .m4 files are saved in the application’s directory, one file per processor.

10.2  To view generated files

From the Code menu, choose the Display Executive(s) option.

If the option Generate m4x Files of the Code menu is checked, SynDEx also produces macro files:

• an application_name.m4x file (if not already existing),
• an application_name_sdc.m4x file.

The .m4x file is the only user macro file which the M4 machinery is aware of. Thus, it should include the _sdc.m4x file. The _sdc.m4x file contains M4 macro definitions corresponding to algorithm definitions that have been associated with a source code via the SynDEx code editor. This file should not be edited by hand because it is overwritten each time the user triggers code generation.

The user should put its hand-written macro definitions in the .m4x which is automatically created by SynDEx only if not already existing. If this file is created by hand, the user should be careful to include the _sdc.m4x at the begining of the file.

10.3  Overview

In this section we give a brief summary of files you will require to generate and compile your executive files. Code generation principles will be detailed in next sections. Files required are:

• application_name.m4x which may be empty, and optionally some processor_name.m4x,
• application_name.m4m,
• GNUmakefile,
• application_name.m4, and one processor_name.m4 file per processor from the main architecture
  These files are generated during the executive generation by SynDEx.

For the files which are not generated by SynDEx, most of the time you can simply copy existing ones (for instance from the example directory) and make modifications explained in the comments of these files. Once you gathered all these files, type make application_name.all in your shell. It compiles the executive files. Then launch the executable file of the main processor. You can also clean your directory by typing make clean.

10.4  To compile an executive

Each macro-executive source file must be first translated by the GNU M4 macro-processor, into a text file in the language preferred for the processor (usually assembler for efficiency, sometimes C or another high-level language for portability). This translation relies on several files included in the following order:

• the first macro-call of the macro-executive source (include(syndex.m4x)) includes the file syndex.m4x which defines all the SynDEx generic (processor-independent) macros which rely on low-level specific macros expected to be defined by the following included files;
• the second macro-call of the macro-executive source processor_(processor_type, processor_name, application_name, version, date)) includes:
  • the file processor_type.m4x which defines low-level macros specific to the type of processor,
  • the file application_name.m4x which defines application-specific macros,
  • optionally the file processor_name.m4x which defines macros specific to the target processor;
• then, after the memory-allocation macro-calls, each communication sequence starts with a
  thread_(medium_type, medium_name, connected_processor_names) macro-call which includes the file medium_type.m4x which defines low-level communication macros specific to the type of the communication medium.

These indirected inclusions, through the names specified under SynDEx, provide a very flexible and powerful mechanism needed to support efficiently heterogeneous architectures, with heterogeneous languages and compilation chains. Then each macro-processed text file must be compiled with the adequate compiler, and linked with the adequate linker against separately compatibly-compiled application-specific files and/or processor-specific libraries, for those macros which cannot simply inline the desired code, but instead must call separately compiled codes.

10.5  To load the compiled executive

In an heterogeneous architecture, there are different compilation chains, with different executable formats which have to be transfered through different types of intermediate media and processors to be finally loaded by different boot loaders. For these reasons, a post-processor is required for each type of processor, in order to encapsulate this heterogeneity into a common download format. This is explained in more details in the downloader specification (cf. chapter 11).

10.6  To automate the compilation/load process

All processor types require the same compilation sequence, but with different compilation tools:

• macro-processing of the macro-executive generated by SynDEx,
• compilation into processor-specific object code,
• linking into processor-memory-map-specific executable code,
• post-processing into common downloadable format.

This compilation sequence may be automatically generated for each processor by macro-processing the macro-makefile generated by SynDEx which includes:

• a very first macro-call (include(syndex.m4m)) that includes the file syndex.m4m which generates a makefile header, and defines the macros architecture_, processor_, connect_, and endarchitecture_ used in the macro-makefile;
• the second macro-call (architecture_(application_name, version, date) that includes the file
  application_name.m4m (if it exists) which defines application-specific make-macros;
• a macro-call processor_(processor_type, processor_name, connectors_type_and_name) per processor that includes the file processor_type.m4m which should have for side effect to generate the required compilation dependences for this processor;
• a macro-call connect_(medium_type, medium_name, connectors_opr_and_name) per communication medium that includes the file medium_type.m4m (if it exists) which should have for side effect to generate any loader-specific dependences (presently unused).

Although this indirect inclusion mechanism is able to generate most of the core makefile, an application-specific top makefile is still required to specify how to generate the core makefile, and to specify the compilation and linking dependencies with application-specific files (include files, separately compiled files and libraries).