FALCON posesses eight statements that declare the 'storage class' of variables: STATIC, AUTO, SHARED, ALLOCATED, UNIQUE, CONTROLLED, VIRTUAL, and STACKED.
STATIC is the default storage class for externally-compiled subroutines and main programs. A variable that is STATIC corresponds to a memory location reserved for it alone (except as EQUIVALENCE statements, etc., change this) with the exception that each copy of the routine has its own copy of each STATIC variable. Multiple copies of a routine may be created as the result of parallel processing or overlays.
AUTO implies that each time a subroutine is executed, a new copy of the variable is created, which then vanishes when the subroutine exits. A subroutine with only AUTO variables can call itself and behave in the 'obvious' manner.
Note that all the AUTO variables in a single subroutine belong to a single block, which is allocated as a unit when the subroutine is called.
The default storage class for internally compiled routines is halfway between AUTO and STATIC. Static storage is allocated, but subprograms that do not call each other may use the same storage for their private variables to minimize memory use. This type is called SHARED; while it is not applicable to programs for which it is not the default, FULL mode or other compiler options may change the default for internally-compiled routines, in which case the corresponding statement would be useful.
ALLOCATED variables occupy no memory initially, but will be given memory when they appear as arguments of an OBTAIN statement (OBTAIN name,name,...name) and that memory is surrendered by a FREE statement (same syntax). Note that this corresponds to the PL/I CONTROLLED access type; here, the name CONTROLLED is given to a completely different access type. Note that this storage class is not useful with MUTABLE variables, as the bulk of the storage they consume is in the data portion, not affected by storage class (see below).
UNIQUE acts like STATIC, but does not allow the exceptions given for STATIC; thus, a UNIQUE variable in an overlay is placed in the root segment; a UNIQUE variable in a subprogram simultaneously executing on several nodes of a parallel processor exists in one copy in the memory of one processor.
Note that, for MUTABLE, STRING, SET, GROUP, PATH, LIST, VLIST and TVAL variables, the storage class applies to the static descriptor part of the variable, and thus, in effect, it appears to apply to the variable as a whole although such variables are never stored in truly STATIC fashion.
Variables declared as having different storage classes cannot be EQUIVALENCEd to each other, or joined via INTERLEAVE, and so on.
A COMMON block has the type UNIQUE, and variables in that block must also have that type.
Note that the act of placing a variable, the storage class of which has not been declared, in an EQUIVALENCE, INTERLEAVE, or COMMON statement which requires it to be of a certain storage class, constitutes an implicit storage class declaration. This is true for the same reason that
REAL J
does not result in an error, although
INTEGER J
REAL J
does: default type attributes are soft, and subject to revision within the type declaration portion of a program.
CONTROLLED variables are stored in the same way as UNIQUE variables, but they are protected against being used in ways that may cause interference. No program may assign a new value to a CONTROLLED variable unless it first executes a statement of the form
LOCK variable,variable,...;alt-error
referring to that variable; and no other concurrent program may LOCK that variable until the procedure that has first locked it executes an UNLOCK (UNL) statement (same syntax, except no alt-error) referring to that variable, after which the first procedure can no longer make assignments to that variable.
A LOCK statement referring to several variables will not lock any of them until it becomes possible to lock all of them. (In practise, it may operate by LOCKing the first, then attempting to LOCK the second, and, if that fails, UNLOCKing the first, and then waiting until the second one is unlocked and trying again.) Attempting to LOCK a variable that is LOCKed by a concurrently executing process simply causes the program to wait until the variable is UNLOCKed by that process with the exception that if that process is also attempting to LOCK a variable that the first process now has LOCKed, an error results. If alt-error is present, abnormal termination is averted. Note that circular deadlock involving more than two parties is not prevented by this; to avoid that danger, LOCK all required variables at one time.
Note that this is a rudimentary form of one of the capabilities offered by APL shared variables; in FALCON, the name SHARED is given to a completely different access type.
VIRTUAL variables occupy a limited amount of internal buffer storage, but a VIRTUAL variable is a disk file or similar entity rather than an area in memory. Thus, the VIRTUAL statement has a different syntax than that of other storage class declaration statements:
VIRTUAL name:device,name:device,...name:device
and the device clauses are not optional. No device can have more than one variable assigned to it.
STACKED variables behave like AUTO variables, but each such variable can have new storage allocated to it by a PUSH statement, and the old value may be obtained by a POP statement, in which that variable is named. Each variable in this class, therefore, has a stack of its own.