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

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

> I don't think it would.   It already was significantly different from othe
r
> 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.[/colo
r]

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.

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

;-)

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.

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

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

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.

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]
 
>
>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

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

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 compare
d to
optimization based upon understanding data structures and communications nee
ds.


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

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