Re: interesting use of NEXT SENTENCE vs. CONTINUE

Chuck may or may not know this, but others may be interested.

Almost ALL the "extensions" to the '85 Standard used by Pete and pointed out by
Chuck are valid in IBM COBOL(s) and those PC or workstation compilers that
support "compatibility" with such.

Program name in quotes (allowed in '02 Standard)
Apostrophe equivalent to quotation mark (included in '02 Standard)
Comp is equivalent to Binary (some but not all Workstation compilers - not
required in '02)
*> as inline comment indicator (not allowed on IBM mainframe - allowed in '02
Standard and many PC compilers
Display upon device-name without Special-Names (NOT allowed in '02 Standard -
allowed by most PC compilers)
Accept from device-name (see above)
Some paragraphs in sections, some not (I *think* allowed in '02 Standard)

Bottom-Line:
Portability depends on where you plan to port (or more likely where you end-up
porting to but did NOT plan on <G>)

Use of "ANSI" of "FIPS" flagging CAN tell you what is portable source code ...
but is (from my experience) rarely actually very useful.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:d9cbn7$1las$1@xxxxxxxxxxxxxxxxxxxxxxx
> "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: [patch] spinlocks: remove volatile
    ... But gcc would follow the standard if it emitted a 'lock' ... In low level system programming there is no fscking way for the compiler ... All those things have hardware dependend semantics ... gcc just isn't correct on normal hardware. ...
    (Linux-Kernel)
  • Re: Adding thread support for C...
    ... and that's why it should not be part of the C language. ... >> the compiler emits code. ... > Unfortunately, according to the standard, the compiler is ... The memory hardware might. ...
    (comp.programming.threads)
  • Re: [patch] spinlocks: remove volatile
    ... >> not follow the C standard on modern hardware. ... > insn on every volatile reference. ... In low level system programming there is no fscking way for the compiler ... All those things have hardware dependend semantics ...
    (Linux-Kernel)
  • Re: Storing _Bool in a single bit
    ... I suppose some operations would make that impossible, but provided that all such conditions are met, would the standard allow it? ... The Standard does not support hardware that uses any memory element of less than 8-bits. ... That does not mean that you cannot have a C compiler for such hardware, but it needs extensions to make best use of the hardware. ...
    (comp.std.c)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)