Next: Links
Up: SynDEx Downloader Specification
Previous: Common Download Format
  Contents
The downloader code is generated by two macros:
- "loadFrom_" starts the initialization phase of the communication sequence of the medium connected to the ascendant processor; its first argument is the name of the ascendant processor, its next arguments, if any, are the names of the other medium connected to descendant processors, if any;
- "loadDnto_" starts the initialization phase of the communication sequence of each medium connected to a descendant processor; its first argument is the name of the medium connected to the ascendant processor, its next argument(s) is (are) the name(s) of the descendant processor(s).
Processor names are usefull to address processors connected to multipoint medium: a processor name may be suffixed to give the name of a user defined macro, which substitution gives the processor address.
As executives data may be forwarded through several communication medium of different bandwidths, transfers must be synchronized such that data flow at the speed of the slowest medium.
Between processors, if flow control is not supported by the medium hardware, it must be implemented by "ready to receive" control messages sent by the loadFrom_ code for each chunk of data to be sent by the loadDnto_ code. Inside a processor, the loadFrom_ and loadDnto_ macros cooperation is based on the order in which the spawn_thread_ macros (one for each communication sequence, i.e. for each communication media) are generated in the initialization phase of the "main_ ... endmain_" sequence: the spawn_thread_ macro corresponding to the thread_ macro of the communication sequence starting with the loadFrom_ macro (i.e. of the media connected to the ascendant processor) is called first, followed by the other spawn_thread_ macros, among which the ones, if any, corresponding to the communication sequences with a loadDnto_ macro (i.e. of the media connected to the descendant processors).
If the processor is a leaf node of the download tree, its loadFrom_ macro has only one argument; in this case, it directly generates the code sending to the ascendant processor a "null" message meaning that no more executive is requested, followed, in the case of a multipoint medium, by the code waiting for other executives to be downloaded to the other processors connected to the medium, until the ascendant processor sends an "empty" executive meaning that the download process is complete on this medium.
Otherwise, before generating the code described in the previous paragraph, the loadFrom_ macro generates a RETURN instruction (which will return control after the CALL instruction generated by the spawn_thread_ macro), followed by a "loadFrom_end_:" label, and the loadFrom_ macro also defines three macros for use by the loadDnto_ macros:
- the "loadFrom_req_" macro must generate the code that sends a "non-null" message requesting the ascendant processor to download another executive;
- the "loadFrom_get_" macro must generate the code that receives one "word" of executive data from the ascendant processor; "word" means the size of a processor register, usually 32 bits; if the communication medium transfers executive data by chunks of N words, then every N calls to the code generated by the loadFrom_get_ macro receives a full chunk of data and returns its first word, and the next N-1 calls each return a next word of the chunk;
- the "loadFrom_next_" macro, which is called at the end of each loadDnto_ macro, must generate a "CALL loadFrom_end_", but only for the very last loadDnto_ macro.
If the code generated by any of these three macros is limited to a few instructions, it may be generated inline, otherwise the loadFrom_ macro generates this code as a subroutine (between the RETURN instruction and the loadFrom_end_: label), and a call to that subroutine is generated instead of the inline code.
Next: Links
Up: SynDEx Downloader Specification
Previous: Common Download Format
  Contents
Julien Forget
2003-03-21