Re: interesting use of NEXT SENTENCE vs. CONTINUE


"Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
news:3gnta2Fd8eb8U1@xxxxxxxxxxxxxxxxx
>

> Now THAT I find VERY interesting. I cannot conceive of an unconditional
> branch being slower than a compare on ANY architecture; can you elaborate
> what architecture and how/why a branch was slower than comparing two
> operands?

On a machine in which it is impossible for the object code to be changed
once it's been built, the technique of "stomping on" the branch instruction
isn't applicable. The Burroughs B5000 and all of its direct descendants are
such machines. If 150 programmers are each compiling 5 COBOL programs
simultaneously on a single system, all 750 compilations are sharing *the
same* copy of the object code for the compiler, both on disk and in memory.

It's my recollection that for at least early S/360 COBOL implementations the
object code generated for ALTER actually altered the code address in the
branch instruction to which the GO TO after the ALTERed LABEL pointed.
That's not the way it works, and that's not the way it *can* work on the MCP
systems today. The sort of branch instruction that is used for an ALTERed
label is different from the sort of branch instruction that's ordinarily
used for a simple GO TO, and it's more costly.

It's *arguable* -- and far from inconcievable -- whether something like
VALC, ZERO, GRTR, BRTR (a pretty-much-minimal ALTER-less conditional GO TO)
is unconditionally *less* expensive than something like NAMC, LODT, DBUN
(the code associated with an altered label). It's not the cost of the
compare that concerns me, it's the cost of the PCW manipulation (at the time
of the ALTER) and the dynamic branch (at the time of the GO TO). Note also
that the non-ALTER case uses *conditional* branches where the ALTERed GO is
unconditional.

There's also the impact of the Segmentation Module (present in '74, obsolete
in '85, gone in '02). If the section-number of the SECTION in which the
ALTERed label resides is 50 or greater, the GO TO has to be restored to its
initial state whenever (an oversimplification, by the way) control is passed
into that SECTION from outside of it (see ANSI X3.23-1974 Section IX or ANSI
X3.23-1985 Section XVI for details). I don't think it can be guaranteed
that the overhead associated with "diddling" this branch address back to its
initial state -- whether in a stack cell or in memory -- before actually
transferring control into the SECTION (to this label or elsewhere) from
outside of it is *unconditionally* less than the cost of the data
comparison!

Yeah, yeah, I know. "Nobody in his right mind would ever ... " ...

> It is like switching the points on a railway line.
>
> Takes some effort to move the lever but you don't have to do it very
often.

"You" may not be the one moving it explicitly. Just because you moved the
lever doesn't necessarily mean it stays moved (see above)!

> Actually the 'effort to move the lever' is simply loading another address
> into the operand of the branch instruction, and that would normally be
> faster than comparing two operands which are in memory, even if optimized
> direct or indirect addressing is used.

Maybe, maybe not.

> I have worked on 6 of the 7 major mainframe architectures (IBM and the
> UNCH - Burroughs, Univac, NCR, CDC, and Honeywell, and ICL) and all the
> ones I've worked on show an unconditional branch as the fastest executing
> non register-to-register instruction in their set.
> Even the Intel architecture has a branch (Jump) as faster than anything
else
> I can find.

Part of the issue is that the comparison-code may be able to use a *local*
branch where the ALTER-code has to use a dynamic one.

> I don't want to labour this because it really isn't that important, but I
> would dearly LOVE to know what architecture has a compare as faster, and
the
> reason for it.

I can't say it's *faster*, but I can say that any speed advantage associated
with ALTER on the Unisys MCP environment can be rendered negligible by
careful coding of the "first-time-through" variable setting and checking
logic. The argument for using ALTER in that context is not nearly as
compelling as it might be in other environments, if it's sustainable at all.


> We've all moved away from GO TO , and with good reason.
> With ALTER, it didn't have to 'go' anywhere... :-) the address could be
left
> null until you wanted to use it.

Depends on what you mean by "we" and "you", and whether "we" allow "GO TO .
", that is, without a "default" procedure-name.

"If procedure-name-1 is not specified in Format 1 [of the GO TO statement],
an ALTER statement, referring to this GO TO statement, must be executed
prior to the execution of this GO TO statement." (ANSI X3.23-1974 page
II-65).

If you've specified a procedure-name in the GO TO statement, then yes, it
still points to where it says until you alter it. But if you've done that,
you somehow have to know that if you did "GO TO SAFE-HAVEN", some part of
the program out there with the dragons in it could have changed it during
execution to be "GO TO WHERE-DRAGONS-ARE" entirely without your knowledge.

If the address is "null" when you execute the GO TO statement, the results
are nonportable. Our system would almost certainly do an operand-dynamic
branch using a variable containing zero, which would take you to the first
instruction of the current code segment, by convention an NVLD instruction
that would immediately terminate the program with INVALID OPERATOR.

> I agree. I use "axiomatic" to mean "self-evidently true". If it has to be
> explained, it is NOT self evidently true. Once people come to understand
> something (such as the performance implications you speak of), THEN it is
> axiomatic and no longer requires explanation. I am all in favour of people
> being trained and mentored and given understanding of the environment and
> how it works. As understanding grows, good standards can be agreed upon as
a
> natural spin-off.

I agree, but I've run into cases in which Management brought in new Experts
who came from a different environment and furthermore presumed that the
environment with which they were familiar was The Way The World Works. On
Unisys MCP systems, a one-digit unsigned packed data item occupies four bits
and comparisons of literals against it are very efficient, whereas a
one-digit signed packed data item occupies eight bits and comparisons of
literals against it are no better than PIC 9 or PIC S9 DISPLAY, and
considerably LESS efficient than even those against PIC X. If a user has
"compacted" his PIC 9 PACKED-DECIMAL flags into true four-bit fields (absent
a true Boolean data type), converting them to PIC S9 PACKED-DECIMAL on the
grounds that Everybody Who's Anybody Knows that 4-bit data Always, Always
has a sign might not prove to be a smart move.

> I see standards as being a helpful guide to new people joining the team.
The
> existing team already know why they do things the way they do.

A new team might not. The old team might even get replaced overnight.
That's why it gets written down.

> What I was trying to get away from is (just one example, there are,
sadly,
> many more...) the case where: "You will not use NOT in a condition" is a
> standard. Instead, run a session on basic logic and Boolean Algebra so
that
> people are not baffled by negated conditions when they encounter them, and
> also so they can realise that for all it's English-like qualities, COBOL
is
> still a computer programming language, and cannot tolerate the slack use
of
> logical operators that standard English can... ("You can't think in
> colloquial English and write good COBOL.")

Again, I agree; if the rules are written down, I would suggest not just "We
do <x> here" but expand that to "We do <x> here because ...".

In the specific case of complex conditions, and having been through the
COBOL standards' rules for precedence and condition evaluation very
carefully over the years for a variety of reasons, I've come to the
conclusion here that the problem lies with differing semantics for condition
abbreviation.

In English abbreviating the condition implies association of the implied
operators and operands with the comparand -- a level of parenthesization, if
you will -- but in COBOL it does not. I think that was one of probably
several mistakes in the COBOL standards; unfortunately it appears it was a
mistake made as early as the '68 standard (where abbreviated conditions seem
to have first made their appearance, based on sketchy evidence). Might have
been even earlier, but in any event unless abbreviated combined relation
conditions are moved through the archaic-obsolete-gone cycle first it ain't
gonna get fixed.

-Chuck Stevens


.

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... I am asking how a machine language BRANCH instruction (which has a SINGLE ... can be SLOWER than a machine language COMPARE instruction that has ... If 150 programmers are each compiling 5 COBOL programs ... possibility that ALTERED code in your environment may not be a good thing, ...
    (comp.lang.cobol)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > I am asking how a machine language BRANCH instruction (which has a SINGLE ... We don't really have general "compare" instructions as you seem to describe ... I can certainly envision "regular" COBOL logic that does a simple VALC ... necessarily be presumed *slower* than the case in which the comparison was ...
    (comp.lang.cobol)
  • Re: Performance of PACK/UNPACK instructions
    ... Cobol will pack before doing a compare for when the operands in the ... compare are not the same data type and atleast one operand is numeric. ... Cobol will not do a pack/unpack pair for a compare ... ... hence instructions like pack and unpack. ...
    (bit.listserv.ibm-main)
  • Re: How to find the greatest of two numbers without using the comparison operators?
    ... it HAD TO BE homework (because I can't think of any "good" reason to ... This may just be a typo,but Standard COBOL requires ... "A - B" is an arithmetic expression ... Is there any other operator in COBOL by which we can compare two ...
    (comp.lang.cobol)
  • Re: Were losing the battle
    ... Some people compare computers with transportation. ... Each tool has different standards, different costs, different ... For IBM-MAIN subscribe / signoff / archive access instructions, ... send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO ...
    (bit.listserv.ibm-main)