Re: interesting use of NEXT SENTENCE vs. CONTINUE


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

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

We don't really have general "compare" instructions as you seem to describe
them. We have unconditional and conditional branches in both static and
dynamic forms (BRUN, BRTR, BRFL, DBUN, DBTR, DBFL), and the conditionals are
based on the low-order bit of the word on the top of the stack, however that
might get there. There are lots of comparison things that might put a truth
value on top of the stack, and they're of varying complexity and cost. But
I can certainly envision "regular" COBOL logic that does a simple VALC
[one-bit item], BRTR where the code using ALTER might require NAMC [stack
cell containing label's current PCW], LODT, DBUN, and if that's the
comparison that's being drawn then I can't see why VALC, BRTR (or even VALC
[item-1], VALC [item-2], EQUL, BRTR or VALC, ZERO, EQUL, BRTR) should
necessarily be presumed *slower* than the case in which the comparison was
done once outside the logic but the branch itself would have to include
NAMC, LODT, DBUN. In the case of the dynamic branch the system has to be
alert to the possibility that it's a cross-segment branch, which raises the
likelihood that a presencebit interrupt would occur, in turn raising the
"overhead" of the instruction. The in-segment static branch does not
encounter that circumstance.

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

See above.


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

See above.

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

Comparing a *branch* with a *compare* may be valid in your environment, but
it doesn't really make sense in ours. Comparing the execution-time code
associated with "IF NOT <condition> GO TO NOT-FIRST-TIME" with the code that
resides at <label> for "IF <condition> ALTER <label> TO PROCEED TO
NOT-FIRST-TIME" is not the whole story.

How fast is the evaluation of <condition>? How far is up?

> Unfair! It MAY have to use a dynamic one... I take that point anyway.

In most cases the user has *some* control over that ...

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

Well, as a strong advocate of sticking to *standard* COBOL, I would repeat
that the COBOL community was put on notice some twenty years ago that ALTER
was doomed, and the construct has not been valid standard COBOL syntax for
nigh onto three years now ... ;-)

-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
    ... 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: 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: how to compare two time
    ... WC> int begin = time; ... WC> How about COBOL? ... When you want to compare times, it is better to use these functions ... FUNCTION INTEGER-OF-DATE which for many applications is more important ...
    (comp.lang.cobol)