This paper outlines a possible method of implementation of the sequence list, where files are executed in parallel. There are three major considerations: how to organise the file stack, what to store on the stack, and how to organise index variables. This paper does net consider the effects of SPSQLS, DLSQLS, RSSQLS or REPEAT.
The whole stack area will be initialised to a chain of storage blocks. Each sequence will have a stack of its own, so that information can be restored correctly. The places where the stack is accessed are
(a) On initial entry to the sequence execution
(b) On meeting ADVFLM
(c) On meeting DRAW
(d) On meeting FIDF
(e) On meeting ADSQLS
At the start of a DRAW sequence, it is necessary to save the current state information (the 'global' conditions). This will be saved once and each item in the sequence list will point to it (items in the. list can add more items to the list during execution).
It is likely that some information will be stored in the stack when this command is obeyed (what this is will be discussed in section 3). The next item in the sequence will be resumed from its currently interrupted point, and the state at that point will be restored. An 'advance frame' order will only be output if we are currently suspending the last item in the sequence list, and an ADVFLM order has been met in the latest pass. The first item in the sequence will then be restarted.
When executing a sequence list, DRAW just causes a new entry on the stack, with control transferred to the new file. No change of sequence list is required. Note that no sequence list entry is made when a DRAW is encountered within a sequence list item.
There are two possibilities
(a) This is not the end of a sequence list item. In this case the last stack entry is used to restore the state (according to the FIDF argument) and the sequence continues.
(b) This is the end of a sequence list item. If this is also the last remaining sequence list item, the picture terminates with the last item in the file stack being restored. If this is not the last remaining item, then the item and its stack are deleted from the sequence and the next sequence restored.
When a new item is added to the sequence list from inside that list, the initial stack pointer for this item may refer to the global conditions or to the conditions current at the time the ADSQLS order was obeyed. If we allow this latter case, then we must ensure that it is the global conditions that are restored at the end of the complete sequence draw.
Consider the following example (all commands which do not reference the stack have been omitted).
Note that, as soon as conditions have once been restored, the entry can be deleted from the stack, and also that only backward pointers are required. (Numbers refer to the sequence list.)
Two types of information will be stored in the stack (ignoring for the present any index variables). The first, defined in the manual, is relevant to the initial conditions, DRAW and ADSQLS stores. This means that the final FIDF obeyed in a sequence draw will determine how much information is to be restored. On initial entry to an item in the sequence list, ail starting conditions will be restored.
The second concerns ADVFLM. Consider the following two cases: use of the sequence list to superimpose two independent film sequences and use of the sequence list to cause camera panning. In the first, all the information stored on meeting ADVFLM should be restored to preserve sequence independence. In the second, however, the sequence list item is being used to change conditions in the sequence, so no restoration is required.
It is likely that, in a given item, all ADVFLM commands should behave in the same way. Thus an extra command can be provided which will tag an item on entry to the sequence list (similar in use to NUMBR) to determine what happens to the storage of ADVFLM. At most, the same information ought to be stored for this command as is stored for DRAW.
The current definition of index variables unfortunately does not go far enough. Although we have allowed naming of these variables, the connection between name and number is specified explicitly in the EQUIV command. A user at the PDP15 will find it difficult to keep track of numbered index variables unless a duplicate list is kept in the PDP15 also. This problem is overcome to some extent by changing the system so that index variables are always referenced by name. The system can give a name a number of a free variable when the name is first encountered. Array names will generate three extra names for the individual index variables referenced. Thus:
LOAD (ANAME ('FRED'), 2.0)
will 'create' index variable FRED (if it does not exist) and load 2 into it. It will be referenced as an argument by
PR ('FRED')
AR('FRED') will access the names
FREDI
FRED2
FRED3
for the three index variables. Hence an array might look like
LOAD(ANAME ('FRED1'), ANAME('MYFILE'))
LOAD(ANAME ('FRED2'), 1.0)
LOAD(ANAME ('FRED3'), 1.0)
AR ('FRED')
The three index variables, of course, need not now actually be consecutive in store.
However, index variables as defined do not cover the various different storage needs of SPROGS. There are three distinct requirements.
(a) Global variables, equivalent to FORTRAN COMMON. Index variables serve this purpose.
(b) Local workspace variables. Index variables will not suffice here. A user accessing a library file containing working variables will have to know the names of all such variables to avoid name clashes, and, even then, the use of such a file in two items of a sequence list may lead to the overwriting of information.
(c) Passing arguments. Again, index variables suffer from the same drawback as those in (b), but a local variable scheme will not work here, since local variables will not be known outside a file.
A comprehensive solution has yet to be worked out. There follows some thoughts on methods available.
4.1 If a scheme for passing arguments is devised, local variables could be named in the argument list. This may well considerably lengthen this list, and impose an extra burden on a user, who ~ does not really want to know anything about local variables used in library items.
4.2 A name list of variables could be saved on the stack during execution. This would probably cause a lot of store to be used, and add a variable block size to the problem of stack organisation. Global names would have to be declared to distinguish them. This would not take account of argument passing.
4.3 Each file has a small fixed number of local workspace variables associated with it (say 7). These can be stored in stack entries. If these items are named in some way connected to the file itself, it will be possible to reference them outside, and hence use them to pass arguments. The naming procedure must be such as to make them unique to a file (including file number?) and to make them distinguishable to routines such as LOAD, FR and AR to avoid duplicate sets of routines.
4.4 If a special command is used to set up arguments for a file, it will not be necessary to devise a unique naming scheme. The routine
ARG(X,Y)
could set value Y into the Xth argument of the net file entered. (X is here a number). It is then only necessary to distinguish global and local variables in a file. This could be done by using a spare setting of IPRMV (the marker word sharing type of display routine argument) to indicate local index variable, and use a routine like PR (say LR?), with a number argument, to access this variable. LOAD could have a function other than ANAME to indicate local variable settings. This scheme would not allow indirection of local variables, and using local variables as array references.
STDF ('FRED')
ADD (ALOCAL (1.0), 4.0)
TOXY (LR(1.0), PR ('Y'))
FIDF (1.0)
ARG (1.0, 20.0)
LOAD (ANAME ('Y'), 3.0)
DRAW (ANAME ('FRED'))
will draw a line to (24,3)