Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #153134 > unrolled thread

high level language idea

Back to article view | Back to alt.folklore.computers

Contents

  high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-20 17:47 -0400
    Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-21 01:09 +0000
      Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-21 14:44 -0500
        Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 13:15 -0700
    Re: high level language idea davidmylastname@acm.org (David Griffith) - 2015-10-21 01:16 +0000
      Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 14:26 -0400
        Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 12:13 -0700
          Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 15:23 -0400
    Re: high level language idea bert <bert.hutchings@btinternet.com> - 2015-10-21 03:53 -0700
      Re: high level language idea rpw3@rpw3.org (Rob Warnock) - 2015-10-21 13:47 +0000
        Re: high level language idea "gareth" <no.spam@thank.you.invalid> - 2015-10-21 14:58 +0100
          Re: high level language idea Walter Banks <walter@bytecraft.com> - 2015-10-21 10:34 -0400
          Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-21 16:43 +0000
        Re: high level language idea rpw3@rpw3.org (Rob Warnock) - 2015-10-21 14:46 +0000
      Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 14:29 -0400
        Re: high level language idea Jon Elson <jmelson@wustl.edu> - 2015-10-21 14:19 -0500
          Re: high level language idea Roberto Waltman <usenet@rwaltman.com> - 2015-10-21 15:24 -0400
            Re: high level language idea Jon Elson <jmelson@wustl.edu> - 2015-10-22 14:13 -0500
              Re: high level language idea "Osmium" <r124c4u102@comcast.net> - 2015-10-23 09:55 -0500
                Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-10-23 11:42 -0400
                  Re: high level language idea "Osmium" <r124c4u102@comcast.net> - 2015-10-23 11:48 -0500
                    Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-23 10:47 -0700
                      Re: high level language idea Jon Elson <elson@pico-systems.com> - 2015-10-24 21:24 -0500
                    Re: high level language idea Jon Elson <elson@pico-systems.com> - 2015-10-24 21:14 -0500
                      Re: high level language idea Jon Elson <elson@pico-systems.com> - 2015-10-25 11:31 -0500
                        Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-25 18:13 +0000
                  Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-23 11:20 -0700
                    Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-23 11:45 -0700
                Re: high level language idea Jon Elson <elson@pico-systems.com> - 2015-10-24 21:11 -0500
                  Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 07:40 -0700
                    Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-27 08:30 -0700
                      Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-27 09:11 -0700
                        Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 12:52 -0400
                          Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 10:22 -0700
                            Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 14:37 -0400
                            Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-27 19:55 +0000
                              Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 17:46 -0700
                                Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 01:22 +0000
                                  Re: high level language idea jmfbahciv <See.above@aol.com> - 2015-10-28 12:58 +0000
                                    Re: high level language idea "gareth" <no.spam@thank.you.invalid> - 2015-10-28 13:59 +0000
                                      Re: high level language idea jmfbahciv <See.above@aol.com> - 2015-10-29 13:55 +0000
                                        Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-29 14:28 +0000
                                        Re: high level language idea "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-10-30 05:06 +1100
                                          Re: high level language idea pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-29 19:55 +0000
                                            Re: high level language idea Lawrence Statton <lawrence@senguio.mx> - 2015-10-29 14:21 -0600
                                    Re: high level language idea pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-29 19:50 +0000
                                  Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-28 07:33 -0700
                                    Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 16:58 +0000
                                      Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-28 10:10 -0700
                                        Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 20:08 +0000
                                          Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-28 13:58 -0700
                          Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-27 15:53 -0500
                            Re: high level language idea - TTF Dan Espen <despen@verizon.net> - 2015-10-27 17:11 -0400
                              Re: high level language idea - TTF scott@slp53.sl.home (Scott Lurndal) - 2015-10-28 13:24 +0000
                              Re: high level language idea - TTF hancock4@bbs.cpcn.com - 2015-10-28 07:37 -0700
                                Re: high level language idea - TTF Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 16:58 +0000
                              Re: high level language idea - TTF Dan Espen <despen@verizon.net> - 2015-10-28 15:10 -0400
                            Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 01:22 +0000
                          Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-28 08:04 -0700
                    Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 11:34 -0400
                      Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 10:14 -0700
                        Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 14:30 -0400
                          Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-27 19:29 +0000
                            Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 16:57 -0400
                              Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-27 21:50 +0000
                                Re: high level language idea Dan Espen <despen@verizon.net> - 2015-10-27 17:58 -0400
                                Re: high level language idea Ahem A Rivet's Shot <steveo@eircom.net> - 2015-10-28 09:04 +0000
                                  Re: high level language idea "gareth" <no.spam@thank.you.invalid> - 2015-10-28 09:42 +0000
                                  Re: high level language idea Roberto Waltman <usenet@rwaltman.com> - 2015-10-28 14:55 -0400
                                    Re: high level language idea Roberto Waltman <usenet@rwaltman.com> - 2015-10-28 15:02 -0400
                                    Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-28 19:15 +0000
                                    Re: high level language idea Lawrence Statton <lawrence@senguio.mx> - 2015-10-28 13:25 -0600
                                      Re: high level language idea Michael Black <et472@ncf.ca> - 2015-10-28 17:54 -0400
                                    Re: high level language idea Ahem A Rivet's Shot <steveo@eircom.net> - 2015-10-28 19:19 +0000
                                    Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 21:09 +0000
                                Re: high level language idea scott@slp53.sl.home (Scott Lurndal) - 2015-10-28 13:36 +0000
                                Re: high level language idea Andrew Swallow <am.swallow@btinternet.com> - 2015-10-28 17:54 +0000
                                  Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-28 20:08 +0000
                                    Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-28 17:54 -0500
                                Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-11-13 16:05 -0500
                                  Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-11-13 17:20 -0500
                                  Re: high level language idea Walter Banks <walter@bytecraft.com> - 2015-11-15 08:14 -0500
                        Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-27 19:55 +0000
                          Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-27 18:00 -0700
        Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 12:21 -0700
          Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 15:25 -0400
          Re: high level language idea "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-21 17:14 -0400
            Re: high level language idea jmfbahciv <See.above@aol.com> - 2015-10-22 12:51 +0000
          Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-10-21 17:56 -0400
        Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-21 19:43 +0000
          Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 13:09 -0700
            Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-22 02:52 +0000
            Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-23 16:04 -0500
      Re: high level language idea Walter Bushell <proto@panix.com> - 2015-10-28 20:19 -0400
    Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 07:35 -0700
      Re: high level language idea Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-21 19:43 +0000
        Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 13:00 -0700
          Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-21 13:35 -0700
            Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-21 13:50 -0700
              Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-10-21 17:56 -0400
                Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-22 07:22 -0700
                  Re: high level language idea John Levine <johnl@iecc.com> - 2015-10-24 00:42 +0000
                    Re: high level language idea hancock4@bbs.cpcn.com - 2015-10-24 20:26 -0700
                    Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-25 18:36 -0500
              Re: high level language idea Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-21 15:31 -0700
              Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-11-20 17:17 -0500
          Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-11-20 17:00 -0500
            Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-11-20 22:20 +0000
              Re: high level language idea Peter Flass <peter_flass@yahoo.com> - 2015-11-21 08:35 -0500
        Re: high level language idea "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-23 16:00 -0500
          Re: high level language idea Bob Eager <news0005@eager.cx> - 2015-10-23 21:07 +0000
          Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-11-20 17:31 -0500
            Re: high level language idea Gene Wirchenko <genew@telus.net> - 2015-11-25 11:28 -0800
              Re: high level language idea Alan Bowler <atbowler@thinkage.ca> - 2015-12-22 14:00 -0500
                Re: high level language idea Gene Wirchenko <genew@telus.net> - 2015-12-22 11:43 -0800

Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]

#153210

On Wednesday, October 21, 2015 at 5:56:30 PM UTC-4, Peter Flass wrote:

> I can't speak to the specific case, but lots of times the differences were
> simply core usage vs. compile time.  I assume you know that the letter "G"
> or "H", etc. was the design point for minimum memory size of the machine
> required to run the compiler.  A  compiler for a larger-memory system might
> overlay less, keep tables in core instead of on disk, etc. for faster
> compiles. "D" compilers were used on DOS and had a lot fewer features than
> the OS compilers.


Well, before 1969 when IBM began to charge, it would seem one would use the biggest compiler that would fit.  So, if they had enough core and disk to run "H" level, they would use "H" by default.

On our DOS machine, we had "D" COBOL, it was free, but we always used "F" COBOL.  We rented it, but I think the fee was modest, just a few bucks a month.  (It couldn't have cost too much as our notoriously frugal director wouldn't have allowed it.)



> Software was "free" back then.  The only thing I remember about FORTRAN H
> was that in the 1963-4 timeframe it was so buggy the university told people
> not to use it "until further notice."

see Lynn's note.

[toc] | [prev] | [next] | [standalone]

#153287

>Well, before 1969 when IBM began to charge, it would seem one would use the biggest compiler that would
>fit.  So, if they had enough core and disk to run "H" level, they would use "H" by default.

Fortran H was much slower than G because of all of the optimization.
It was quite common to use G while debugging, then switch to H once
you were close to production.  They accepted very close to the same
dialect of Fortran.

Fortran H did take a while to debug but by the time I was using it in
1969 it was reliable enough.

[toc] | [prev] | [next] | [standalone]

#153315

On Friday, October 23, 2015 at 8:42:51 PM UTC-4, John Levine wrote:
 
> Fortran H was much slower than G because of all of the optimization.
> It was quite common to use G while debugging, then switch to H once
> you were close to production.  They accepted very close to the same
> dialect of Fortran.

Thanks for the explanation.  So, shops would have both versions, and programmers would utilize the most appropriate one for their task.

[toc] | [prev] | [next] | [standalone]

#153333

"John Levine" <johnl@iecc.com> wrote in message 
news:n0ek6a$1n3j$1@miucha.iecc.com...
> >Well, before 1969 when IBM began to charge, it would seem one would use 
> >the biggest compiler that would
>>fit.  So, if they had enough core and disk to run "H" level, they would 
>>use "H" by default.
>
> Fortran H was much slower than G because of all of the optimization.
> It was quite common to use G while debugging, then switch to H once
> you were close to production.  They accepted very close to the same
> dialect of Fortran.
>
> Fortran H did take a while to debug but by the time I was using it in
> 1969 it was reliable enough.
>

ISTM that FORTRAN H also supported a "quad precision" integer... 128 bits!

-- 

numerist at aquaporin4 dot com

[toc] | [prev] | [next] | [standalone]

#153198

hancock4@bbs.cpcn.com writes:
> Did H level cost more to lease?  Was it commonly used?
>
> (I wish I saved my college printouts, so I could look to see what they used.)

re:
http://www.garlic.com/~lynn/2015h.html#35 high level language idea

H-level cost more after IBM started charging software,
23jun1969 unbundling announce ... past posts
http://www.garlic.com/~lynn/submain.html#unbundle

H&HX did optimization ... see reference comparing extended & enhanced
optimization differences ... that reference also has some discussion
about improvement in optimization becoming as good as human assembler
coding ...

PG 13&24 has comparison of G1, H-extended, H-enhanced efficiency (not
exactly the original 360 G&H ... but gets somewhat the idea) gives
aggregate operation for plasma physics code (integer, floag, control &
others), pg24: G1: 84.125M operations, H-extended 18.575M operations,
H-enhanced 12.058M operations.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#154689

On 2015-10-21 4:50 PM, hancock4@bbs.cpcn.com wrote:
>
> Did H level cost more to lease?  Was it commonly used?

H had something of a reputation for producing incorrect code.
Sometimes these were real compiler bugs, and other times is was
because of questionable assumptions about aliasing in the code
being compiled.

The reputation lead to it being less used, and so the
real problems not being reported and fixed.

The H compiler also was just a big resource intensive program,
and so not really feasible to run on the smaller /360 models.
Even on the larger systems it might not be worth the extra
cost of the compile step.

[toc] | [prev] | [next] | [standalone]

#154688

On 2015-10-21 4:00 PM, hancock4@bbs.cpcn.com wrote:>
> I don't know about Fortran, but in college they used the WATFIV product,
> supposedly for better diagnostics.
> I don't know what Fortran a researcher would use who had serious number
> crunching to do and machine time was a consideration.

WATFOR/WATFIV were really designed for compilation speed, good
diagnostics and short execution jobs.  Not for optimal code.
Generally, at Waterloo they were run under a sub-monitor so the
the program was compiled directly to memory, and then executed.
On termination, control returned to the monitor which reloaded
the compiler and started on the next program.  All this within
what was to OS/360 a single job step bypassing all the resource
management of separate job steps (compiler, link-edit, execution).
If a program ran too long, it got kicked out and on to the next one.

   If you had a CPU intensive program, you worked out most
of the bugs with WATFOR and then did the production runs
with Fortran G or H.

The WATFOR diagnostics were better as it checked for out of bounds
subscripts, and uninitialized variables.  Execution errors
reported the exact source line.  That checking alone
was expensive.  WATFOR initialized memory to 0x80808080 and
then looked for this value on every variable access.
On rare occasions this value could arise legitimately and give
a false position.  Consequently, this checking could optionally be
turned off.

On the original 7040 WATFOR, the uninitialized
variable check was done by initializing the memory to bad parity
so the hardware would fault on a read of an unitiallized variable.

[toc] | [prev] | [next] | [standalone]

#154690

On Fri, 20 Nov 2015 17:00:42 -0500, Alan Bowler wrote:

> On 2015-10-21 4:00 PM, hancock4@bbs.cpcn.com wrote:>
>> I don't know about Fortran, but in college they used the WATFIV
>> product,
>> supposedly for better diagnostics.
>> I don't know what Fortran a researcher would use who had serious number
>> crunching to do and machine time was a consideration.
> 
> WATFOR/WATFIV were really designed for compilation speed, good
> diagnostics and short execution jobs.  Not for optimal code. Generally,
> at Waterloo they were run under a sub-monitor so the the program was
> compiled directly to memory, and then executed.
> On termination, control returned to the monitor which reloaded the
> compiler and started on the next program.  All this within what was to
> OS/360 a single job step bypassing all the resource management of
> separate job steps (compiler, link-edit, execution). If a program ran
> too long, it got kicked out and on to the next one.
> 
>    If you had a CPU intensive program, you worked out most
> of the bugs with WATFOR and then did the production runs with Fortran G
> or H.
> 
> The WATFOR diagnostics were better as it checked for out of bounds
> subscripts, and uninitialized variables.  Execution errors reported the
> exact source line.  That checking alone was expensive.  WATFOR
> initialized memory to 0x80808080 and then looked for this value on every
> variable access.
> On rare occasions this value could arise legitimately and give a false
> position.  Consequently, this checking could optionally be turned off.

EMAS (https://en.wikipedia.org/wiki/Edinburgh_Multiple_Access_System) had 
an almost identical system, called its Scientific Jobber. It was a 
separate subsystem that once again compiled short program to memorry and 
ran very fast. It had extensive checking including uninitialised 
variables and bounds checking. It supported three languages - Algol-60, 
FORTRAN-IV (and later), and IMP (the system implementation language).

I worked on the actual operating system for about 8 years, including 
porting it to XA architecture.
-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#154706

Bob Eager <news0005@eager.cx> wrote:
> On Fri, 20 Nov 2015 17:00:42 -0500, Alan Bowler wrote:
> 
>> On 2015-10-21 4:00 PM, hancock4@bbs.cpcn.com wrote:>
>>> I don't know about Fortran, but in college they used the WATFIV
>>> product,
>>> supposedly for better diagnostics.
>>> I don't know what Fortran a researcher would use who had serious number
>>> crunching to do and machine time was a consideration.
>> 
>> WATFOR/WATFIV were really designed for compilation speed, good
>> diagnostics and short execution jobs.  Not for optimal code. Generally,
>> at Waterloo they were run under a sub-monitor so the the program was
>> compiled directly to memory, and then executed.
>> On termination, control returned to the monitor which reloaded the
>> compiler and started on the next program.  All this within what was to
>> OS/360 a single job step bypassing all the resource management of
>> separate job steps (compiler, link-edit, execution). If a program ran
>> too long, it got kicked out and on to the next one.
>> 
>> If you had a CPU intensive program, you worked out most
>> of the bugs with WATFOR and then did the production runs with Fortran G
>> or H.
>> 
>> The WATFOR diagnostics were better as it checked for out of bounds
>> subscripts, and uninitialized variables.  Execution errors reported the
>> exact source line.  That checking alone was expensive.  WATFOR
>> initialized memory to 0x80808080 and then looked for this value on every
>> variable access.
>> On rare occasions this value could arise legitimately and give a false
>> position.  Consequently, this checking could optionally be turned off.
> 
> EMAS (https://en.wikipedia.org/wiki/Edinburgh_Multiple_Access_System) had 
> an almost identical system, called its Scientific Jobber. It was a 
> separate subsystem that once again compiled short program to memorry and 
> ran very fast. It had extensive checking including uninitialised 
> variables and bounds checking. It supported three languages - Algol-60, 
> FORTRAN-IV (and later), and IMP (the system implementation language).
> 
> I worked on the actual operating system for about 8 years, including 
> porting it to XA architecture.

At one point there were a lot of these types of systems: PL/C, PLUM on
UNIVAC, etc.  The advent of peecees seems to have made them obsolete.  It's
too bad, however, because in addition to speed these systems usually
provided excellent diagnostics and run-time checking that novice
programmers need.  Most PC C compilers I have seen, for example, really
stink at those things.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#153276

"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote in message 
news:n08psh01oc8@news6.newsguy.com...
> On 2015-10-21, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>
>             [snip...]                        [snip...] 
> [snip...]
>
>> In the earliest days, part of the challenge was that machine memories
>> were so small there wasn't room to have both the compiler and source
>> code in memory (a problem that plagued 1401 users who attempted COBOL
>> and FORTRAN).
>
> Strictly speaking, you didn't need room for all of both the compiler and
> the source code; the compiler would work on statements one at a time, and
> build internal tables that were much smaller than the source code.  And
> not even the entire compiler had to be held in memory - sophisticated
> overlay trees were developed so that only the portions of the compiler
> in use at the moment had to be in memory.
>

See the book _Compiler Construction for Digital Computers_ by David Gries, 
released in 1971. This book describes building a *20* pass compiler!!!  This 
allowed computers with smaller memories to run the compiler, as Charlie said 
above.


>> Later on, there was concern that a compiler wouldn't generate code that
>> was very inefficient compared to what a human could do; this was critical
>> in the days of small slow machines.
>
> Indeed.  Later, though, compilers got smarter, and this became less of
> a factor.
>

At a PPoE long ago and far away, the old-time FORTRAN programmers would put 
in a variable:

          COSX = COS(X)

...and use the variable instead of the call ... so that the following 
complicated expression containing many calls for COS(X) would *not* make 
multiple calls.  I had to convince them that the current FORTRAN compiler 
would "optimize" this common expression out anyway and only make a single 
call... and adding the extra variable was a waste of time.

-- 

numerist at aquaporin4 dot com

[toc] | [prev] | [next] | [standalone]

#153278

On Fri, 23 Oct 2015 16:00:19 -0500, Charles Richmond wrote:

> See the book _Compiler Construction for Digital Computers_ by David
> Gries, released in 1971. This book describes building a *20* pass
> compiler!!!  This allowed computers with smaller memories to run the
> compiler, as Charlie said above.

I got that book when I was learning that stuff. Still have it here!

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#154691

On 2015-10-23 5:00 PM, Charles Richmond wrote:
 >
> At a PPoE long ago and far away,
 > the old-time FORTRAN programmers would put in a variable:
>
>           COSX = COS(X)
 >
> ...and use the variable instead of the call ... so that the following
 > complicated expression containing many calls for COS(X) would
 > *not* make multiple calls.  I had to convince them that the
> current FORTRAN compiler would "optimize" this common expression
 > out anyway and only make a single call... and adding the extra variabl
 >  was a waste of time.

Since Fortran ignored blanks, some programmers would then code
     cos x = cos(x)
and then use "cos x" in the rest of the routine.  Someone published
such a program.  A complaint came in from someone who said he
would not be able to use the code because it depended on a
non-standard feature of turning
    ABS X
into
    ABS(X)

[toc] | [prev] | [next] | [standalone]

#154748

On Fri, 20 Nov 2015 17:31:26 -0500, Alan Bowler <atbowler@thinkage.ca>
wrote:

[snip]

>Since Fortran ignored blanks, some programmers would then code
>     cos x = cos(x)
>and then use "cos x" in the rest of the routine.  Someone published
>such a program.  A complaint came in from someone who said he
>would not be able to use the code because it depended on a
>non-standard feature of turning
>    ABS X
>into
>    ABS(X)

     I do not understand how the last sentence follows.  Please
explain.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#155495

On 2015-11-25 2:28 PM, Gene Wirchenko wrote:
> On Fri, 20 Nov 2015 17:31:26 -0500, Alan Bowler <atbowler@thinkage.ca>
> wrote:
>
> [snip]
>
>> Since Fortran ignored blanks, some programmers would then code
>>      cos x = cos(x)
>> and then use "cos x" in the rest of the routine.  Someone published
>> such a program.  A complaint came in from someone who said he
>> would not be able to use the code because it depended on a
>> non-standard feature of turning
>>     ABS X
>> into
>>     ABS(X)
>
>       I do not understand how the last sentence follows.  Please
> explain.

A paper was published with a Fortran program to illustrate the
algorithm.  (I think the author was Morven Gentleman.)
The program had a variable like ABSX that was assigned the value
ABS(X).  Throughout the code the variable was coded as "ABS X"
since Fortran treats "ABS X" and "ABSX" exactly the same,
and coding "ABS X" makes it more obvious that the item in
and expression is the absolute value of X, and not just some
weird variable name.

After it was published a complaint was raised from someone
who did not realize that "ABS X" was just a variable that
had been assigned ABS(X) and though that the program depended
on some non-standard compiler feature that was turning
"ABS X" in to the actual function call ABS(X).

[toc] | [prev] | [next] | [standalone]

#155498

On Tue, 22 Dec 2015 14:00:27 -0500, Alan Bowler <atbowler@thinkage.ca>
wrote:

[snip]

>After it was published a complaint was raised from someone
>who did not realize that "ABS X" was just a variable that
>had been assigned ABS(X) and though that the program depended
>on some non-standard compiler feature that was turning
>"ABS X" in to the actual function call ABS(X).

     Thank you.  I understand how FORTRAN works with spaces, but was
thinking that I was missing something.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [standalone]

Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]

Back to top | Article view | alt.folklore.computers

csiph-web