Re: interesting use of NEXT SENTENCE vs. CONTINUE

Thanks for posting this, Chuck.

I'm not entirely persuaded, but I found it very interesting.

Some comments below.

"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:d87edh$ide$1@xxxxxxxxxxxxxxxxxxxxxxx
>
> "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.

Yes, I realise that. I am NOT advocating the use of ALTER in modern
environments.

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 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.
Yes, that is true. It worked simlarly on several other architectures also,
including Burroughs B500 (which I programmed in both Assembler and COBOL.)

> 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.
>
Good. That clears that up. We can agree that ALTER is 'best avoided' in
modern environments.

Now can we discuss why a Branch instruction is slower than a compare, if it
is...?

> 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.
>
Understand that.
Now can we discuss why a Branch instruction is slower than a compare, if it
is...?

> 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 ... " ...
>

This is CLC. Might be best not to discuss 'right minds'.... :-)

> > 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.
>

Well you have presented a good enough case to at least suggest the
possibility that ALTERED code in your environment may not be a good thing,
but I'm not convinced on the actual speed of branch vs compare. I think the
'maybe not' in your sentence above needs expansion...


> > 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.

Unfair! It MAY have to use a dynamic one... I take that point anyway.
>
> > 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.

OK, that is honest and fair. We can leave it there. I'm satisfied that it
isn't faster. I also accept your arguments that any speed advantage is lost
in other overheads.



> 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.
>

I would not advocate the use of ALTER in COBOL in modern environments
(except as a possible wind-up to some people here who take this whole COBOL
thing much too seriously...).


>
> > 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).
>

Yes. But you have no idea the intellectual satisfaction that could be
derived from coding: GO TO.

....in a COBOL program. Of course we made sure the points were set before the
train arrived, but there is an almost quantum surrealism about code that is
coded to be indeterminate. It makes me think of Scroedinger's cat... and
probability waves collapsing an instant before the express roars across the
junction... Does the non-explict GO TO shown above actually point to EVERY
SINGLE ADDRESS in the program before it is executed? Heisenburg and Feynman
think it does; far be it from me... Who knows what particles and GO TO
statements are doing when we are not looking at them? <G>


> 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.
>

Nope. This is procedural programming. NOTHING happens without the
programmer's knowledge.

I understand you are positing a multi-use environment with shared code but I
still don't think so... There would have to be separate instances for ALTER
to work at all...

> If the address is "null" when you execute the GO TO statement, the results
> are nonportable.

That's why we made sure the points were set before the train arrived....


> 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'd like to think that most systems of any worth would misbehave under this
circumstance...

> > 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.
>

It's annoying when fresh approaches are introduced, isn't it... <G>

> > 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.
>

I agree with all of this.

> > 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 ...".
>

Sure. If it helps. It is no longer axiomatic, but that is just a
philosophical objection anyway.

Pragmatism must usually be preferred to philosophy (otherwise, philosophers
would starve to death... :-))

> 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.
>

You might well be right. I have seen differing interpretations of implied
subjects and objects and it really is confusining. This is something else I
avoid, personally.



> 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.
>

Thanks for a stimulating response, Chuck.

Pete.



.

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... It's my recollection that for at least early S/360 COBOL implementations the ... branch instruction to which the GO TO after the ALTERed LABEL pointed. ... compare that concerns me, it's the cost of the PCW manipulation (at the time ... > I see standards as being a helpful guide to new people joining the team. ...
    (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: Comparing 2 recordsets to get Missing or Different
    ... I took your example and tried to make it fit my interface: ... (This lets the user choose an environment) ... >>> You seem to indicate you want to compare all rows from within your table ... >>> tblAIPProfileVariables T2 ...
    (microsoft.public.access.queries)
  • Re: WICKED OT: Comments on Gone Baby Gones ending?
    ... single horror on the planet more-or-less instantly available. ... But compare that to the firebombing of Dresden or Tokyo, ... starting to clean up their act in recognition that durable industry ... While I mostly agree with you, I disagree about the environment part. ...
    (alt.smokers.pipes)
  • 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)