Previous: Mixing Fortran and C Up: VICAR Porting Guide Next: Creating Applications
This section discusses the creation and use of new subroutines for the SUBLIB library in VICAR. Although the discussion mentions only the class 2 subroutine library (p2$sub), the rules apply to the class 1 and 3 libraries (p1$sub and p3$sub) and other libraries (such as the HW library, hw$sub) as well.
The new VICAR directory structure allows the creation of more than one subroutine library in each application class. For example, the general SUBLIB library could be augmented with a Galileo-specific subroutine library with the subroutines that apply only to the Galileo project. Or, a Real-Time subroutine library could be created with subroutines that apply only to the Real-Time subsystem. While this capability is not currently implemented (there is only one subroutine library per class), the flexibility exists in the system to add these extra libraries in the future if they are deemed necessary.
It is important to remember that MIPL should not be doing a wholesale conversion of SUBLIB. Rather, subroutines should be converted as they are needed in the process of porting programs. Thus, if no ported programs use a SUBLIB routine, then it will not get ported. This helps keep the size of SUBLIB down, and should eliminate some of the unnecessary routines. The practical upshot of this is that the contents of the new SUBLIB will be changing constantly during the VICAR porting process. Keep a close eye on the available routines (the source code is in p2$sub or $P2SUB). If you need to port a SUBLIB routine, check to make sure nobody else is doing it, then if not, let configuration management know you are doing it. That way, duplication of subroutines can be avoided.
___________________________________________________