Re: interesting use of NEXT SENTENCE vs. CONTINUE


"Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
news:3gsc9uFe0rs5U1@xxxxxxxxxxxxxxxxx
>
> "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.

My IBM S/360 PoO has long since faded into the sunset, so I must postulate
the existence of an instruction to draw the proper comparison.

The BC seems to correspond loosely to our BRTR and BRFL instructions. I
seem to remember a BR <n> instruction; what I don't remember if there was a
BCR (or BRC) instruction, where you might (or might not) branch to the
memory address pointed to by register <n> based on the tested condition.

This is (or would be) *something like* the dynamic branch used on our
system, except that the "register" is actually the Top of Stack, and the
boolean value being tested is underneath it.

While the contents of one of the General Purpose Registers back in S/360
(and where I encountered it more often, on an Interdata 3) are
straightforward, the contents of a PCW as used in a DBxx instruction are
not, they represent considerable indirection, the resolution of which is a
combined responsibility of hardware and system software. A DBxx
instruction is *at very best* only somewhat slower than a BRxx instruction.


I converted the program to COBOL74 and ran it using your two examples, plus
a third in which an ALTER was *actually used*. The object code for the
"busywork" incrementing of J is the same.

The case in which a numeric on-stack value for 1 on each update of J
consumed approximately 1% more time than the case that included a pure local
branch in the same location.

The case in which the first paragraph had been ALTERed to proceed to the
second consumed very nearly three times as much processor time as either of
the other two.

The difference between the "pure local branch" case and the "altered branch"
case is precisely the differing object code for the unconditional branch,
namely, NAMC, DBUN instead of BRUN.

In our enviromment it is *significantly* more costly to execute a GO TO
that's the target of an ALTER than it is to execute a GO TO that is not the
target of an ALTER. On a NX6830 it's about THREE TIMES as costly.

Even fairly complex conditional expressions can be shown to be less
expensive than this. YMMV, but I'm pretty sure it will vary based *only* on
the time consumed for evaluation of the conditional, which can be reduced to
negligibility through informed coding.

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

When the comparison is trivial -- get a value, branch on true or false.
VALC, ZERO, EQUL is also really, really inexpensive, at least on our larger
systems.

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

What's a register? ;-) Everybody knows that a data item is either on
the stack or it's not, and all numeric comparisons are done on the stack
anyway. "Informed coding" as mentioned above includes ensuring that
critical-path data items are declared on the stack in the first place.

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

Proven wrong in my experience.

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

A dynamic branch -- conditional or otherwise -- can be quite a bit more
expensive than a simple condition evaluation, depending on the nature of the
expression and of its components.


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

That depends on how "smart" the particular model of machine is in analyzing
and executing groups of instructions. The "cycle time" for each step taken
in isolation may be utterly meaningless; what counts is the overall resource
consumption of the construct, and in the case of a GO TO statement that's
been ALTERed, it's greater than that of a GO TO that hasn't, but a good
margin.

The question is whether an *unconditional branch* is always faster than a
*comparison*, and the answer is "no, not always, and it can be a whole lot
worse."

> OK, why not get timings for both? Presumably instruction cycle times are
> documented?

No, not all machines execute their instructions linearly, and instruction
cycle times are specific only to individual processor models, not to the
entire architecture.

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

That presumes that "cycle times" for instructions taken in isolation are
meaningful. In your universe they may well be, but ...

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

Then the whole of your contention is *wrong* as a generalization.

My experiments prove that at least in *some* subset of the universe of
systems, an unconditional branch that happens to be "dynamic" not only takes
a whole lot more time than an unconditional branch that happens to be
"static" but also a whole lot more time than a simple numeric comparison
taken in combination with a static conditional branch. The difference is
significant.

And I agree that it is not merely a matter of ALTER; if the code associated
with the label BT001 in your example happens to be in a different code
segment (NOTE: that's not necessarily the same thing as in a different
SECTION) the same performance difference will be observed. The point here
is that with ALTER, as with a cross-segment branch, the static branch
*cannot* be used.

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

Couple of bugs in it, as written. Won't compile as is ... ;-)

There is no significant difference between the behavior of an ALTERed GO TO
statement and a GO TO statement that is determined at compile time to point
to a different code segment; the mechanisms are the same, and they are
equally costly. Most GO TO statements prove to be within the same code
segments as their destinations, whether ALTERed or not.

-Chuck Stevens


.

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > the existence of an instruction to draw the proper comparison. ... > memory address pointed to by register based on the tested condition. ... > case is precisely the differing object code for the unconditional branch, ... Won't compile as is ... ...
    (comp.lang.cobol)
  • Re: How does this make you feel?
    ... >> XOR instruction that applies to a 1M range of VM; ... > register gives a memory address, and the second gives a byte-count (up ... in a CPU that has one execution pathway. ... instruction set and the specifics of its addressing modes; ...
    (comp.arch)
  • Re: Designing my own architecture to be simulated in software - need help with the ISA
    ... > memory address range is limited to 16 bits. ... > I'm reserving the HO byte of the word for the instruction type, ... The register operands are half-bytes in length, ... > sub - store the difference of two registers in a register ...
    (comp.arch)
  • Re: How does this make you feel?
    ... > instruction was added that allowed you to, for instance, extract a column ... >> + Maybe C and UNIX distorted CPU design, ... > supporting interrupts efficiently was a design goal for the transputer. ... behaviour of a conventionally conceieved register. ...
    (comp.arch)
  • Designing my own architecture to be simulated in software - need help with the ISA
    ... I'm reserving the HO byte of the word for the instruction type, ... The register operands are half-bytes in length, ... defining an instruction set. ... sub - store the difference of two registers in a register ...
    (comp.arch)