Re: interesting use of NEXT SENTENCE vs. CONTINUE

I went back through the thread via Google (the earlier stuff has ridden off
into the sunset on our server), and found this:

<<I am asking how a machine language BRANCH instruction (which has a SINGLE
operand), can be SLOWER than a machine language COMPARE instruction that has
TWO operands. >>

The short answer is that neither "machine language BRANCH instruction" nor
"a machine language COMPARE instruction" require comparable resources on all
platforms in all environments.


> And why did you convert it to COBOL 74?

Two reasons: 1) I wanted to provide a lowest common denominator in
ANSI-standard COBOL. 2) I wanted to compile it with COBOL74 because I'm
more familiar with the internal workings of that compiler (having been
keeping it shipshape for over twenty years now) and could better follow the
*compiler's* internal reasoning. 3) The COBOL74 compiler makes more use of
the stack in this stack-architecture machine than the COBOL85 compiler does.
This is a tradeoff; the Lex Level 2 Display stack is a limited resources,
and a design criterion for COBOL85 was to allow much larger monolithic
programs than COBOL74 allows. 4) The user has object code segmentation in
the Unisys MCP COBOL74 implementation than in the Unisys MCP COBOL85
implementation.

> It is a conceptual thing and I want to know why something that logic tells
> me SHOULD be so, apparently isn't, on Unisys hardware.

I've described this at length, in detail, and dare I say it ad nauseam,
elsewhere.

> Show me the money. Post the test results. After that we can discuss
> implications for Unisys.

Given as a base line the following code, in which J is declared "77 J
PICTURE S9(11) BINARY EXTENDED", which is about as efficient as you can get
in COBOL74, and only slightly less so in COBOL85 (which discourages on-stack
variables because it's a precious resource), and given the generation of
object code that is upward and downward compatible across the entire
currently-supported Unisys product line:

COMPARISON-TEST SECTION.
CTS001.
IF OK-TO-RUN
IF J NOT = 10000000
ADD 1 TO J
GO TO CTS001.

The following code requires about 6% more time; the only difference is the
(static) unconditional branch instead of the comparison in the first
example:

BRANCH-TEST SECTION.
BT001.
GO TO BT002.
BT002.
IF J NOT = 10000000
ADD 1 TO J
GO TO BT001.

Presuming AT001 has been ALTERed to GO TO AT002, the following code requires
about 205% more time (that's just over triple the time) compared to the
first example:

ALTER-TEST SECTION.
AT001.
GO TO AT002.
AT002.
IF J NOT = 10000000
ADD 1 TO J
GO TO AT001.

For COBOL85, the first example produces the same code as for COBOL74, and
thus runs for the same length of time. Because the GO TO BT002 at paragraph
BT001 is optimized out of existence by COBOL85 for this test case, the
second example consumes some 8% *less* time than the first. And because
COBOL85 builds some "safety-net" code into GO TO statements that are
targeted by ALTERs, the code generated thereby consumes almost exactly 300%
(FOUR times, compared to THREE times with COBOL74) as much time as the first
example.

If you want to know the code sequences: Given
77 RUN-TEST PIC S9(11) BINARY EXTENDED VALUE 0.
88 OK-TO-RUN VALUE 1.

Let's say the "base code" consists of
label-1:
<other examples have code here>
label-2:
VALC (J), LT8 (10000000), NEQL, BRFL (label-3) ["IF J NOT = 10000000"]
VALC (J), ONE, ADD, NAMC (J), STOD ["ADD 1 TO J"]
BRUN (label-1) ["GO TO CTS001/BT001/AT001"]
label-3:

The 88-level test that goes between label-1 and label-2 is
VALC (RUN-TEST), ONE [=OK_TO_RUN], EQUL, BRFL (=OK-TO-RUN VALUE), BRFL.

The unconditional branch test that goes between label-1 and label-2 for the
second example from COBOL74 is simply
BRUN (label-2).
COBOL85 omits this and adjusts all refeences to both labels to point to the
same place.

The COBOL74 ALTERed GO TO code that goes between label-1 and label-2 is
NAMC (stack cell assigned to AT001), DBUN.
The corresponding COBOL85 code is much more complex, and I'm not posting it
here.

GO TO BT002" is simply BRUN (address of BT002). This is absent from the
COBOL85 code.

The COBOL74 "AT001. GO TO AT002" is NAMC (stack cell for AT001), DBUN.
The COBOL85 code for the above isn't worth posting.

Now, COBOL85 example 2 represents the "base code".

Example 1 (both languages) adds about 8.4%. That's the additional cost of a
pretty-much-minimal test-and-branch-conditional sequence -- VALC, ONE, EQUL,
BRTR/BRFL.

When a BRUN is added to the base code (per COBOL74 Example 2) the time
increases by about 33%. Note that that implies that the extra BRUN is
*significantly* more expensive than a simple comparison and a conditional
branch. I suspect that's because the particular hardware I'm running on
isn't expecting a branch to the next syllable that ends up being a NOOP
(NoOperation, in case this point wasn't clear).

When NAMC, DBUN is added to the base code, the aggregate cost is about 216%
of the base code alone. Thus, this particular flavor of "unconditional
branch" is not only more expensive than the cost of a simple
compare-and-branch, it's more expensive than the entire body of code it
controls.

-Chuck Stevens


.