Re: interesting use of NEXT SENTENCE vs. CONTINUE


"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:d99ead$2uev$1@xxxxxxxxxxxxxxxxxxxxxxx
>
> "Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message news:...
> >
> > "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.
>
> To return to this point: There are some assumptions in here that aren't
> universal.
>
> In Unisys MCP terminology, a fixed part of a machine instruction isn't an
> "operand". Generally speaking, an "operand" on this architecture is a
data
> word, not a code word, a control word, or a descriptor already on the
stack.
> An "operand" is also *not* part of the machine instruction itself; fixed
> information contained within the instruction is referred to as a
> "parameter".
>
> A "static" BRANCH instruction has no operands; it has a *parameter*
(within
> the instruction, with a fixed value) that includes the word address within
> the segment in which the branch occurs (13 bits), and the syllable address
> within that word (0-5), to which control is to pass. A code word has a
tag
> of 3 and cannot be an operand. By convention and by enforcement all
> executing instantiations of an object program share a single copy of the
> object code segments, both on disk and in memory, and any overwriting of a
> code word would destroy that architectural feature.
>
> As stated before, there is no single "compare" instruction with two
> arguments. A numeric comparison is done between two operands on the
stack,
> and is quite rapid. Comparisons of alphanumeric data require two
> descriptors on the stack pointing to data in memory and is more costly.
In
> the former case, the cost of the comparison has to include the cost of
> putting the numeric values onto on the stack (with conversion if
necessary);
> in the most trivial case the value is stored in the proper form and can
> simply be retrieved. A compare of two operands -- or of an operand and a
> literal -- can be cheap indeed or it can be expensive.
>
> For the cheapest case, the instruction for the retrieval of a value
doesn't
> have an *operand* either -- the stack cell location to be retrieved is
> encoded within the instruction proper. A constant value to be placed on
the
> stack is encoded in the instruction proper (ZERO, ONE, LT8, LT16 and LT48
> are all in the same family; the corresponding instructions are B0, B1, B2
> [8-bit literal], B3 [16-bit literal] and B4 [48-bit literal aligned at the
> next word in the code stream). EQUL requires two operands -- both
already
> on the stack
>
> A "dynamic" branch instruction has a single (dynamic) top-of-stack
argument.
> That argument may be an operand (in which case it's treated as an integer
> directing control to pass forward or backward within the current segment),
> it may be a Tag-7 word (a Program Control Word), ent number and the word
and
> syllable address within that segment to which control is to pass, or it
may
> be an Indirect Reference Word chain that ultimately leads to a PCW.
>
> The case of most interest here is the second, with a PCW argument. A PCW
> (ultimately) contains the index into the Actual Segment Descriptor table,
> maintained by the operating environment, whose entry corresponds to the
> object code file's code segment to which the branch is to proceed; at the
> very least, the hardware checks the table entry to find the associated
> object code segment already in memory before transferring control to the
> word and syllable location specified in the original operand. Whether,
and
> how long, that code segment remains in memory after any given execution of
> code within it is dependent on processes entirely outside the program's
> control, largely, the amount of available memory on the system and the
> likelihood that that particular code segment (which need not be saved to
> disk) will be marked as absent to make space for data.
>
> The point here is that the processing of the variable argument when that
> argument, strictly speaking, isn't an *operand*, gets quite expensive.
>
> -Chuck Stevens
>

Thanks for the explanation, Chuck. I have followed the posts with interest
and understand the difference in the architecture.

This post, in particular, is clear.

I compiled the code and ran it.

To my amazement, The unconditional branch code was a fraction slower than
the comparison code! (This was over 100,000,000 iterations which took around
3 seconds with the counter defined as COMP. With it defined as COMP-5
(optimal for this platform) it took under a second...

It took me some time to realise that the Fujitsu compiler had figured out
the condition could never change, so it simply ignored it after the initial
test...<g>

Compiler writer: 1, application programmer: 0 :-)

What I have learned from all this:

1. Platforms vary widely. The Unisys architecture you describe is different
from anything I have encountered before.
2. Optimizing compilers can render much of the discussion on efficiency that
goes on in CLC.... redundant and academic.

I also found that the overheads in arithmetic conversion (at least on the
Intel platform), are much more significant that either branching or
comparing.

So, if I was really ocncerned about efficiency (which I am not particularly)
I should be looking to minimise data conversions in my COBOL programs; that
is much more important from an efficiency POV than ALTERED GO TOs or
comparisons.

Thanks for the time you put into this, I found it enlightening.

Cheers,

Pete.

PS Here's the code I used. I tried many variations on it. (In the ones where
I could prevent optimization, the branch was, indeed, faster than the
compare and branch. But it was always a whisker and nowhere near as
significant as I had believed at the start of this exercise.)

IDENTIFICATION DIVISION.
PROGRAM-ID. 'CHUKTEST'.
*
*AUTHOR. Peter E. C. Dashwod.
*
*Compares the time taken for comparison and unconditional branch
*
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
*
*------------------------ DATA DIVISION -----------------
DATA DIVISION.
WORKING-STORAGE SECTION.
01 subscripts usage comp. *> On the Intel platform 'comp-5' would be best
but
*> I'm keeping it transportable...
12 J pic s9(18).
12 K pic s9(18).
01 run-flag pic x value space.
88 OK-to-run value '1'. *> Single byte compare
*> should be minimal
overhead
*> on most platforms
01 timeDisplay pic x(10).

01 holdit pic x.
PROCEDURE DIVISION.
BEGIN.
MOVE ZERO TO J
SET OK-TO-RUN TO TRUE
DISPLAY 'test1' UPON CONSOLE
ACCEPT timeDisplay FROM TIME
DISPLAY timeDisplay UPON CONSOLE
PERFORM COMPARISON-TEST
ACCEPT timeDisplay FROM TIME
DISPLAY timeDisplay UPON CONSOLE
DISPLAY 'end test1' UPON CONSOLE
MOVE ZERO TO J
DISPLAY 'test2' UPON CONSOLE
ACCEPT timeDisplay FROM TIME
DISPLAY timeDisplay UPON CONSOLE
PERFORM BRANCH-TEST
ACCEPT timeDisplay FROM TIME
DISPLAY timeDisplay UPON CONSOLE
DISPLAY 'end test2' UPON CONSOLE
ACCEPT holdit
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
IF J NOT = 100000000 *> this is loop overhead. Same for both
tests.
ADD 1 TO J
GO TO CTS001
END-IF
END-IF
.
BRANCH-TEST SECTION.
BT001.
GO TO BT002 *> this emulates the unconditional branch that would be
*> set by an ALTERed GO TO
.
BT002.
IF J NOT = 100000000 *> this is loop overhead. Same for both tests.
ADD 1 TO J
GO TO BT001
END-IF
.






.

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... a fixed part of a machine instruction isn't an ... word, not a code word, a control word, or a descriptor already on the stack. ... of 3 and cannot be an operand. ... object code file's code segment to which the branch is to proceed; ...
    (comp.lang.cobol)
  • Re: Integrating LaTeX tables into "Word"
    ... The listing to the console shows two problems. ... starting of the script. ... instruction, and the other delete instructions, in the script, ... MS Windows commands for making conditional requests. ...
    (comp.text.tex)
  • [PATCH] xen: suppress known wrmsrs
    ... just ends up ignoring the instruction and printing a message on the ... console noise. ...
    (Linux-Kernel)
  • Console Application - Stop and await input
    ... I am wanting to stop my console application and see the information which has ... people do some sort of keyboard prompt when the application is awaiting some ... this instruction. ...
    (microsoft.public.dotnet.languages.csharp)