Dummying an SU

To dummy out unwanted SUs and to change the set of dummies to track program development, proceed as follows:-

1. Define what SUs are required in the normal way, i.e. either by building a program with USER_DEFINE_TASK or by writing a command file with a $processor_list command.

2. Run the program and give the command:-

   $write_dummies my_file.f

   (where any suitable file name can be substituted for my_file.f.) Then supply other commands as normal. SNOMAN will begin to initialise but, once the list of SUs that are required has been defined, will terminate after writing a special version of USER_DEFINE_TASK into the file you have specified.

3. This special USER_DEFINE_TASK has all the required SUs enabled but has dummy entry points that mask out all other SUs. So any program that is built with LINK_SNOLIB using this file will be trimmed precisely to the requirements of the task. If you do this you may see that the tool still links in some MC BLOCKDATAs, of which the EGS4 is by far the largest. If you want to squeeze the last drop of wasted space out of your program, set the third option of LINK_SNOLIB to NO_MC e.g.:-

   $SNO_TOOLS/link_snolib.scr my_file.o test.exe NO_MC

   If you wanted to set this third parameter to NO_SNOMAN then combine them into NO_SNOMAN_MC (or anything that includes _SNOMAN and _MC). Note: you only have to do this if BLOCKDATAs are not auto-loaded on your platform. At the time of writing, this is only true of the MIPS. You can check this by looking at the file get_platform_variables.scr and seeing how the environmental variable autoload_blockdata is set for your platform.

   Note that this procedure cannot, of course, be used to reconnect disconnected SUs; if you want to use such an SU, it must first be reconnected as described in section 11.6.3.

If subsequently you change the pattern of SU usage, one of two possible situations will arise:-

• An SU that was previously used is no longer required. This just represents wasted space in the program. It is easy to spot because, as part of initialisation, SNOMAN summarises the number of disabled SUs and the number of these that are dummied/disconnected.

• A dummied SU is now required. This is, of course, a fatal error, but again it is easy to spot as it is checked for and reported on during initialisation.

After such a change you can either regenerate USER_DEFINE_TASK again as described above or you can edit the version you already have; the routine is deliberately designed to make it easy to change. Look at the log file to see a complete analysis of all SUs and use it to decide what edits to make.

You must always regenerate the routine when moving to a new version of SNOMAN as the SU interdependencies may have changed.