07/16/86  fortran_large_arrays.gi

Fortran has been extended to allow large and very large arrays in
automatic, static and COMMON storage.  These arrays are stored in
separate segments outside the stack and linkage area.


Large arrays:

Large arrays (LAs) should be used when the size of the arrays in a
storage class (automatic or static) would exceed the normal limits of
that storage class.  For automatic storage, the normal aggregate limit
is about 62000 words.  For static storage, the normal aggregate limit
is about 128K words.  The use of large arrays extends this storage
limit to an arbitrarily large amount.  Every individual array must
occupy less than one segment (262144 words) and is contained in a
single segment.  There is some additional overhead to allocate and
initialize the extended storage.  There is no restriction on the type
or use of large arrays.

Large arrays are available through the -large_array (-la) (automatic
and static), -la_auto (automatic only), or -la_static (static only)
control arguments or the la, la_auto, or la_static arguments in a
%global statement.


Very large arrays:

Very large arrays (VLAs) are those which are longer than 255K words.
This includes COMMON blocks which are longer than 255K words.  The
limit now is 2**24 words for each array or COMMON block.  In addition
to the overhead for allocation and initialization, there is addressing
overhead for VLAs and the array parameters of programs that use VLAs.

Very large arrays are available through the -very_large_array (-vla)
(COMMON, automatic, and static), -very_large_common (-vlc) (COMMON
only), -vla_auto (automatic only), or -vla_static (static only)
control arguments or the vla, vlc, vla_auto, or vla_static arguments
in a %global statement.

There are some restrictions on the use of VLAs.
- They may not contain characters.
- Binary I/O is limited to a segment or less in length per record.
- Permanent very large COMMON blocks are not supported.

Programs that expect VLA parameters but otherwise do not use LAs or
VLAs should use the -vla_parm control argument or the vla_parm %global
argument.  In this case, the only extra overhead is for addressing the
(possibly) VLA parameters.

LA and VLA features affect the entire compilation unit.

Array initialization information is now stored in a condensed format,
so that an object segment can contain the initialization for several
VLAs.


Location of Storage:

Use of the LA/VLA features requires large amounts of quota.  By
default, the extended storage segments are placed in the process
directory.  If there is not enough space there, the user can use the
value_set command to define "fsm_dir_dir_path".  The extended storage
segments are placed in pool directories within the process directory
or "fsm_dir_dir_path".  There is potentially a separate directory for
each ring.  For example, the pool directory for ring 4 has the name
fsm_dir_4.  Access on individual segments is set to "rw" for the owner
and to "null" for everyone else.

The command list_fortran_storage (lfs) lists the extended storage
segments assigned to the user's process.  They are grouped according
to the storage they are extensions of.  For example, all the segments
for a program's static LAs and VLAs are grouped together, identified
by a pointer to the beginning of the program's active linkage section
(the copy that is being used, not the copy in the object segment).


COMMON:

There are some changes concerning COMMON.  VLA COMMON (VLC) is
allocated when a program is entered, rather than when the block is
first referenced.  When a program that uses VLC is bound with a
non-VLA program that uses the same COMMON block, the binder will make
all references be to the VLC block.  If the non-VLA program is
executed first, the block will be allocated as a VLC but the program
will reference only the first segment.

All the commands that deal with COMMON have been modified to work with
VLC.  This includes set_fortran_common, the external variable
commands, and print_link_info.  The run command has been modified to
work correctly with LAs/VLAs/VLC.


Overhead in allocating and freeing storage:

There is substantial overhead in allocating and freeing the storage
associated with LA's and VLA's as compared to normal arrays.  For
static and common storage, the allocation overhead cost is paid once
per process (unless a program is terminated and then reinvoked).  Thus
it is not very expensive or inefficient to use static or common LA's
and VLA's.  However, the allocation overhead for automatic LA's and
VLA's occurs every time the compilation unit which declares them is
entered and the freeing overhead occurs every time on exit.  If a
program is compiled in one piece, then the allocation and freeing
overhead for automatic LA's and VLA's occurs only once per run of the
program.  However, if the program is made of separately compiled
pieces, then a high price might be paid for allocation and
deallocation.  Therefore, if a program is known to to contain only
certain storage classes of LA's and VLA's, they can be compiled using
the appropriate storage specific LA and VLA arguments (la_auto,
la_static, vla_auto, vla_static, very_large_common) to reduce the
overhead required.  Only the vla_parm argument does not cause any
entry/exit overhead.


Static storage:

The normal limit on the amount of static storage in an unbound segment
is 128K words.  However, the binder will not bind a set of objects if
the total amount of internal static storage used by those objects
exceeds 16383 words.  Using the la_static argument causes the static
arrays to go into fortran's managed storage and hence are addressed
differently.  The effect is that programs may then have arbitrarily
large amounts of static storage and can be bound.


Probe:

Probe has been modified to work with VLAs.  In addition, probe can
print the values of the base pointers to LA and VLA segments.  These
pointers have names which are printed in the storage class section of
program listings' symbol maps and which can be obtained through the
probe value request.

Base pointers to LA storage are of the form:
     la$auto$xxxxxx or la$static$xxxxxx
where xxxxxx is the octal offset from the beginning of the stack or
static section of the pointer to the first segment.

Base pointers to VLA segments are of the form:
   vla$auto$name  or vla$static$name  or vla$common$name
where "name" is the name of the array or COMMON block.  Blank COMMON
has the name of vla$common$_.


Conditions raised:

Two new conditions can be raised by Fortran runtime.
fortran_storage_manager_error is raised if an error occurs during the
assignment or creation of external segments.  fortran_storage_error is
raised if an error occurs in the initialization of external storage or
in the creation of a COMMON block.  The accompanying messages describe
the cause of the error and possible correction.  These conditions are
usually restartable if the cause of the error is corrected.


Implications for subroutine libraries:

The use of subroutine libraries poses some efficiency problems with
the use of VLA's.  These problems must be addressed by the library
managers of individual sites.

  1. VLA addressing  is a superset of  normal hardware addressing
     of  the  Multics  processor.   This  permits  all subroutine
     libraries to be compiled with VLA addressing for parameters,
     through either "-vla_parm" or "%global vla_parm;".

  2. It  is  possible  that  certain programs  will  be noticably
     impacted by the  use of VLA addressing in  very tight loops,
     or in complex operations, such as might occur in things like
     matrix multiplies or inversions.  In  such cases it might be
     advisable  to  copy  VLA  parameters to  a  local  area, and
     re-copy the result at the end of computation.

  3. It  may be  advisable to take  internal routines  of a large
     libary set, such as IMSL, which are known to NEVER be passed
     VLA's  and  to  separately  re-compile  them  so  that their
     internal interfaces will only expect normal arrays.

  4. A  final  possibility  would  be two  distinct  and separate
     libraries,  each  compiled  for  maximum  speed  in  the two
     calling  types; VLA  calls and  normal calls.   This poses a
     management problem in making segments known, dynamic linking
     and storage management, and  management of user problems and
     education.


                                          -----------------------------------------------------------


Historical Background

This edition of the Multics software materials and documentation is provided and donated
to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. 
as a contribution to computer science knowledge.  
This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology,
Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL
and BULL HN Information Systems Inc. to the development of this operating system. 
Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970),
renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership
of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture 
for managing computer hardware properly and for executing programs. Many subsequent operating systems 
incorporated Multics principles.
Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., 
as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. .

                                          -----------------------------------------------------------

Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without
fee is hereby granted,provided that the below copyright notice and historical background appear in all copies
and that both the copyright notice and historical background and this permission notice appear in supporting
documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining
to distribution of the programs without specific prior written permission.
    Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc.
    Copyright 2006 by BULL HN Information Systems Inc.
    Copyright 2006 by Bull SAS
    All Rights Reserved