🚀 go-pugleaf

John Leonard wrote:

>Structured code is not an end unto itself, structured coding is done to
>make code easy to read, thus easy to understand and maintain.
>With that thought in mind consider the following examples
>
>
[snip]

>With native assembler in the first example nothing has to be compiled you
>can simply read the code.
>In the second example you have to compile the code to understand that the
>two branches go to the same place, further because each of the generated
>labels will be unique you have to look at the offset from the base
>register in the generated code to determine that the two labels are
>actually in the same place. Put 400 lines of code in between the two
>branches tell me what you would rather read.
>
>

Not sure what you're thinking about here. It makes absolutely no sense
to say that you must compile code to understand it. Is it easier to
understand what a C compiler generates than to look at the source code??
Of course not! And your "examples" aren't using any macro set I've ever
seen before.

There are only a limited number of constructs in structured programming.
(Indeed, it has been shown by mathematical proof that any logic problem
can be solved using only iteration, choice, and sequence.) The way the
structured constructs behave is known both by the programmer writing the
code and the programmer maintaining it. Programs that use a limited set
of well-known constructs are considered easier to read because tedious
inspection of "custom" coding constructs is not required. It's not even
a question of spaghetti vs. structure. There is a virtually unlimited
number of coding constructs possible using native assembler language.
I've seen a lot of them and I'm always coming across new ones.

One reason highly structured languages like ADA are considered so
powerful is that they limit the programmers ability to create custom
constructs -- forcing them instead to program using a small but rich set
of constructs that all ADA programmers understand a-priori. The same is
true of HLASM SPMs. The behavior of the constructs is intuitive and
understood by all. There is no need to compile the code and follow the
generated branches to know how the construct behaves.

For example, I'll wager that everyone reading this understands how this
code fragment works:

|     SELECT CLI,0(R1),EQ
|     WHEN value1
|       .
|       . (code for value1)
|       .
|     WHEN value2
|       .
|       . (code for value2)
|       .
|     WHEN value3
|       .
|       . (code for value3)
|       .
|     OTHRWISE ,
|       .
|       . (handle all other cases)
|       .
|     ENDSEL ,

This is the equivalent fragment written in traditional assembler
language. It runs no faster or slower, yet illustrates several
unfortunate aspects of the language in that it provides opportunities
for corruption of the structure by exposing LABELA, LABELB, LABELC, and
LABELX at the source code level, requires more "housekeeping" code on
the part of the programmer (seven more lines of source code) making the
routine appear longer, and provides more opportunity for coding errors
e.g., typos on the CLI statements and branches to the wrong labels.

|         CLI   0(R1),value1
|         JNE   LABELA
|         .
|         . (code for value1)
|         .
|         J     LABELX
|LABELA   DC    0H
|         CLI   0(R1),value2
|         JNE   LABELB
|         .
|         . (code for value2)
|         .
|         J     LABELX
|LABELB   DC    0H
|         CLI   0(R1),value3
|         JNE   LABELC
|         .
|         . (code for value3)
|         .
|         J     LABELX
|LABELC   DC    0H
|         .
|         . (handle all other cases)
|         .
|LABELX   DC    0H

Another benefit we have found using the SPMs is that writing programs
without labels provides more "real estate" for programming. Once you
realize that columns 1-9 are (nearly) always blank, you start
questioning whether starting opcodes in column 10 is the best practice.
When you're limited to 71 columns in most cases, a few extra columns can
really make a difference!

As a side note, we use long, mixed-case, self-describing names for all
"legitimate" labels in programs. When you see something like 'JAS
R14,UpdateBinaryTree' it also adds to the readability of a program. Of
course, this can be done with our without the use of SPMs, I just
thought I'd mention it here...

--
 -----------------------------------------------------------------
| Edward E. Jaffe                |                                |
| Mgr, Research & Development    | edjaffe@phoenixsoftware.com    |
| Phoenix Software International | Tel: (310) 338-0400 x318       |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801            |
| Los Angeles, CA 90045          | http://www.phoenixsoftware.com |
 -----------------------------------------------------------------