![]() |
|
| SEMS: Software Engineering & Modification System | |||
This is a collection of software tools that allow control and modification of large software projects. The primary goal of the SEMS system is the careful management of project information and project software codes and data. The primary benefit is absolute control of shared memory allocations across many processes and potentially CPUs and machines. In simulation and real time applications, high speed access to data is essential, and this is best accomplished by straight memory access by the software processes and threads running in a CPU. The memory may be allocated in one machine, or shared amongst machines with the various reflective memory and memory repeaters available on the market today. |
|||
| The essential problem with implementing control over shared memory is to ensure that the memory variable map of that shared memory is consistent over the entire set of programs and processes which must access the data. SEMS provides tools to control this variable map without major efforts by software administrators and gurus. | |||
| SEMS is available for SUN Solaris Release 2.x, Win NT® 4.0, and is portable to any multi-tasking operating system which supports tcl/tk. | |||
| SEMS Database | |||
| The focal point of SEMS is a hierarchical database which is created by an administrator and modified by the various engineersand software developers working on the various aspects of a large software project. This database resides in a central place in the network, and is accessible to all of the developers and testers. This database acts as a repository for all of the project software data, so that at any given time, all members of the project have access to the most current information. Although it's primary purpose is the control of allocation and naming of software variables, other project information may be defined and maintained with in the database. | |||
| Adding Memory Mapped Variables | |||
| SEMS release 5.0 includes the Tcl script add7. This is the latest version of the add program to add programming variables to the SEMS database. | |||
| Starting add7 | |||
| The script add7 is started by typing add7 database on the OS shell command line. The database string provided as an optional argument will be opened for usage. If not specified add7 uses the Environment Variable $DATABASE. The database string should include a pathname (absolute or relative) and the Database root filename (without the file appender). If no Database is found add7 is terminated. $DATABASE is usually set at login in the .semsrc file. | |||
|
|||
| ADD | |||
| The ADD command works on the database record type $SIMULATIONVARS. All records defined and added are validated within the record type in the SEMS database. The ADD command has 6 mandatory fields. These fields must be delimited by at least a space, although processing of the commands ignores additional white space and carriage returns. Carriage returns will result in a prompt of the next field to be entered. Once all mandatory, and optional fields are entered, the record entry will be validated against the database, and if allowed, will be added to the database record. The success or failure of the add process will be reported to the user, along with appropriate error messages if failure to add has occurred. | |||
| 'definition' | |||
| A definition of the variable being added. This field MUST be enclosed with single quotes. The contents of this definition are added to the DEF1 field, the string length is limited to the length of that field. Additional characters are truncated. | |||
| The ADD command also allows optional fields to be specified. Optional fields are delimited by commas, and if a comma does not follow the mandatory definition, or any subsequent optional field, entry is assumed to be complete and the entry is then processed against the database. | |||
| STRUCT | |||
| The STRUCT command is identical to the ADD command, except it adds variables and structure elements to the $STRUCTURES record type. Additionally, the STRUCT command has $STRUCTURES as its parent, then a type record is created in $UNITS_AND_TYPES. Refer to the Caveats for utilization of structures. | |||
| END | |||
| Terminates the program. | |||
| Notes | |||
| When adding structures, there are some limitations due to the nature of SEMS and shared memory. | |||
|
|||
| DBLOOK | |||
| DBLOOK is the SEMS tool which is used to view the records in the SEMS hierarchical Database by NAME or ALIAS access. DBLOOK is written as Tool Command Language (Tcl) scripts running with the Tool Kit (Tk) shell. This provides a X-Window based user GUI interface using the SEMS Tcl extensions. In conjunction with the normal command line entry, a menu/button point and click interface is provided for DBLOOK navigation commands. In addition, menu entries are provided for the more complex command and file generation capabilities of DBLOOK. | |||
| Basic commands of DBLOOK navigate the user though the records of the Database and allow viewing of those records. Menu driven extensions allow extracting lists of children and descendants of records, searching and sorting for particular data in fields by Query, extracting memory usage information for memory mapped variable partitions, extraction of records for use with the other SEMS tools, and modification of Database records. | |||
| Starting DBLOOK | |||
| DBLOOK is started by typing DBLOOK database on the OS shell command line. The database string provided as argument will be opened for usage. If not specified DBLOOK uses the Environment Variable DATABASE. The database string should include a pathname (absolute or relative) and the Database root filename (without the file appender). If no Database is found DBLOOK is terminated. $DATABASE is usually set at login in the .semsrc file. | |||
| Window Elements | |||
|
|||
![]() |
Current. Outputs and redisplays the current record to the screen. Useful after long lists, rather than scrolling. | ||
| Modify. Invokes the field modification menu for the current record | |||
| Next. Moves the current record to the next sibling record, and displays it. | |||
| Up. Moves the current record to the parent record, and displays it. | |||
| Down. Moves the current record to the first child record, and displays it. | |||
| Child. Displays a tabular list of the children of the record. | |||
| NextRec. If the name appears in more than one record type, then this command displays the record of the next type. Otherwise, behaves exactly as Next. | |||
| Form. Displays the current record with the print format string. This format is defaulted to a list of all fields. | |||
| Command Display. The Command display window is the section of the DBLOOK application which displays the results of the commands. If the command is typed into the command entry field at the bottom, the command is repeated. The "typed" entry or the command selected from the menu or button is executed and the results of the command is displayed, according to the format specification related to that executed SEMS Tcl command. The result of each command is separated by a dashed line for easy identification. The results for a session are maintained, and a scroll bar on the left side will allow scrolling backward through results of past commands. | |||
| The Display window is implemented with the Tk text widget, however, the widget is programmed as read only, and no input is allow in this window. Selection mechanisms for text windows are active, and for this purpose, the standard mouse and keyboard select click and drag options for the text widget are active. Refer to the man page on Tk text widgets for this functionality. | |||
| If errors are encountered, a Tk error dialog box alerts the user to the specific error. This dialog box MUST be acknowledged to continue processing. | |||
| Command Line Entry. This element is the entry box where SEMS Tcl commands may be typed and entered by the user. This entry is implemented with a standard Tk entry widget, and most standard Entry bindings apply (refer to the Tk man page on entry widgets). However some bindings have been modified to give a more consistent behavior. Selections are handled in a manner similar to the text widget. Most useful bindings are: | |||
|
|||
| cprep - SEMS C Preprocessor | |||
| SEMS release 5.0 includes the Tcl script cprep7. This is the latest version of the cprep C preprocessing program. This program defines shared memory variables from the SEMS database for C source files. The cprep program reads the C source file with cprep commands, regenerates documentation and declarations, and rewrites the source file which is then suitable for compilation. cprep does not do the compilation. | |||
| Running cprep7 Program | |||
| The script cprep7 is started by typing cprep7 -d database -m sourcefile on the OS shell command line. The database string provided as an optional argument will be opened for usage. If not specified cprep7 uses the Environment Variable $DATABASE. The database string should include a pathname (absolute or relative) and the Database root filename (without the file appender). If no Database is found cprep7 is terminated. $DATABASE is usually set at login in the .semsrc file. | |||
| The -m option is used with the C module which is used to define the mapping partition. Usually the module of choice is global.c. Without the -m option the global union statements are defined as external. | |||
| cprep Statements | |||
| cprep statements are special comment lines. These comments MUST start in column 1. cprep currently supports the following commands: | |||
| /*G Global Statement | |||
| A global statement has the following format: /*G name*/ . A /*G statement must be provided for every global symbol referenced in shared memory. symbol referenced. The /*G statement must precede any other reference to the variable. In the output file, the /*G statement is replaced by two comment lines containing the type, units, alias, and description of the variable, and linking it to the appropriate global segment to be written to the include file. The expanded G statement written to the new source file contains a complete description of the global variable. This replaces the comments previously used to describe global variables. If the description is incomplete, or incorrect, the database record must be modified, not the source file. | |||
| /*P Parameter Statement | |||
| The /*P statement is used to parameterize a program variable with a value derived from the dimension of a database variable. | |||
|
|||
| To produce a value equal to the product of all the dimensions of a database variable, use this form. For instance, if a variable is dimensioned var(2,3,7), then this form would produce a value of 42 for the constant con in the following example: | |||
|
|||
| The product of selected dimensions can be produced by this form. For the above-mentioned variable var, The following values are generated as a #define statement with the name and value in the include file: | |||
|
|||
| Using Array Elements from Shared Memory in C | |||
| SEMS as a matter of course supports both FORTRAN and C. When addressing an array that is declared in shared memory, it must be remembered that FORTRAN uses elements by column, and C uses elements by row. This results in an inversion of indexes between FORTRAN and C. | |||
| For historical reasons, in that SEMS was first developed for FORTRAN, before C became a widely used language. The array representations in SEMS tools have therefore FORTRAN representations: var(x,y,z). The field structures for memory mapped variables in SEMS support three dimensions, and these dimensions (and the supporting address calculations) assume that the memory is a FORTRAN representation when loaded into memory. As such the addressing calculation for elements is columnwise. When using C to address an array element defined in SEMS, in order to get the actual address to the element to be consistent with the FORTRAN representation, the array elements must be used backwards (from the C point of view). So if an array is defined in the database as var(2,4,6), then in C the statement var[1][3][5] is WRONG. FORTRAN would be var(1,3,5) but C must be var[5][3][1] to get the correct memory location. | |||
| Include File | |||
| cprep generates a declaration include file, commonly referred to as the "I." (eye-dot) file because of the SIMPREP name generation. However with cprep only one file is created for the source file itself, not each module as in SIMPREP. This filename is the source file trunk name appended with ".I" This file contains the declarations created by cprep for the variables and parameters defined by the cprep statements. An "include" statement is placed in the source to reference this file. | |||
| Simloch | |||
| Simloch is the SEMS tool which allows the user and the model developer access to the values in allocated shared memory at run time. Simloch uses the variable map created by the database tools to allow access to all memory locations defined in shared memory by variable name, and, where appropriate, element and memory tag. In the case of elements, these may be array numbers or struct elements. In the case of memory tags, it will allow access to all mapped segments of the same memory map by tag. Simloch also provides extended commands for initial conditions, save and reloading screen files, and the loading and unloading of memory data by variable name. | |||
| Simloch under SEMS release 5.0 comes in two flavors, siml5 (X-windows/MS windows) and simlh (dumb terminal). Either name may be typed as the command from the OS shell. Both have been developed to run under the SEMS Tcl/Tk interpreters (tclsh and wish respectively), and use the SEMS Tcl extensions. | |||
| Starting Simloch | |||
| The Simloch tasks may be started up with options on the OS shell command line. These options specify the commands to execute at startup, the geometry of the Variable Display, and/or an alternate database. Default setting are defined with the option, in the case where no default is listed, no action is taken. | |||
| siml5 | |||
| This version of Simloch is written as Tcl scripts running with the TK shell and provides a X-Window based user GUI interface. In addition to the normal command line interface, a menu point and click interface is provided for controlling the users simulation, executing extended Simloch commands, and defining user look and feel customization. | |||
| Window Elements | |||
|
|||
| simlh | |||
| This version of Simloch is based on Tcl, and provides a dumb terminal, curses based interface. This version is used when X-Window Displays cannot be displayed or exported to the users screen. The user interface (MS Windows) for simlh is solely command line. Screen size for variable display will be determined by the TERM setting on process startup. | |||
| For users familiar with older versions of SEMS and Simloch, this version provides similar functionality to Simlg. However, with simlh the screen update is not suspended for command line entry as it was in earlier versions. | |||
| Simloch Screen Example | |||
|
|||
| New Enhanced Features of SEMS Release 5 | |||
|
|||
| Compatibility with Older Versions of Simloch | |||
| With release 5.0, Simloch will read all files, include screen files, load files, and IC files which have been created by the older SEMS tools. However, files created by siml5 and simlh cannot be read by the older Simlg. | |||
| Taurus teleSYS Inc. © 1999-2000 |