Reference manual of SynDEx code generation
Contents
1. processorType_ processorName_ e The mandatory inclusion of the file TYPE m4x TYPE being the first parameter of the macro e The optional inclusion of the following files APPLI m4x APPLI being the third parameter of the macro PROC m4x PROC being the second parameter of the macro The file syndex m4x contains only generic pacros All the macros defining the architecture dependent code are placed in m4x files included here 3 2 1 2 Macro semaphores_ This macro declares the set of semaphores used in the executive to synchronize the computation thread with the different communication threads The file syndex m4x doesn t define this macro It must be defined in the architecture dependent executive kernel This macro take parameters The lack of this file leads to an error 13 e for each communication thread name X Semaphore_Thread_X These parameters are historic and useless e the name of each semaphore That name is composed of the concatenation of the following elements in the opposite order joined by underscores _ empty or full like the buffer supposed to be protected by the semaphore the name of the communication port whereby the data will get through the operator name the name of the buffer protected by the semaphore see below the name of the buffer 3 2 1 3 Macro shared_ and endshared_ These macros delimit the declaration of the semaphore and the declaration of the buf2. let s explain what they are 2 1 Macros An m4 macro is a definition which link the macro name with the replacement text As soon as a macro is defined every time m4 read this macro name it replace the macro name with its replacement text Here is an example Entr e Sortie 1 foo 1 foo 2 define foo bar 2 3 foo 3 bar On the first line no macro has been defined thus the word foo is reproduced to the output On the second line the macro foo is defined The text of the definition is deleted thus the second output line is empty Finally on the last line the word foo matches the name of the macro previously defined and so it is replaced by its replacement text here bar 2 1 1 Parameters of macros Macros can take parameters to benefit from more dynamic replacement Entr e Sortie define 0P1 vari 1 define 0P2 var2 Y define add 1 2 3 add 0P1 OP2 4 Ae Nhe vari var2 Macro parameters are called by 1 2 etc These parameters are given to the macro between parenthesis and comma separated You can notice that define is a macro itself and so it is replaced here by the empty string Warning Parenthesis must be immediatly after the macro name when the macro is called else Entr e Sortie define OP1 vari define 0P2 var2 define add 1 2 add OP1 OP2 gt UNa gt UNa vari var2 2 1 2 Quoting The characters backquote and quote allow the quoted text to be rep
3. TYPE is the name of the medium type used 9 These specific macros are called with same parameters that the generic macros 3 2 1 18 Macro write_ and read_ These macros are instead of send_ and recv_ in the case of shared memory communications Therefore they receive in parameter in addition to the name of the local buffer the name of the shared buffer by which the data will go through 10This corresponds to the first parameter of the macro Thread 18 Annexes A minimalist Makefile ONon kWwWNEH en OANAMTMARWNHEOYHO B A control M4 m4 these path have to be modified by user SDX_MACRO_PATH path to syndex macros export Algo_Macros_Path SDX_MACRO_PATH algo_libraries export Archi_Macros_Path SDX_MACRO_PATH archi_libraries export M4PATH Algo_Macros_Path Archi_Macros_Path S2s_Files_Path VPATH M4PATH PHONY all A all run A run Eula g SON ome ON cual run all A run A mk A m4 M4 lt gt include A mk MGC Macro Generation Context The MGC is a variable to give the context in which an applicative macro is called These applicative macros may be referred to as for the initialisation phase the transitional or permanent phase and after the permanent phase For these macros to be substituted differently depending on a phase when they are called they can test the content of the variable MGC gt Qw0NRAa MGC contains e INIT at the initialisation e
4. a communication port of the operator and the name of this port respectively This macro appears one time for each operators belonging to the architecture for which we generate the application Thus this macro is supposed to generated the part of the makefile which will generate and compile the code associated to the operator Most of the time we have one executable for each operator This executable is added to the list of the dependencies of the target APPLI al1l Then in order to build the command line we join the name of the executable and the address of the operator hostname TP etc into the APPLI root variable Theses pieces of informations are convenient for the downloader see comment page 11 When the main executable is supposed launch the other executables it gets the name of these executable as well as the site where they are supposed to be launched from its command line Besides since these pieces of makefiles are written in the same order as the order of the different macros processor_ the macro of the root operator which is supposed to launch the others must be the first one Finally one or more makefile target must be written to generate the executable from the file PROC m4 PROC being the name of the operator Most of the time this is done in few steps e Transformation of the macro code PROC m4 into source code for example PROC c e Compilation of the source code into object files PROC c gt PROC o e Link
5. ones in SynDEx 2 2 1 include The macro include take a file name in parameter give its contents to m4 to be processed immedi ately Basicly we often have files containing an include macro in the beginning of the file followed by macro calls defined in the included file Fichier foo m4 Entr e Sortie 1 This file is foo m4 1 include foo m4 1 This file is foo m4 Ya define foo bar 2m foo too ve 4 barbare Notice that m4 search the given file in the current directory But if the M4PATH environment variable is set it is expected to contain a colon separated list of directories which will be searched in order This features is used in SynDExbecause the files which define our macros are in the SynDExinstallation folder so it is put in M4PATH 2 2 2 dnl We can see in the last exemple a troublesome effect The two empty lines line 2 and 3 aren t actually desired but are here for good reasons Theses two empty lines corresponds to the two line feed after the macros define and include Fortunately there is a macro which is able to eat these line feed dnl This macro delete itself and all the following characters to the end of the line including line feed Entr e Sortie 1 Rewritten text dnl Forget me 1 Rewritten text Hi 2 Hi Or Fichier foo m4 Entr e Sortie 1 This file is foo m4 1 include foo m4 dnl 1 This file is foo m4 Ym define sfoo bar Dama foo toos ve 2 barbare In the context of code gene
6. saveUpto_ 3 2 1 11 Macro loop_ and endloop_ 0 000000 3 2 1 12 Macro trans_andendtrans_ o 3 2 1 13 Macro main_ and endmain_ 0 0 000004 3 2 1 14 Macro spawn_thread_ and wait_endthread_ 3 2 1 15 Macro Suci SucO_ Prel_ Pre0_ 3 2 1 16 Macro SucR1_ and PreRl_ 2 2 e 3 2 1 17 Macro send_ recv_andsync_ e 3 2 1 18 Macro write_ and read_ e A minimalist Makefile B MGC Macro Generation Context 10 10 12 12 12 12 13 13 13 13 14 14 15 15 15 15 16 16 17 17 17 17 17 18 18 18 18 19 19 Introduction This document aims to explain how we generate code from files produced by SynDEx It will describe the methods tools and libraries used This documentation targets anyone who expects to generate code using SynDEx and who wants to know more about how the code generation works or wishes to upgrade existing tool to generate code more in line with its needs This document also targets SynDEx developers as it is a code generation equivalent of the SynDEx reference manual 1 General principles In the world of software development mainly in the industrial context the traditional development model is the V model The V materializes a Specifications Modeling downward slope to the de velopment itself and an upward slope with tests and validation The existence of this upwa
7. to know from two connected operators which one is supposed to launch the other The second purpose also needs it to match the dissymmetry of most of network protocols that work on a client server model Even if we achieve to part the downloader with the executive these macro may stay for the establishing of communications between operators The macro loadDnto_ is present for the operators that are in charge of launching another operator and that are the server in the communication establishing with the other operator The first parameter is empty and the following ones are the list of the other operators mentionned above The macro loadFrom_ is present for the operators that aren t launched by hand and are sup posed to connect to an operator that waits his connection This macro has only one parameter which is the operator that is supposed to launch the current operator The macro loadFrom_ can appear at most one time because In the case of a shared memory only one operator creates this memory the others just connect with it In the case of a TCP connection only one operator waits and listens on the port where the other operators are supposed to connect 16 e the operator must be launched by at most one other operator e the establishing connection has been initialized by at most one other operator By contrast the macro loadDnto_ can appear several times because an operator may launch several other operators and because many of
8. LOOP during transitional and permanent phases e END after permanent phase Thus here is the common way to write an applicative macro Applicative macro template define my_function ifelse MGC INIT Initialisation MGC LOOP Permanent phase MGC END Ending 19
9. Reference manual of SynDEx code generation Methodology and tools for generic code generation Yves Sorel Simon Nivault INRIA Rocquencourt BP 105 78153 Le Chesnay Cedex France yves sorel inria fr www syndex org Contents 1 General principles 2 Starring m4 2 1 MacrOs 0 La a BE Ge a Eee A ee Be A 2 1 1 Parameters of macros os oa ea paa e oea e a ee DADA QUON A ae E BS A hehe Ge BAe Sis a Ee 2 2 Predefined macros aii ii A A Bel es a ts Be 22M a AE aei ab a rr e a We a das Boeke DD A a peel a ds We ice A o ee E aa DO CiVert ia a Re Dele A A A tt A da 3 G n ration de code 3 1 Build system generation ee 3 1 1 APPLLmk generation 222 bok ee ir a a a a LLLI Macro architecture es dies o a Re eit 31 12 Macro processori ss nenede e A ee ee 3 1 1 3 Macro connect_ and endarchitecture_ 3 2 Executive code generation 3 2 1 Generic macro e la a A A ee ee a A 3 2 1 1 Macro processor_ and endprocessor_ 3 2 1 2 Macro semaphores_ e 3 2 1 3 Macro shared_ and endshared_ Madada Macro ALO A A A eS 3 2 1 5 Macro semaphoresRk_ e 9 2 1 07 Macro allOcR ici id Be MOOR eh Norte hie a EA Jill Macro ala o AAA A Be a Red 3 2 1 8 Macro thread_ et endthread_ 3 2 1 9 Macro loadDnto_ et loadFrom_ 3 2 1 9 1 Comment about the possible romoving of these macros 3 2 1 10 Macro saveFrom_ and
10. asicAlloc_ It must be defined in the architecture de pendent executive kernel 3 2 1 5 Macro semaphoresR_ See semaphore_ 3 2 1 6 Macro allocR_ See alloc_ 3 2 1 7 Macro alias_ This macro allow to alias a buffer No additional memory will be allocated but a new buffer name will refer to an existing buffer The file syndex m4x define this generic macro so that it checks its parameters before calling a more specific macro basicAlias_ with alll its parameters These parameters are e the alias name e the referenced buffer name e the offset e the size of the referenced data The file syndex m4x does not define basicAlias_ It must be defined in the architecture de pendent executive kernel 3 2 1 8 Macro thread_ et endthread_ These macros delimit and define a communication thread The macro thread_ take the following parameters e the medium type of the architecture e the port name of the operator e the operator name which are connected to this medium The call of this macro results in e the definition of new temporary macros mediaType_ is the medium type here the first parameter mediaName_ is the port name here the second argument threadArgs_ is the whole parameters given to the macro thread _ e the inclusion of an executive kernel specific to the medium type the file name must be TYPE m4x TYPE being the medium type This inclusion is optional 15 e the inclusion of an executive kernel spe
11. cific to the port of the operator the file name must be TYPE m4x TYPE being the port name of the operator This inclusion is also optional Finally the call of this generic macro cause the call of few specific macros e TYPE_shared_ TYPE being the medium type This macro is called with all parameters of thread_ except the first medium type e basicThread_ this macro is called with the second parameter of thread_ the port name e TYPE_ini_ in the same way as TYPE_shared_ The macro basicThread_ is systematically called unlike the two others that are called only if they exist The macro endthread_ has an symmetrical behavior in relation to thread_ e a macro call TYPE_end_ as TYPE_shared_ e a macro call basicEndthread_ as basicThread_ e deletion of the following definitions mediaType_ mediaName_ and threadArgs_ 3 2 1 9 Macro loadDnto_ et loadFrom_ Each thread section contains at least one of these macro as first lines These macros concern among other things the domwloader see comment 3 1 and must be in charge of these two purpose e the launch remotly or not of one or more operators which are supposed to be launched by the current operator e the establishing of the connection between the current operator and those that are supposed to connect with 3 2 1 9 1 Comment about the possible romoving of these macros The dissymmetry between the two macros is useful for the two purpose above The first purpose requires it
12. ct of producing a file Dashed red arrows mean is included in by SynDEx produce a macro code which is made up of a set of m4 files m4 extension The macro code is called as it is because it is intended to be processed by m4 which is a macro processor This set of files is composed by an m4 file describing the architecture applicative macro code named appli m4 appli being the name of the application and by one m4 file per processor of this architecture named proc m4 proc being the name of the processor describing the program that will be executed by the processor previously mentioned executive macro code Thus SynDEx generate two type of macro code an applicative one and an executive one From an The architecture can be composed of several calculation operators 2The different calculation and communication operators of the specified architecture can be differently typed initial Makefile written by the user the macro processor m4 will transform the applicative macro code into an helper makefile specifically generated to describe how to transform and compile the executive macro code This transformation of files uses m4 files m4x and m4m extension where we define the macros contained in the macro codes These m4 files are called executive kernels these ones can be classified among two axis e one axis related to which type of macro code is concerned by the executive kernel e one axis related to the genericity of the e
13. d OP1 et matches the macro name Since the macro name isn t followed by a parenthesis the macro is called without parameters and so is replaced by 1 2 M4 always processes again the result of a macro replacement thus instead of matching the following comma M4 reads the word 1 then the comma and so the first parameter is 1 and so on The next parameters are 2 and 3 The macro add is called 1 resp 2 as first resp second parameter The third parameter is passed over To avoid these mistakes there is a simple rule to remember Always quotes one time the parameters for macro calls thus these parameters are processed after the macro replacement Entr e Sortie define UPA DO derino Ga OP OMe Sil derine radd P ER Siam mh on add C OPIU Ora Ae UNa mewhw Fr ioe ar S Last thing to know about macro calls white spaces around parameters e White spaces placed after the parameter belong to it Entr e Sortie iderine ladd Sst salsa 1 2 add 0P1 0P2 2 0P1 L 0P2 e White spaces placed before the parameter are passed over Entr e Sortie W actine add 1 urul 2 1 2 add 0P1 0P2 2 0P1 0P2 2 2 Predefined macros As we can see m4 is based on text replacement by macros These macro can be defined by the user using the macro define However m4 owns lots of predefined macros that enable specific behavior We won t take up these macro exhaustively but only the most used
14. e The main tool is the macro processor m4 Thus the first section will talk about it and will present its general principles and its most used features The reader looking for details is invited to look deeper in the user manual available on the web The next section will talk about the transformation itself This transformation happens in two step both based on m4 The first step is the generation of the build system Makefiles the second one is the code generation followed by his compilation using the build system previously generated 3http www gnu org software m4 manual Gm 3 Syndex m4m j E l Ce Ceg TITTET EEEE EE A APPA A nesset Figure 1 Overall view of code generation 2 Starring m4 Basically m4 read a text from input and reproduce this text to the output with possible modifica tions These ones are defined in the input text itself in the shape of macros m4 invocation echo foo m4 foo Here we call m4 giving foo on its standard input line 1 m4 get foo and write back on its standard ouput line 2 m4 can get input from a file echo foo gt test m4 cat test m4 foo m4 test m4 foo Here we first put foo into the file test m4 then we call m4 giving this file in its parameters Thus instead of reading on its standard input m4 reads from the file given in parameters and writes back again foo on its standard output Since in m4 all is based on macros
15. e other Despite that we will not explain the concept of Makefiles and we will consider that this knowledge is owned The Applicative macro code 5The executive macro code 10 First of all only one of these two Makefiles are generated The other Makefile is the main one is minimalist and must be handwritten This main Makefile can be tuned in accordance with your needs but must respect some condition to be operational Being the gateway towards the generated Makefile it must contain e the include command of the generated Makefile This one is named APPLI mk by convention The mk is by convention the suffix for makefile helpers This command is line 18 appendix A e One rule to make this makefile For that purpose we call m4 on the file APPLI m4 and the outpus is stored in APPLI mk All these are line 16 and line 17 appendix A e A variale which tell to m4 the path of specific macro definitions of SynDEx This variable is named M4PATH and must contain a colon separated list of absolute paths where these definitions are See the macro include at 2 2 1 All these are from line 5 to line 8 appendix A Finally the generated makefile must have two phony target APPLI all and APPLI run APPLI all has the purpose of generating and compiling code while APPLI run has the purpose of running it To be able to call these command from the rules all and run we add the lines from 11 to 14 in the appendix A Comment about appl
16. edition of the object file PROC o alone or with others into an executable PROC exe 3 1 1 3 Macro connect_ and endarchitecture_ The macro connect _ takes 2 2n param eters The two first parameters are the type and the name of a medium respectively The pairs of parameters that follow are the name of the operator connected to the medium and the name of the port whereby the operator is connected to the medium respectively These macro are replaced by empty strings and so they are useless at present 12 3 2 Executive code generation Like the file APPLI m4 each source file of each operator is generated by m4 from its corresponding file PROC m4 which include syndex m4x We will show the macro defined in syndex m4x and used in PROC m4 according to the order they are written Before in addition of the file syndex m4x PROC m4 may also include others files of extension m4x corresponding to the standard library of SynDEx These libraries belongs to the applicative kernel of the generator 3 2 1 Generic macro 3 2 1 1 Macro processor_ and endprocessor_ These macros delimit the executive All other macros must take place between them The macro processor_ take five parameters e the processor type e the processor name the application name e the version of the SynDExwhich generate this executive and a copyright e the date and the time of the generation The use of processor_ produce e The definition of two new macros
17. es the code of multiperiodic application These two macros do not call for any specific macros and stick to define the MGC LOOP for trans_ and END for endtrans_ 3 2 1 13 Macro main_ and endmain_ As macros thread_ and endthread_ these macros are used to delimit the main thread also called calculation thread main_ defines the MGC as INIT and calls on the macro basicMain_ endmain_ deletes the definition of MGC and calls the specific macro basicEndmain_ 3 2 1 14 Macro spawn_thread_ and wait_endthread_ The different communication threads being managed by the main thread this must have instructions to spawn this threads and others to wait for their ending The macros are there to generate these instructions These macros are not defined in syndex m4x and should therefore be defined in the executive kernels dependent on the architecture The macro spawn_thread_ takes in parameter the name of the thread T he macro wait_endthread_ takes in parameter the name of the semaphore of the thread see the macro semaphores_ Tt corresponds to the first parameter of the macro thread_ 17 3 2 1 15 Macro Suc1_ Suc0_ Pre1_ Pre0_ The macros are intra operator synchronization macros They take in parameter the semaphore on which they operate Macros that starts with Suc release their semaphore those starting with Pre wait for them The 0 and 1 sticked to the macros are details relating to priorities for arbitration purposes of sequencers when the
18. fer that will be used for a shared memory communication Originally that allow to distinguish the semaphores and buffers for intra operator data ex changes from the ones for inter operator data exhanges From now the macros for inter operator data exhanges ie for shared memory communication has been renamed to semaphoresR_ and allocR_ The file syndex m4x does not define this macro It must be defined in the architecture depen dent executive kernel 3 2 1 4 Macro alloc_ This macro declares a buffer The rule is a buufer is created for each data production in the algirithm graph Thus a buffer is associated to each output port of each atomic function The name of this buffer is the concatenation of the following elements in the opposite order joined by underscores e the port name e the definition name of the atomic function e the name of the hierarchical function whose the instance of the atomic function belongs e an underscore This macro takes three parameters e the data type e the buffer name e the vector size The file syndex m4x defines this macro so that it call a more specific macro to allocate this memory e if a macro NAME_alloc_ exists NAME being the buffer name it is called e else if a macro TYPE_alloc_ exists TYPE being the data type it is called 14 e else the macro basicAlloc_ is called In any case the called macro take the buffer name in parameters The file syndex m4x does not define b
19. here the downloader code and the application code stands Thus we can t part with the downloader to only use the core application This drawback exacerbate the previous one because we can t part with the downloader when it is too hard to implement 6 An example of minimalist Makefile is given at the appendix A 11 3 1 1 APPLI mk generation As seen earlier the file APPLI mk is generated by m4 from the file APPLI m4 which include syndex m4m So we will present the macros defined in syndex m4m and used in APPLI m4 3 1 1 1 Macro architecture_ This macro takes three parameters in the following order e application name e copyright e date and time of the file creation It generate the makefile rule APPLI run APPLI being replaced by the first parameter The recipe of this rule is the concatenation of two variable prefix run et APPLI root prefix run is defaulted to which is the beginning of the command line to run an executable placed in the current directory This variable exists to support other execution environment For example under Windows RTX an executable in a file with type RTSS which is supposed to be launched by RTSSRun In that case prefix run must be RTSSRun the RTX m4m kernel executive is in charge of this setting 3 1 1 2 Macro processor_ The macro processor_ take 2 2n parameters The two first ones are respectively the type and the name of an operator The pairs of parameters that follow are the type of
20. ication execution Now in several executive kernels macros and gen erated code are written in such a way that the whole application can be lauched from a single command even for distributed application This mecanism is called the downloader Currently this downloader is designed in such a way that it is very interlinked with the applicative source code of each operator Thus the set of operators of the application make up a tree where each node is the executive code of an operator Each node is supposed to be lauched by its parent and is supposed to launch its children This mecanism has the advantage of being able to simply execute a distributed application from only one workstation By constrast it has two major drawbacks e the ability of an executable to launch another one on a remote machine is based on service which is not always supplied by the operating system This is relatively easy on a network of Unix based computer thanks to ssh but is still quite complicated about the ssh configuration This decrease the impact of the advantage above Besides it s even more complicated on system without ssh like Windows It s possible to give Windows a Unix behavior using solution like CygWin but this is too intrusive But what about the application distributed on Unix and Windows in the same time e the current implementation of the download is as well too intrusive with regard to the gener ated executable because there is only one site w
21. ration it s important to master the removing of these line feed Otherwise a lot of line feeds will remain which are as many fence to the readability of the generated code 2 2 3 divert The macro divert is one of the most complicated of m4 Indeed this macro creates kinds of buffers where m4 is able to temporarily write instead of standard output However divert does not allow to redirect the standrad output towards a file or anything else this is not his job it s the job of a shell divert take a number as parameter which select the buffer where m4 will write from now on If the parameter is left out it is defaulted to 0 which is the normal output stream Consequently when divert is called with a non zero parameter the text that should be output won t be output anymore Example Entr e Sortie 1 Normal ouput 1 Normal ouput 2 divert 1 2 3 O output 3 Back 4 divert 5 Back As we can see all between divert 1 and divert hasn t be output The empty line corresponds to the line feed after the divert Most of the time this line feed is unwanted and this is achieved like that Entr e Sortie 1 Normal ouput 1 Normal ouput 2 divert 1 2 Back 3 Diverted output 4 divert 5 Back Actually what is written in a numbered buffer isn t lost By contrast this is stored to be used later thanks to the macro undivert The exception is when a negative number is used the text is discarded We can use a negative dive
22. rd slope is due to the fact that the development is done by humans and may be incorrect it is necessary to reconcile with hindsight development with specifications and modeling to obtain a consistent and error free application The purpose of SynDEx is to transform this V model into a I model by code generation The idea is to ensure by construction the consistency between specifications and development It im proves the safety and the speed of the development the I model being shorter than the V model SynDEx performs an adequation between the twooriginal specifications the functional spec ification also called algorithm and hardware specification also called architecture From this adequation SynDEx produce at first time what is called a distributed and heterogeneous generic macro code This macro code is specific with regards to the algorithm and the architecure for which it was produced but it is generic with regards to the various methods that we could use to carry out this program if it had the will to write manually In a second time and this is precisely the purpose of this document there is a compilation chain that can transform the SynDEx generated macro code to a specific code chosen by the user Indeed the choice of the target language is left to the user the objective of being able to integrate SynDEx with its own development chain The figure 1 gives an overview of this file transformation The black arrows represent the a
23. roduced without any modification i e without calling macro or taking into account special characters Here is an example without quoting the result is not the expected one Kh w NnN mw Nhe Entr e Sortie define add 1 2 il exclel il 2 Tandi Y iL 2 ame 3s Agel i 2 5 3 al ae 2 Here is how to have the expected result using quotes Entr e Sortie define add 1 2 1 radd i 2 and 3 1 2m add 1 2 and 3 Agel 1 2 3 3 MEA Nevertheless quotes can introduce unexpected behavior Entr e Sortie TU define 0P2 3 define add 1 2 add 0P1 0P2 gt UON To uderstand what happens it s important to know how m4 read its input e First m4 read word for word Thus in the example above it begins to recognize the word define e Since define is a macro and the following character is an opening parenthesis m4 will decide to read the following to fetch the comma separated parameters of the macro until it matches a closing parenthesis l M4 reads the following word here OP1 M4 reads a comma so it accepts OP1 as first parameter M4 reads then it directly goes to match the corresponding then accepts the content as is MA reads the closing parenthesis It is ready to call the macro define with OP1 and 1 2 as argument Let s go directly to the last line e M4 reads the word add then the opening parenthesis then fetches parameters M4 reads the wor
24. rt to define our macro thus we needn t dnl Finally unlike all other macros m4 doesn t process again the result of the macro undivert Entr e Sortie Normal ouput 1 Normal ouput divert 1 dnl Dae Back foo 3 foo divert 1 define foo bar divert dnl Back undivert 1 BAIA KWH 3 G n ration de code SynDEx produce two kinds of m4 files e One filet named APPLI m4 relating to the application APPLI being the application name e One file per operator which contains the macro code of this operator We will name them PROC1 m4 PROC2 m4 PROC1 and PROC2 being the name of the operators of the architecture Each kind of files has a specific job APPLI m4 is useful for the generation of the build system makefiles while PROCN m4 files are useful for the executive code generation These files are com posed of standard macro calls and these standard macros are defined in an m4 file included in the beginning of the macro code Thus the first line of APPLI m4 file is include syndex m4m and the first line of PROCN m4 files is include syndex m4x syndex m4m et syndex m4x are the generic macro files of code generation One of their main purpose is to include in accordance with the content of APPLI m4 and PROCN m4 files the application specific macro files 3 1 Build system generation In this section we will talk a lot about Makefile because the build system is composed of two Makefiles one of them including th
25. them are supposed to connect to it Finally both macros can appear at the same time beginning the loadFrom_ one These two macro are generic and are defined in syndex m4x They check that they have been called from a thread_ section and then call specific macros TYPE_loadFrom_ or TYPE_loadDnto_ TYPE being the name of the medium type used These specific macro are called with the same parameters as the generic ones 3 2 1 10 Macro saveFrom_ and saveUpto_ These macro are the symmetric of the previous ones and are at the last lines of the thread _ sections For each loadDnto_ there is a saveFrom_ with the same parameters and for each loadFrom_ there is a saveUpto_ with the same parameters In the same way these two macros check that they have been called from a thread_ section and then call specific macros TYPE_saveFrom_ or TYPE_saveUpto_ 3 2 1 11 Macro loop_ and endloop_ These two macro appear in thread_ sections and in main_ section They delimit the instruction cycle of communication threads and calculation thread that needs to be runned loop_ define the MGC see appendix B as LOOP and call the specific macro basicLoop_ endloop_ defines the MGC as END and calls the specific macro basicEndloop_ 3 2 1 12 Macro trans_ and endtrans_ The macros are actually similar to loop_ and endloop_ to this loan that they highlight the transient phases when they exist instead of permanent phases Therefore the macros are only shown when one generat
26. xecutive kernel Among the first axis one has e the executive kernels describing the macros used in the applicative macro code makefile generation m4m extension e the executive kernels describing the macros used in the executive macro code code generation m4x extension Among the second axis one has e a generic executive kernel which is the entry point of the other executive kernels called syndex m4x and syndex m4m e several executive kernels specific to the architecture which describe the way one will generate the code and the context where it will be executed description of the language of the OS of the system libraries etc called Archi m4x and Archi m4m Archi being the name of the used architecture e several executive kernels specific to the application called Appli m4x and Appli m4m Appli being the name of the application which mainly contain the definition of the macro corre sponding to the domain specific code These definitions are usually specifically written for a given application but this work can virtually be factorized by creating applicative executive kernel libraries some are distributed with SynDEx Besides these executive kernels can contain some general execution options number of it ration of the application names of the hosts where the application will be executed in case of distributed application some specific options to tune the behavior of other executive kernels or whatever Outlin
27. y deal with computing thread and communication threads in a non symmetrical way On the systems which manage multitasking as Unix and Windows we can ignore this and make the same substitution for both variants of Suc and Pre 3 2 1 16 Macro SucR1_ and PreRi_ These macros work just the same way as the previous and are dedicated to the inter operator synchronizations in the context of communications by shared memory 3 2 1 17 Macro send_ recv_ and sync_ These macros are the functions of communications et apparaissent in the or section thread They take into first parameter the name of the buffer to send or receive The two following parameters are the kind and the name of the operator that produced the data which is redundant they may seem therefore no need for the contrary A optionel last parameter indicates the operator with which this communication which amounted also seems redundant the macro thread_ providing already this information In the case of a multipoint communication the macro sync_ means that when sending to a given by another operator the current operator is not the receiver of this and can therefore ignore it Thus instead of in the name of the buffer in first parameter the macro sync_ receives the type of the given and its size These two macros are generic and defined in syndex m4x They check that they are called in a section thread_ then call for the specific macros TYPE_send TYPE_recv or TYPE_sync as the case may be
Download Pdf Manuals
Related Search