Re: interesting use of NEXT SENTENCE vs. CONTINUE


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

I don't want to say ITSA so I'll say ITSLIKE...
The Branch on condition (BC) in BAL.

Your 'low order bit' corresponds to the 'condition code' set in IBM
architectures. Except that you only have two states.

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

Yes, and they must have at least two operands? Comparison is meaningless
without two things to compare...

And these two things must be in memory. We are not considering register to
register comparisons here, unless we consider unconditional branch on
register address against them. Let's keep oranges and apples in separate
baskets...

This is where I argue that the TIME to do that compare cannot be faster than
the time to do your branch (irrespective of the branch being unconditional
or conditional, or static, or dynamic.)

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

We are no longer discussing code generated for an ALTER.

I have agreed all of that.

My contention is regarding machine instructions: Namely, comparison and
branch.

If your 'comparison' breaks down into a series of steps (and you are not the
only architure where this happens) then we need to get the cycle time for
each of the steps.


> 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.
>
OK, why not get timings for both? Presumably instruction cycle times are
documented?

It should be easy to look in the documentation and get the cycle times.

The whole of my contention is that comparison MUST take longer than
branching. Nothing to do with ALTER (any more...:-))

Your statement was that it may not on Unisys architecture. I can't believe
it. (I'm not saying you're wrong because I am not an expert in this
architecture, but logic and experience tell me it simply doesn't make sense.
So there must be something I am missing here... or not.)
<snip>
>
> 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.
>
I think it is.

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

Easy. Here's some code. (Courtesy of Pete's Unseen String Measurement
Factory)

BEGIN.
MOVE ZERO TO J
SET OK-TO-RUN TO TRUE
DISPLAY 'test1'
(display the time, including milliseconds, if available, using whatever
COBOL construct is best on your machine)
PERFORM COMPARISON-TEST
(display the time, including milliseconds, if available, using whatever
COBOL construct is best on your machine)
DISPLAY 'end test1'
MOVE ZERO TO J
DISPLAY 'test2'
(display the time, including milliseconds, if available, using whatever
COBOL construct is best on your machine)
PERFORM BRANCH-TEST
(display the time, including milliseconds, if available, using whatever
COBOL construct is best on your machine)
DISPLAY 'end test2'
STOP RUN.
COMPARISON-TEST SECTION. *> needs a section because the other test has an
*> internal GO TO
and overheads must be the same for both.
CTS001.
IF OK-TO-RUN *> this serves the function that a first time switch might
in normal code
CONTINUE
END-IF
IF J NOT = 10000000 *> this is loop overhead. Same for both tests.
ADD 1 TO J
GO TO CTS001
END-IF
.
BRANCH-TEST SECTION.
BT0001.
GO TO BT0002 *> this emulates the unconditional branch that would be
set by
. *> an ALTERed GO TO
BT002.
IF J NOT = 10000000 *> this is loop overhead. Same for both tests.
ADD 1 TO J
GO TO BT001
END-IF
.

If the branch test is slower on your UNISYS mainframe, I'll be convinced.

And feel free to rearrange this code (after you have run it as is...:-)) to
cause any of the situations you discussed with page segments, dynamic
branching, and so on...

Pete.


.

Relevant Pages

  • Re: J4 - presentation/discussion on "Future of the COBOL Standard"
    ... I ask why WOULD it be slower? ... the extra instruction is small compared to the time to execute the move. ... Micro Focus' efficiency advice is exactly the same on every platform, ... becomes zero, rather than incrementing the counter from zero to n. ...
    (comp.lang.cobol)
  • Re: Cobol Myth Busters
    ... Of course, whether adding 5 is slower, or faster, than adding 1 is completely ... Or he was thinking of a LOOP instruction. ... but it gives an insight into optimization. ... Facts incorrectly interpreted are less useful than an absence of facts. ...
    (comp.lang.cobol)
  • Re: IF NOTs
    ... a" will will slower than "FALSE a". ... case (executing x) would be slower than the "TRUE b" case (also ... conditional jump instruction. ... zero as needed. ...
    (comp.lang.forth)
  • Re: 80386 support in -current
    ... So, indeed, xchg is *lot* slower on p4 in non-SMP case than cmpxchgl, I ... functions in atomic.h to use cmpxchg instead of xchg, ... cmpxchgb %b1,%0; jnz 1b"); ... >>particular instruction which was introduced with the 486 and must be ...
    (freebsd-current)
  • Cycle count utility program?
    ... Any tool that will tell each instruction and how much cycles it takes? ... The display would be something like: ... Instruction Cycles ... ADD reg, reg N2 ...
    (comp.lang.asm.x86)