SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Tue, 12 Apr 2005 07:40:04 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Progress--Step 3

Content Type: text/plain

Before getting on to this I want you to know that missing this
month's meeting was a difficult decision for me. It just turns
out that many conflicts occurred.

Peter seems concerned that the speakers cannot fill up 90
minutes for presentations. He has been at the same meetings
as we have over the last months. I'm not aware that any of
them have ever been able to come under that limit. If they
had, then we would have no concerns about the time
available in the morning for the Programming SIG.

While I have no objections to Peter's use of REXX, I also know
that he has a PL/I compiler. It comes with no "ups, adds, or
extras" necessary: complete. Moreover if he didn't have it, he
could get a free copy complete with documentation. I know
he appreciates the help, but he has an available choice in
which no such help is necessary.

Now on to the main thread.

As a gentle reminder we have a program space composed of
an instruction space and a data space. Both instructions and
data have static and dynamic spaces which have different
binding times. Those binding times occur either prior to
execution, at entry to execution, or during execution. While I
won't pursue it here these binding times have a whole
calculus devoted to them: the lambda calculus. For those
more curious and with some time on their hands for such
study do a google search on "lambda calculus".

The first two steps covered the static and dynamic aspects of
the instruction space. I this step we will look at the static and
dynamic aspects of a data space...and their binding times.

Another gentle reminder before we continue. The binding
time of the program logic occurs when writing the source
code. I don't really care that LISP (and its derivatives) and
FORTH allow programs to modify themselves, i.e. they can
alter program flow, they can't do it on their own outside of
the logic already encoded for the modification. It's bound,
bound, bound in the source and no one except in fantasy and
science fiction has ever demonstrated any other possibility. I
hate to have to spell it out, but the brain in no manner
resembles a computer, because it does, it allows what no
computer does.

Using PL/I terms we have four different storage attributes for
data: static, automatic, controlled, and based. The static
storage is bound at compile time;the automatic, at entry to
execution;and the controlled and based during execution.
Thus you have static and dynamic (automatic, controlled, and
based) storage with different binding times: prior to, at entry
to, and during execution.

Now when you declare a variable in PL/I you control its
storage attribute, e.g. 'dcl a char(20) static;' or 'dcl b fixed
dec (7,2) based;' The difference between these two is that
the compiler allocates the space for 'static' storage while the
programmer allocates based storage during execution. Thus
only one copy of a static storage variable exists prior, at, and
during execution. Only one copy of an automatic storage
exists at and during execution, while multiple copies
(allocations) of controlled and based storage variables can
exist during execution.

Now why do you need dynamic storage? After all major
programming languages like COBOL and earlier versions of
FORTRAN only allowed static variables. Basically you have
automatic to support re-entrancy and recursion. It gained
initial acceptance in ALGOL when that was the specification
language used by the ACM. As PL/I was initially to be
FORTRAN VI the presence and thus the competition from
ALGOL, first implemented as a programming language by
Burroughs as BALGOL, gave the impetus to support both static
and automatic storage.

Thus in either a re-entrant (multiple threads invoking the
same procedure) or recursive (a single thread invoking the
same procedure multiple times) program, the instruction space
remains constant while the data space varies, increasing on
procedure entry and decreasing on procedure exit.

As far as I know the 'controlled' storage attribute is unique to
PL/I. Take the data declaration, 'dcl beta char(40)
controlled;'. You create a copy of it with the 'allocate'
statement: 'allocate beta;'. You free it with the 'free'
statement: 'free beta;'.

Each controlled variable has a stack associated with it. An
'allocate' statement allocates the space and places it on top
of ("pushes" down) the stack; the 'free' statement frees the
space and "pops" up the stack. In reality the stack is a linked
list. The allocate statement places the variable at the head
of the list. The free statement removes it from the list,
moving its "head" to the next (possibly null) entry in the list.

All processing for a controlled variable takes place on the last
allocation. Suppose, for example that we wanted to create a
table, an array of character variables, from an input. Suppose
further that we didn't know how many input instances we
had. We can read them from the input, allocate them onto a
stack, maintain a count of the allocations, and on reaching
end of file allocate an array of the correct dimensions. Then
we could pop them from the stack, assigning them to their
relative position in the array.

example: proc options(main);
dcl beta char(40) controlled;
dcl array (*) char(40) controlled;
dcl count fixed bin (31) static init(0);
dcl eof_sw char(1) static init('0');
dcl input file input record;
on endfile (input) begin;
eof_sw = '1';
close file (input);
end;
open file (input);
allocate beta;
read file (input) into (beta);
do while eof_sw = '0';
count += 1;
allocate beta;
read file (input) into (beta);
end;
if count ^= 0
then do;
allocate array (count);
end;
do while (count ^= 0);
array(count) = beta;
free beta;
count -= 1;
end;
.
.
.
end example;

A couple of things to note here. One, the ability to declare a
variable with a unknown dimension, e.g. 'dcl array (*)
char(40) controlled;'. Here the asterisk denotes that the
actual dimension is obtained at allocation. Two, despite its
internal implementation as a list instead of a physical stack,
controlled variables do not support list processing. For that
we need 'based' variables. We go there next.

Based variables also use the 'allocate' and 'free' statements.
Based variables, however, do not have to be allocated in
order to be used. For example, 'dcl beta char(40) based;'
functions as a description, an applicable template wherever it
is based. Where it is based depends upon the address which is
attached to it at execution.

That address is obtained through the use of the 'addr' builtin
function. It requires the use of pointer variables, e.g. 'dcl moe
ptr static;'. From our previous example we can obtain the
address of any element in 'array',
e.g. 'moe = addr(array(count));'. If we then use "pointer
qualification" designated by '->',
e.g. 'moe -> beta = "Happiness is yours";',
we will have changed the value in 'array(count)'.

We have a choice of declaring a base variable with a specific
or default pointer, e.g. 'dcl beta char(40) based(moe);'. In this
case we could have written our previous statement as
'beta = "Happiness is yours";'.

So a based variable has a use as a "floating" description. Had
we declared a second pointer variable, e.g. 'dcl manny ptr;',
we could have the statement 'manny->beta = beta;'. As a
floating description it can "float", i.e. redefine, any space
occupied by any named variable through use of the 'addr'
builting function.

If, for example, you had the following declarations:

'dcl beta char(4) based(moe);
dcl uppity fixed bin (31) based(moe);
dcl chance fixed dec(4,3) based(moe);',

they would redefine any address set in 'moe'. What you see
here is what the 'union' declaration does in C, having multiple
different data types define the same space.

Now note that as you allocate and free based variables the
data space will expand and contract accordingly. However,
using a based variable as a description only with pointer
qualification through use of the 'addr' builtin function does not
impact the "size" of the data space.

But the real advantage of based variables lies in their support
of list processing. We'll save that for the next step. At this
point we have covered the static and dynamics of instruction
and data spaces along with their binding times.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 12 | April | 2005 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.