Re: Is it always possible to write a COBOL program using only 1 sentence per paragrap

Re:
compute x = function length (str)
perform varying strlen from x by -1 ...

In the '02 Standard, one could code a conforming:

Perform varying strlen from Function Length (str) by -1 ...

And, in fact, if the correct "repository" paragraph was coded (to allow omis
sion
of "FUNCTION" keyword), one could code:

Perform varying strlen from Length (str) by -1 ...

which would (in MOST cases) provide the same results as the "extension" code
:

Perform varying strlen from Length of str by -1 ...

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11e5405rddbchf1@corp.supernews.com...
>
> "Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
> news:joe_zitzelberger-2F5770.11542623072005@ispnews.usenetserver.com... 
>
> It is not clear to me that I "intentionally handicapped" anything.
> I do not use LENGTH OF because it is non-standard and, with
> the exception of COMP-5, I believe the extensions that I did use
> (such as, unnamed paragraphs in sections, exit perform, and
> partial expressions in the EVALUATE statement) are all
> available in the 2002 standard. For flexibility, I would normally
> write something like:
>
>    compute x = function length (str)
>    perform varying strlen from x by -1 ...
>
> This is, at least, standard. However, flexibility was not a
> consideration, code size was.
> 
>
> The optimizing compiler I use does not unroll loops. In fact,
> when I enabled some specific optimizations (OPTSPEED and
> NOTRICKLE), the loop version slowed and the unrolled loop
> sped up for lengths of 0 and 16, but slowed for a length of 32.
> There is something happening that I do not yet, and may never,
> understand; but the program was unimportant for all but one
> reason.
> 
>
> Which has nothing to do with the reason for the code. The
> code was presented to demonstrate that *sometimes* larger
> is faster. I was aware of this because I have unrolled loops
> before and achieved speed gains on the order of 50 to 800
> percent, in long running programs; that is, those programs
> were the speed up was important (savings of hours per
> execution, sometimes a hundred or more hours per year).
>
>
>