Re: interesting use of NEXT SENTENCE vs. CONTINUE

This is a good post. Thanks.

some comments below...

"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:d8ctcg$q7j$1@xxxxxxxxxxxxxxxxxxxxxxx
>
> "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
> news:3gsc9uFe0rs5U1@xxxxxxxxxxxxxxxxx
>
> > 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.)
>
> ...
>
> > 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.
>
> I found some figures from a somewhat-recent system.
>
> First case: Presuming no concatenation, branch prediction and so forth,
it
> appears that BRUN consumes one clock or less.

Can we blow away some of the smoke here...? I don't have access to your
manuals so could you please translate this op code into English? Is this an
unconditional Branch?
>
> Second case: The collection of operations (say, four instructions -- for
> example VALC, ZERO, EQUL, BRTR) required to retrieve properly-described
> numeric values to the stack, compare them against numeric literals, and
> branch conditionally based on that comparison should take four clocks or
> less.

And the BRANCH part of that would be BRTR? Again, it wouldn't hurt to
tranlsate this into English (at least once).

>
> In contrast, depending on the architecture, the three instructions needed
to
> accomplish a dynamic branch from an empty-stack state consume from around
> fifteen to as many as seventy clock cycles. Two of these are one clock or
> less (NAMC, LODT); it's the dynamic branch itself -- DBUN, as I've said
> before -- that's the killer. When ya gotta use it, ya gotta use it.
>

Why do I feel that this is obfuscation? Could it be that you are retreating
behind symbology that is known only to you? Makes it hard to have a
reasoned, informed , or fair argument.


> > 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.)
>
> DBUN is now, and has always been, more costly than the simplest of numeric
> comparisons taken in combination with static conditional branches, to say
> nothing of being more costly than the comparisons taken without associated
> logic to test the conditions.

And BRUN takes one clock cycle. So what does DBUN do and why would it be
used in preference to BRUN? "Translate" these instruction sequences into
what they do, in English, a language we both share, unless you have some
reason not to...I have not thrown a heap of IBM Assembler, (or any other) Op
Codes at you, to support my position; can you not show me the same courtesy?
>
> To return to the original point: It is *not* a universal truism that
ALTER
> performs better than using an explicit run-time switch.
>

I NEVER said it did and this is gross distortion of what I DID say. My
statement was qualified to specific platforms in cases where memory was in
short supply. I would EXPECT it to be an "universal truism" and am genuinely
interested as to why it apparently isn't.

Here's what I said:

"To digress for a moment, in Odene Dayse I worked on sites where ALTER was
used as a matter of course. It was extremely efficient and, in machines
with limited memory, was MUCH better than using IF for a first time switch,
for example. With IF, the first time condition is tested for every iteration
of the code; with ALTER, once only...(and IF required other machine code
overheads, which ALTER didn't.)".

There is no mention of 'universal truisms' there. It is, like all the
statements I make in posts here, limited to my personal experience. My
comment is qualified to "sites I worked on where ALTER was used as a matter
of course, and memory was in short supply".

> There are environments in which testing an explicit run-time switch in the
> source code is significantly more efficient than using ALTER.
>

And the results of a test designed to explore that have not been posted.

> And to answer the more recent point: there are environments in which the
> testing of a simple run-time switch does not outweigh the cost of *some*
> unconditional branches.
>

Not proven.

Pete.




.

Relevant Pages

  • Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
    ... My first experience with the ALTER verb was our shop standards when I ... are doing a compare that can never be true 9,999,999 times. ... You have removed 9,999,999 instructions from the execution. ... Or so "horrendous" it couldn't be maintained by a trained COBOL ...
    (comp.lang.cobol)
  • Re: Good economic news! + metalworking
    ... compare the 1929 "investment trusts" with the ... Unka' George [George McDuffee] ... for Time is the greatest innovator: ... and wisdom and counsel shall not alter them to the better, ...
    (rec.crafts.metalworking)
  • Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
    ... My first experience with the ALTER verb was our shop standards when I ... are doing a compare that can never be true 9,999,999 times. ... You have removed 9,999,999 instructions from the execution. ... Or so "horrendous" it couldn't be maintained by a trained COBOL ...
    (comp.lang.cobol)
  • Does a tool like this exist?
    ... I am looking for a tool/utility that can compare 2 tables (indexes and ... constraints etc.) and create a SQL script containing 'ALTER TABLE ...' ...
    (microsoft.public.sqlserver.tools)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... appears that BRUN consumes one clock or less. ... In contrast, depending on the architecture, the three instructions needed to ... To return to the original point: It is *not* a universal truism that ALTER ... There are environments in which testing an explicit run-time switch in the ...
    (comp.lang.cobol)