Re: interesting use of NEXT SENTENCE vs. CONTINUE

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
news:3hs4gvFi7bv8U1@xxxxxxxxxxxxxxxxx

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

Some comments on the code, if you were aiming for portability, and a few
other notes interspersed:

>
> IDENTIFICATION DIVISION.
> PROGRAM-ID. 'CHUKTEST'.

In the PROGRAM-ID syntax, <program-name> is a COBOL user-defined word, not a
literal (ANSI X3.23-1985 pages IV-6 and VI-7). As coded this ought to be
at least flagged as an extension if not outright treated as a syntax error.

Also, note that the apostrophe is not part of the COBOL character set in
ANSI X3.23-1985. It was added to the COBOL character set in ISO/IEC
1989:2002 and became acceptable in that standard as an alternative to the
quotation mark at that point. If compatibility with ANSI X3.23-1985, and
portability to other environments in that form, is required, then aside from
use *within* alphanumeric literals the apostrophe should be avoided.

> 01 subscripts usage comp.
> 12 J pic s9(18).
> 12 K pic s9(18).

Three things:

ANSI X3.23-1985 has USAGE BINARY. On a system that actually has a *binary*
processor for arithmetic, this might be both faster and portable. It might
be equivalent to COMP, it might not. It isn't on the Unisys MCP system, by
the way; COMP is PACKED-DECIMAL for historical reasons having to do with
Burroughs actually trying to make sure programs were portable across widely
disparate Burroughs architectures back as COBOL74 was being developed.
Imagine that! What a concept!

ISO/IEC 1989:2002 adds a bunch of USAGEs that strike me as really
Wintel-friendly -- binary-char, binary-short, binary-long, binary-double,
all in signed and unsigned flavors, occupying no less than 8, 16, 32 and 64
bits each respectively -- but they're unavailable in *standard*
'85-compliant COBOL.

Regardless of USAGE, our system's boundary between single and double
precision is at 11 decimal digits. Any arithmetic involving items declared
PIC S9(12) or greater will be quite a bit slower than the same arithmetic
using items declared PIC S9(11) or smaller. Your choice of number size is
platform-dependent.

Since there is no intrinsic relationship among 'J' and the unreferenced 'K'
and 'subscripts', why impose a physically-hierarchical relationship among
them? The argument that the *group* USAGE of subscripts, namely COMP,
percolates down to J doesn't convince me.

If J can be made an independent item which the compiler can put wherever it
deems most efficient by declaring it at Level 77, why not do so? Putting
something in a physical record imposes retrieval methodologies that may be
less efficient than if the compiler knew, by virtue of the level number,
that the datum was independent. You can always use comments to identify
such groups for source-file searching purposes.

> 01 run-flag pic x value space.
> 88 OK-to-run value '1'. *> Single byte compare
> *> should be minimal
> overhead
> *> on most platforms

Might be, but might require descriptor-based access on some. I'd personally
prefer (note the quotation marks):

77 run-flag pic 9 binary extended value 0.
88 OK-to-run value "1".

so that access is directly to the stack rather than being through a
descriptor on the stack, or an optimization that loads a word from the
descriptor on the stack and isolates the 8 bits out of it for testing.

> DISPLAY 'test1' UPON CONSOLE

If you've got an "UPON" clause in DISPLAY, the "mnemonic-name" used there
has to be associated with a hardware device in SPECIAL-NAMES. In our case
you'd need to add
SPECIAL-NAMES. SPO IS CONSOLE.
to your program.

> ACCEPT timeDisplay FROM TIME

Well, hmm. "TIME ... behaves as if it had been described ... as an unsigned
elementary numeric integer data items eight digits in length." (ANSI
X3.23-1985 page VI-72). Why not declare timeDisplay "PIC 9(8) DISPLAY"?
For that matter, I can imagine it might be useful to deal with the results
arithmetically, and presuming the implementation provides for the conversion
of non-display information into USAGE DISPLAY form as part of the operation
of the DISPLAY statement (I can't really imagine that any implementation
mightn't!), the cost of the data conversions you're imposing can be
significantly reduced!

Another thing: This works as coded, but TIME is only granular to the
hundredths of a second, and represents elapsed time. In our environment you
never know when the MCP is going to interrupt you and for what reason, so
elapsed time is not a particularly good measure. In our case, we have an
(extremely ancient!) extension called TIMER that reads out in
2.4-microsecond increments; we also have the ACCUMPROCTIME task attribute
that reports the "CPU time" in the same increments, accessible through the
extended syntax "MOVE ATTRIBUTE ACCUMPROCTIME OF MYSELF TO timeDisplay".
The *least intrusive* measure is TIMER (a single machine instruction!), but
you have to have a quiet system for the results to be meaningful, and ours
has above 400 simultaneously-active user tasks at the moment (and most of
the time).


> DISPLAY timeDisplay UPON CONSOLE

DISPLAY generates a fair amount of code. When we're doing code timings like
this we use different data items for start and end time (wanna have the
computer actually calculate the elapsed time for you? Can you imagine how
useful that might be?), and save the DISPLAYs until we're done with the
timing.

> COMPARISON-TEST SECTION. *> needs a section because the other test has an
> *> internal GO TO and overheads must be the same
> for both.

Syntax error. ANSI X3.23-1985 page IV-35: "If one paragraph is in a
section, all paragraphs must be in sections."

> CTS001.
> IF OK-TO-RUN *> this serves the function that a first time
switch
> might
> *> in normal code

Ummm... why the limitation? Looks to me like a reasonable first-time switch
regardless of context!

> BRANCH-TEST SECTION.
> BT001.
> GO TO BT002 *> this emulates the unconditional branch that would be
> *> set by an ALTERed GO TO

.... No, no, no. That's true in your experience based on the presumption
that ALTER *always* modifies the address parameter of the hardware branch
instruction in memory.

Our system has a hardware branch instruction, and that hardware branch
instruction has an address parameter.

But once the compiler puts that address parameter there, it is not changed.
It's not changed by the program, it's not changed by the compiler, it's not
changed by the Binder (somewhat like IBM's linkage editor), it's not changed
by the MCP. It's what got writ to the code file by the compiler, period,
forever and everywhere.

Our system prohibits, through cooperation and convention between hardware
and software, the object code from changing itself either on disk or in
memory, because to do so would render it impossible for multiple users of
the same object code file to share the same instantiations of its code
segments in memory. You do 500 COBOL compiles on your system, you've got
*one* copy of the Code Segment Dictionary, and no more than *one* copy of
any object code segment from the object code file in memory at any given
time. Data and code are *STRICTLY* separated on our system. It's not that
you MUSTN'T execute data or modify code, it's that you CAN'T. The hardware
and the MCP will prevent you from doing it. *ALL* object code on the system
is by nature reentrant, including that of the MCP itself.

Note that that's not exactly new. The strict hardware-enforced separation
of code from data dates back to the original design of the Burroughs B5000,
from the early 1960's.

> IF J NOT = 100000000 *> this is loop overhead. Same for both tests.
> ADD 1 TO J
> GO TO BT001
> END-IF
> .

Yes, it's the same for both tests, but how costly it is depends on how J is
declared. Same is true for run-flag as its declaration affects the timing
results for the first test.

-Chuck Stevens


.

Relevant Pages

  • Re: Inside an FBI Computer Forensics Lab
    ... properly reproduce or validate a piece of hardware. ... open source tools and well established procedures and methods are used ... like me could trivially design a black box which satisfied every ... possible to create a compiler that will recognizes your code during ...
    (alt.privacy)
  • Re: UART RS232 "hello world" really taking shape now.
    ... executed at ELABORATION time - the COMPILER takes ... the hardware just sees a lookup table. ... you could stick with the nice simple "goto address" ... MSG "At B" ...
    (comp.arch.fpga)
  • Re: C to Java Byte Code
    ... The actual topic is about creating a Java equivalent for a C program. ... as well have argued that a byte, int, long, float, double can all be ... The values of the compiler depend on the underlying hardware. ...
    (comp.programming)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... Program name in quotes (allowed in '02 Standard) ... > If J can be made an independent item which the compiler can put wherever it ... > has to be associated with a hardware device in SPECIAL-NAMES. ... > that ALTER *always* modifies the address parameter of the hardware branch ...
    (comp.lang.cobol)
  • Re: whats taking up room and resources?
    ... just got slower with usage. ... With that hardware you are running on, ... >> after some app set to run on start up; that app (might be a driver as ... >>>shown running, no processes other than system idle, but CPU showing ...
    (microsoft.public.windowsxp.basics)