Cobol - "Goto statement considered superfluous" (was: If you were inventing C)

Author

"Goto statement considered superfluous" (was: If you were inventing C)

Richard

2004-09-28, 3:55 am

"Howard Brazee" <howard@brazee.net> wrote

> I don't think it would. It already was significantly different from other
> languages of the time. We would have used the tool as given to us.

In what way was it 'significantly different' ? It was developed as a
common subset of Flow-Matic and the other languages in the
acknowledgement in every Cobol manual. It used ideas from many
business languages. Its major distinction was that it was 'common',
ie the same on every system rather than the existing business
languages which were different from each other.

> I also don't think that removing ADD, SUBTRACT, MULTIPLY, and DIVIDE would have
> hurt it. We learned to use those verbs because they were part of the tool.

It certainly would have hurt it unless they also provided COMPUTE
(which didn't arrive until '74).

The problem with COMPUTE is that it uses an intermediate result that
may make the calculations much slower than using the discrete
statements. In 1960 there was no 'power to burn' in the CPUs and
forcing the use of COMPUTE would have hurt the language greatly.

Even in the 80s there was a reluctance to use COMPUTE due to
performance issues. For example I was running MF CIS Cobol on
multiuser 2.5 MHz machines.

Similarly in the 80s C was not displacing Fortran because C promoted
real to double in function calls. Fortran used the parameters as
specified and this often meant that Fortran would outperform C, and
still does.

Joe Zitzelberger

2004-09-28, 3:55 am

In article <culel0161kn9jkaek60qgk093s5c1vbm76@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:

<snip>
> Although 64-bit is rare on desktops,
<snip>

Macs are not rare -- just elite. I believe they qualify as "desktops".

;-)

Richard

2004-09-28, 3:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>
> Ok, here are two:
>
> DELL DIMENSION 2400 INTEL PENTIUM 4 2.8GHZ,

That is not 64 bit.

> Processor Class: Athlon XP

That is not 64 bit.

2 for 2 is about par for the course for you.

To be 64 bit it must be Pentium 4EE or Athlon 64.

Richard

2004-09-28, 3:55 am

"Chuck Stevens" <charles.stevens@unisys.com> wrote

>
> That depends on who "they" is!

They = users of machines where ALTER saved space and instructions ..

We are talking about 1959.

> Machines that modified their own object
> code, maybe. Not so clear for machines that didn't, and don't to this day

There was probably much less reason to use ALTER there.

Nothing illustrates the extent that had to be gone to to get computers
working in the 1950s than an example in 'Early British Computers'.
Using mercury tube delay lines the computer was capable of doing
several instructions in the time taken to cycle the memory tubes. To
cater for that every instruction contained a 'next instruction
address'. The program would be timed and laid out in memory as far as
possible so that the data words being used and the 'next instruction'
were about to come around when the instruction being processed
required them.

docdwarf@panix.com

2004-09-28, 8:55 am

In article <koydnfQKGvxj4sncRVn-hA@giganews.com>,
JerryMouse <nospam@bisusa.com> wrote:
>Richard wrote:
>
>Today, however, any programmer who chooses a technique based on
>micro-efficiency without a compelling reason ("the boss told me to do it
>that way" is one), should be shot.

Hmmmmm... consider a trivial example of 88-level conditions. Given a
choice between:

01 WS-ACTION-FLAG PIC X(06) VALUE SPACES.
88 AWAITING-DECISION VALUE SPACES.
88 ADD-REC VALUE 'ADD '.
88 CHANGE-REC VALUE 'CHANGE'.
88 DELETE-REC VALUE 'DELETE'.
88 OTHER-MAINT VALUE 'OTHER '.

.... and ...

01 WS-ACTION-FLAG PIC X(01) VALUE SPACES.
88 AWAITING-DECISION VALUE SPACES.
88 ADD-REC VALUE 'A'.
88 CHANGE-REC VALUE 'C'.
88 DELETE-REC VALUE 'D'.
88 OTHER-MAINT VALUE 'O'.

.... and the associated code to manipulate and query these conditions -
given that 'Set (cond) To True' can be used instead of 'Move (literal) To
WS-Action-Flag' - would you insist that using the single-character format
is an executionable offense?

(The Procedure Division code would be identical and the reason I was
taught to prefer the single- over the multi-character was, precisely,
micro-efficiency, in that it generates the equivalent of CLI/MVI mnemonics
while the multi- generates CLC/MVC... and the difference between the two
is a factor of three.)

DD

Robert Wagner

2004-09-28, 8:55 am

On 25 Sep 2004 20:22:04 -0400, docdwarf@panix.com wrote:

>In article <saqbl05ph5l5tcmm5rj6mquub8848chdrm@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>Given that particular architecture this might be the case, Mr Wagner...
>but when the architecture is ignored then what you state becomes
>irrelevant, as your statements are about hardware.

It's the same on other architectures such as Intel, Power, SPARC, etc.

docdwarf@panix.com

2004-09-28, 3:55 pm

In article <959cl097b32oeu9s680oib9p7tpqnitvd0@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 25 Sep 2004 20:22:04 -0400, docdwarf@panix.com wrote:
>

[snip]
[color=darkred]
>
>It's the same on other architectures such as Intel, Power, SPARC, etc.

It is still unclear, Mr Wagner... are you saying that since all machines
are 64-bit architectures then the differences between all
machine-instructions are null... or that the example I chose to
demonstrate how machine-instruction efficiencies might need to be
considered is, as was clearly labelled at the start, 'trivial'?

DD

docdwarf@panix.com

2004-09-28, 3:55 pm

In article <07mdl0he2olqprif8btd40o0ubv7efavqg@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 26 Sep 2004 08:22:18 -0400, docdwarf@panix.com wrote:
>
>
>I didn't say that, although it happens to be true. Generally, all
>instructions run in one clock, unless they operate on multiple words.

Not being familiar with 'all instructions' on all possible platforms I can
neither agree nor disagree with this assertion.

>
>
>That's it. The example you chose doesn't support your point .. not
>even trivially.

If the flaw is in the admittedly trivial example, Mr Wagner, and not the
principle upon which the example is based, then perhaps a person of
knowledge, sound principles and generosity of spirit might examine the
depths and ignore the trivial... the question remains, it seems, open.

DD

Howard Brazee

2004-09-28, 3:55 pm

On 27-Sep-2004, LX-i <lxi0007@netscape.net> wrote:

> But, of course, I wasn't the one advocating the firearms education
> plan... :) Based on my experience, I would turn my eyes toward MOVE
> and IF statements as a source of a bottleneck dead last. In every
> performance tuning exercise I've been through, the bottleneck was either
> database access or communications.

Absolutely. I was just pulling out simple, obvious code where a bit of
optimization has no real cost. Unfortunately, its benefit is small compared to
optimization based upon understanding data structures and communications needs.

The goal in this thread was to make my example obvious and simple. In real
life, our goals are to save money. And it is quite possible to make much more
significant efficiency savings without obfuscating code.

docdwarf@panix.com

2004-09-28, 3:55 pm

In article <la4bl09so0qq9g937jssv7h7hpt3635a3v@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 25 Sep 2004 09:44:55 -0400, docdwarf@panix.com wrote:
>
>
>A 64-bit machine runs both at the same speed. It accesses memory (and
>cache) 8 bytes at a time.

I'm not sure what you are trying to communicate here, Mr Wagner... are you
suggesting that all programming should be done with the limitations of a
64-bit architecture in mind?

DD

Robert Wagner

2004-09-28, 3:55 pm

On 25 Sep 2004 22:09:56 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>
>Please send me some 64 bit machines so that I no longer need to care
>about such issues.

Ok, here are two:

DELL DIMENSION 2400 INTEL PENTIUM 4 2.8GHZ, 256MB DDR RAM, 80GB HDD,
64MB SVGA, 52X CDRW, DVD-ROM, 10/100 NIC, 5.1CH SOUND, 2-USB, MID
TOWER CASE 400W P/S, KEYB & MOUSE, WIN XP HOME BLACK COLOR (NEW)

$ 489.00

http://www.pchardware4u.com/details...=18&SKU=8016211

Processor Class: Athlon XP
Processor Speed: 2.08 GHz
Installed Memory: 512 MB
Hard Drive Capacity: 120 GB
Included Drives: 3.5" 1.44 MB floppy, DVD-ROM, CD-RW
Network Support: Ethernet, Fast Ethernet
Modem Speed: 56 Kbps
1 Year Warranty from the Manufacturer

$494.25

http://www.pcrush.com/prodspec.asp?...7986&refid=1058

Joe Zitzelberger

2004-09-28, 3:55 pm

In article <217e491a.0409231452.a02b4da@posting.google.com>,
riplin@Azonic.co.nz (Richard) wrote:

> It certainly would have hurt it unless they also provided COMPUTE
> (which didn't arrive until '74).
>
> The problem with COMPUTE is that it uses an intermediate result that
> may make the calculations much slower than using the discrete
> statements. In 1960 there was no 'power to burn' in the CPUs and
> forcing the use of COMPUTE would have hurt the language greatly.
>
> Even in the 80s there was a reluctance to use COMPUTE due to
> performance issues. For example I was running MF CIS Cobol on
> multiuser 2.5 MHz machines.

Just because a few implementors were unable to make two logically equal
statements generate the same machine code does not make an entire verb
bad.

I've seen COMPUTE -v- ADD/SUB/MUL/DIV statement tests even into the
1990s. In most cases they were rigged to make compute look bad to
satisify preconcieved notions of the testers.

Weather the compiler generatesm or the programmer hand codes the
intermediate fields, they are, in most cases, needed for the logical
calculation. You can time individual ADD/SUB/MUL/DIV and claim they are
faster, but you will still need to use your own intermediate fields to
reach the same conclusion as a simple COMPUTE.

Rick Smith

2004-09-29, 8:55 am

"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-4F21F5.00152824092004@knology.usenetserver.com...
> In article <217e491a.0409231452.a02b4da@posting.google.com>,
> riplin@Azonic.co.nz (Richard) wrote:
>
>
> Just because a few implementors were unable to make two logically equal
> statements generate the same machine code does not make an entire verb
> bad.
>
> I've seen COMPUTE -v- ADD/SUB/MUL/DIV statement tests even into the
> 1990s. In most cases they were rigged to make compute look bad to
> satisify preconcieved notions of the testers.
>
> Weather the compiler generatesm or the programmer hand codes the
> intermediate fields, they are, in most cases, needed for the logical
> calculation. You can time individual ADD/SUB/MUL/DIV and claim they are
> faster, but you will still need to use your own intermediate fields to
> reach the same conclusion as a simple COMPUTE.

Whether such intermediate fields are used is a function of
the optimizer. By limiting the number of significant digits
in the intermediate result, additional instructions are avoided.

For example,

compute d = (a + b) * c

where a, b, c, and d are 32-bit binary means the temporary
item produced by '(a + b)' may be 64-bits on some machines;
'* c' would.

The equivalent,

move a to temp
add b to temp
multipley c by temp
move temp to d

where temp is also 32-bit binary means all 32-bit operations;
because the optimizer is being informed that results will never
exceed 32-bits. The optimizer may assign temp to a 32-bit
register and never store the intermediate results. The absence
of 64-bit operations improves performance, at least, slightly.

Both USAGE and compiler truncation options will influence
performance. COMP-5 with no truncation is faster, where
COMP-5 is defined as native binary. For COMP-2, compute
is faster, where COMP-2 is defined as native floating-point.

The same considerations apply to

if a + b < c

versus

move a to temp
add b to temp
if temp < c

For Micro Focus, such examples and additional tips are
given in their references under 'Performance Programming'.

Howard Brazee

2004-10-02, 8:55 am

On 24-Sep-2004, "JerryMouse" <nospam@bisusa.com> wrote:

> Today, however, any programmer who chooses a technique based on
> micro-efficiency without a compelling reason ("the boss told me to do it
> that way" is one), should be shot.

The definition of "compelling reason" is variable.

And micro-efficiency without significant a cost in understanding or
maintainability doesn't need a compelling reason.

Let's say the following occurs once per day.

Is there a reason to shoot the person who writes the 1st version of this code,
saving 6 assembler moves per day?

MOVE THIS-DAY TO COMPARE-DAY
PERFORM VARYING DAY-INDEX FROM 1 BY 1 UNTIL DAY-INDEX > 7
IF COMPARE-DAY = DAY-OF-WEEK (DAY-INDEX)
PERFORM FOUND-ONE
END-IF
END-PERFORM

PERFORM VARYING DAY-INDEX FROM 1 BY 1 UNTIL DAY-INDEX > 7
MOVE THIS-DAY TO COMPARE-DAY
IF COMPARE-DAY = DAY-OF-WEEK (DAY-INDEX)
PERFORM FOUND-ONE
END-IF
END-PERFORM

docdwarf@panix.com

2004-10-02, 8:55 am

In article <217e491a.0409241111.14147389@posting.google.com>,
Richard <riplin@Azonic.co.nz> wrote:
>"Rick Smith" <ricksmith@mfi.net> wrote
>
>
>In 1960 _all_ programming was 'performance programming'.

Well put, Mr Plinston, and despite the reminders that Mr Simmons and
others post a consideration which is frequently forgotten.

DD

docdwarf@panix.com

2004-10-02, 8:55 am

Howard Brazee

2004-10-02, 8:55 am

Robert Wagner

2004-10-03, 3:55 pm

On 26 Sep 2004 11:33:34 -0400, docdwarf@panix.com wrote:

>In article <07mdl0he2olqprif8btd40o0ubv7efavqg@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>Not being familiar with 'all instructions' on all possible platforms I can
>neither agree nor disagree with this assertion.
>
>
>If the flaw is in the admittedly trivial example, Mr Wagner, and not the
>principle upon which the example is based, then perhaps a person of
>knowledge, sound principles and generosity of spirit might examine the
>depths and ignore the trivial... the question remains, it seems, open.

In the old days, one could take machine language, look up instruction
timings and sum them to determine how long a passage of code would
take to execute. Branches taken and calls were especially expensive,
which is why we unrolled loops and inlined functions.

All that has changed on modern CPUs. Using Intel's Itanium as an
example (others are similar), the machine can execute up to three
instructions in parallel, and they need not be the next three nor even
in sequence; it can execute two floating-point instructions in
parallel and has four integer math processors; it has the next ten
instructions in a high-speed on-chip cache, with addresses resolved.
It remembers which way a conditional branch went last time and
speculatively follows the same path for cache loading. The effect is
to automatically unroll ALL loops, and reduce to zero the execution
time of a branch. It has 6M of Level 3 memory cache in the package,
96K of Level 2 cache on-chip, and 32K of very high speed Level 1
cache, so nearly all memory access is running at cache speed rather
than memory speed.

As a result of all these on-chip optimizations, one can no longer
calculate how long code will take to run. If you want to do
micro-efficiency, the lowest you can go is the algorithm level.

Robert Wagner

2004-10-03, 3:55 pm

On 26 Sep 2004 12:13:50 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>
>What percentage of all those machines are 64 bit ? Given that Intel
>is about 90% of all machines and 99% of them are not 64bit, and for
>example there is _no_ 64bit Cobol compiler for Intel that I am aware
>of, then your vague assurances are not productive.

Although 64-bit is rare on desktops, it is common on servers and
mainframes. Intel is testing the low-end waters with the 64-bit
Pentium 4, and AMD with the Opteron. Complete computers with either
chip sell for $500.

Fujitsu had the first 64-bit Cobol in 1999, for IA-64. Micro Focus
compiles to 64-bit IA-64, SPARC and Power PC. IBM Visual Age compiles
to Power PC and IA-64. IBM mainframe Cobol compiles to 64-bit
z/Architecture. Unisys Clear Path compiles to 64-bit Wintel ES7000,
also IA-64.

Robert Wagner

2004-10-03, 3:55 pm

On 26 Sep 2004 19:21:11 -0400, docdwarf@panix.com wrote:

>In article <0a0el0p65oh7aheiqatpgr7c11s5spn1ps@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>So what you appear to be saying, Mr Wagner, is that not only did the
>example I chose not support my point but that *no* example could support
>the point... which is it, please?

No example will support the point that one can tell how fast code will
run by looking at assembly language .. including z/Architecture.
Optimization at that level is no longer in the hands of programmers;
it now belongs to compilers, microcode and CPUs.

If you're inclined, write a timing test that compares the speed of
single-byte codes to six-byte words. Run it in high priority or on an
otherwise idle machine. Repeat the loop a few million times .. enough
to produce three stable digits of timer resolution. Run it a few
times, using the lowest, not average, speed.

I'll bet you'll find the speeds equal.

Richard

2004-10-03, 8:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>
> Ok, here are two:
>
> DELL DIMENSION 2400 INTEL PENTIUM 4 2.8GHZ, 256MB DDR RAM, 80GB HDD,
> 64MB SVGA, 52X CDRW, DVD-ROM, 10/100 NIC, 5.1CH SOUND, 2-USB, MID
> TOWER CASE 400W P/S, KEYB & MOUSE, WIN XP HOME BLACK COLOR (NEW)
>
> $ 489.00
>
> http://www.pchardware4u.com/details...=18&SKU=8016211
>
> Processor Class: Athlon XP
> Processor Speed: 2.08 GHz
> Installed Memory: 512 MB
> Hard Drive Capacity: 120 GB
> Included Drives: 3.5" 1.44 MB floppy, DVD-ROM, CD-RW
> Network Support: Ethernet, Fast Ethernet
> Modem Speed: 56 Kbps
> 1 Year Warranty from the Manufacturer
>
> $494.25
>
> http://www.pcrush.com/prodspec.asp?...7986&refid=1058

I'm waiting expectantly at the gate for your donations to turn up.

Richard

2004-10-04, 3:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> Fujitsu had the first 64-bit Cobol in 1999, for IA-64.

No. Wrong.

Fujitsu """announced today their plans to work with Intel Corporation
on the development of a COBOL compiler optimized for Intel's future
IA-64 processor family."""

In 1999 they announced a _plan_ to work on developing a compiler. As
far as I can tell it hasn't been delivered. Given the prospects for
IA-64, I doubt it ever will.

> Micro Focus compiles to 64-bit IA-64, SPARC and Power PC.

As far as I can tell the IA-64 compiler was announced for AIX on
IA-64. However, this version of AIX was never made generally
available - Monteray was cancelled.

While MF discuss HP-UX for IA-64 it specifies that it is 32 bit only
(see column heading).

> IBM Visual Age compiles to Power PC and IA-64.

Again for AIX which was never available.

> IBM mainframe Cobol compiles to 64-bit z/Architecture.

Not Intel.

> Unisys Clear Path compiles to 64-bit Wintel ES7000, also IA-64.

Can you show where there is any _released_ versions for 64 bit mode
operation.

Sponsored Links