SCOUG-Programming Mailing List Archives
Return to [ 21 |
March |
2005 ]
>> Next Message >>
Content Type: text/plain
The Programming SIG appears to be the Rodney Dangerfield of
SCOUG: we don't get any respect. While we continue to seek
our time in the monthly meetings we will make use of this
mailing list to make some progress.
Let's begin with a perspective on a program, namely a
program space, its components, and their storage attributes.
A program space (PS) has two components: an instruction
space (IS) and a data space (DS). So we can say that PS = IS
+ DS.
While the basic atom, element, or raw material of the IS is the
instruction these occur within assemblies. Above the
instruction level we have the assemblies known as "control
structures". We have three primary control structures: (1)
sequence, (2) decision (if...then...else...), and (3) iteration (do
while....). In addition we have two special cases, one for
decision (the CASE statement group) and one for iteration (do
until...).
The CASE statement group is essentially a nested sequence of
"if....then..." groups followed by an optional "else..." group. It's
a sequence and not simply a series because the order,
programmer determined, is important. The first statement of
the group, the SELECT statement, determines the variable
while each "if..." (WHEN) contains a value for the true/false
test. The optional "else..." (OTHERWISE) determines what
happens if no previous true instance occurs. Thus the
sequence for the statement group is
SELECT...WHEN...WHEN...WHEN... ...OTHERWISE...END.
The "do until..." differs from the "do while..." in that at least
one iteration occurs prior to testing for termination. Thus the
'do while..." allows for 0, 1, or more iterations while the 'do
until..." allows for 1 or more.
These five control structures (sequence, do while, do until,
if...then..else..., and select...when... ...end) form the basis for
structured programming. We can construct any program using
these control structures. We can restructure (reconstruct)
algorithmically any unstructured or "spagetti" program
automatically.
Moreover we can construct a structured program or
reconstruct an unstructured one into a structured form on the
basis of its executable machine instruction from only without
recourse to its source. That means if we decide that we need
only to use a single programming language, we can "convert"
existing programs from their executables only, a single
conversion program instead of one for each separate
language as well as differences which lie in versions within
the same language.
This does not occur by magic but relies in that every machine
instruction falls into one of three categories in terms of its
"exit" strategy: "n" for next sequential instruction (NSI) only,
"c" for conditional (either NSI or a "branch"), or "u" for
unconditional ("branch" only). Each of the control structures
have a specific form based on the use of "n" instructions in
combination with "c" and "u". Substituting these ("n", "c",
"u") for each machine instruction gives us an abstract from
which, one, we can topologically order (reconstruct) if
necessary, and, two, can topologically construct the source in
any language.
It's important to remember that control structures are
assemblies. That means that they can consist of other control
structures (assemblies) and statments (raw materials). Thus
you can develop a hierarchy, a bill of material, of control
structures. Each hierarchy at its top level is a "procedure" in
HLL parlance. A "program" in turn consists of one or more
procedures.
We've come this far and perhaps forgotten that the discussion
thus far has focused on the instruction space within the
program space only. We have considered only our ability from
the machine instruction level to create an abstract form
representing the control structure and procedure hierarchies
of a program: the ability to create a source from an
executable.
To complete the picture we need to do a similar analysis on
the data space which accompanies the instruction space
within a program space. We'll do that the next time in step
2...or maybe step 3.
=====================================================
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".
=====================================================
>> Next Message >>
Return to [ 21 |
March |
2005 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
|