Re: interesting use of NEXT SENTENCE vs. CONTINUE


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

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.

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.

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

To return to the original point: It is *not* a universal truism that ALTER
performs better than using an explicit run-time switch.

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

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.

-Chuck Stevens


.

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... >> This is where I argue that the TIME to do that compare cannot be faster ... > appears that BRUN consumes one clock or less. ... >> Your statement was that it may not on Unisys architecture. ... in Odene Dayse I worked on sites where ALTER was ...
    (comp.lang.cobol)
  • Re: Version after Version
    ... > Now I've been long removed from the architecture of the machine, ... > being able to load the equivalent of two 32 bit words with a single clock ... > would process twice as many bits of data for each clock cycle. ... In days of old the native word size of a cpu indicated the bus width. ...
    (alt.comp.lang.borland-delphi)
  • Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
    ... The architecture mentions varying time base frequencies, ... Clock spreading on the core clock is the bigger problem, ...
    (Linux-Kernel)
  • Re: Dynamical alteration of signal path
    ... likely that you could clock everything at N times the ... register holding the results from whichever processing ... can easily create a less flexible architecture that is ...
    (comp.arch.fpga)
  • Re: Bug Hotspot accelerates Windows system clock
    ... user process, and I guess I can run unprivileged although I would ... assume it will still alter the clock since it has something to do ... with low level thread seheduling, ...
    (comp.lang.java.machine)