Home > Archive > Fortran > January 2006 > Worst extension ever?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Worst extension ever?
|
|
| Thomas Koenig 2006-01-18, 7:03 pm |
| What you think was the worst extension to Fortran you've ever
come across?
My personal (dis)favorite was the AT statement in a Siemens/Fujitsu
compiler, for debugging purposes. It actually implemented the
infamous "come from" statement, and it also introduced different
behavior when debugging.
Code like
10 A = I+3
20 B = I+5
DEBUG
AT 10
IF (I.LT.4) I=42
GOTO 20
END
would, when debugging was turned on, magically yank control flow
away at the statement label 10, change the value of I and then
jump back.
Urgh.
Anything worse?
| |
| glen herrmannsfeldt 2006-01-18, 7:03 pm |
| Thomas Koenig <Thomas.Koenig@online.de> wrote:
> What you think was the worst extension to Fortran you've ever
> come across?
>
> My personal (dis)favorite was the AT statement in a Siemens/Fujitsu
> compiler, for debugging purposes. It actually implemented the
> infamous "come from" statement, and it also introduced different
> behavior when debugging.
> Code like
> 10 A = I+3
> 20 B = I+5
> DEBUG
> AT 10
> IF (I.LT.4) I=42
> GOTO 20
> END
The OS/360 Fortran G compiler also implemented it, though
Fortran H didn't.
Some DEC compilers had a debugging feature where lines
starting with D were comments unless a debug option was
specified to the compiler, which allowed them to be
compiled.
The DEBUG packet method allows one to easily remove
the debug code when needed.
-- glen
| |
| Steven G. Kargl 2006-01-18, 7:03 pm |
| In article <dqm8e0$n88$1@naig.caltech.edu>,
glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> writes:
>
> Some DEC compilers had a debugging feature where lines
> starting with D were comments unless a debug option was
> specified to the compiler, which allowed them to be
> compiled.
>
gfortran supports an extension similar to the DEC D extension.
It is, of course, for legacy code.
troutmask:kargl[211] cat v.f
program v
print *, 'here'
D print *, 'there'
end
troutmask:kargl[212] gfc -o z v.f
In file v.f:3
D print *, 'there'
1
Error: Non-numeric character in statement label at (1)
troutmask:kargl[213] gfc -o z -fd-lines-as-code v.f
troutmask:kargl[214] ./z
here
there
troutmask:kargl[216] gfc -o z -fd-lines-as-comments v.f
troutmask:kargl[217] ./z
here
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Greg Lindahl 2006-01-18, 7:03 pm |
| In article <dqm8e0$n88$1@naig.caltech.edu>,
glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
>Some DEC compilers had a debugging feature where lines
>starting with D were comments unless a debug option was
>specified to the compiler, which allowed them to be
>compiled.
Glen, do you use Fortran compilers much? This extension has become
common outside of DEC.
-- greg
| |
|
|
"glen herrmannsfeldt" <gah@seniti.ugcs.caltech.edu> wrote in message
news:dqm8e0$n88$1@naig.caltech.edu...
> Thomas Koenig <Thomas.Koenig@online.de> wrote:
>
>
>
> The OS/360 Fortran G compiler also implemented it, though
> Fortran H didn't.
>
> Some DEC compilers had a debugging feature where lines
> starting with D were comments unless a debug option was
> specified to the compiler, which allowed them to be
> compiled.
>
> The DEBUG packet method allows one to easily remove
> the debug code when needed.
>
> -- glen
I never used the D construct because the VMS debugger is so much more
powerful. With it you can do every thing that the D provides plus a whole
lot more.
Jim
| |
| David Flower 2006-01-19, 4:06 am |
|
Thomas Koenig wrote:
> What you think was the worst extension to Fortran you've ever
> come across?
>
> My personal (dis)favorite was the AT statement in a Siemens/Fujitsu
> compiler, for debugging purposes. It actually implemented the
> infamous "come from" statement, and it also introduced different
> behavior when debugging.
>
> Code like
>
> 10 A = I+3
> 20 B = I+5
> DEBUG
> AT 10
> IF (I.LT.4) I=42
> GOTO 20
> END
>
> would, when debugging was turned on, magically yank control flow
> away at the statement label 10, change the value of I and then
> jump back.
>
> Urgh.
>
> Anything worse?
Does anyone remember the Univac 1108 FLD function?
It extracted specified bits from a (36bit) word, and was unusual in
that it could appear on the LHS of an assignment statement.
Quite a good idea, but the implementation left something to be desired;
the architecture of the machine meant that zero could be expressed by
all zeroes or all ones, but if a zero argument to FLD (ie specifying
start bit) was all ones, the result was chaos. Consequently, programs
were full of statements of the form:
IF ( K .EQ. 0 ) K = 0
Dave Flower
| |
| Ron Shepard 2006-01-19, 7:05 pm |
| In article <1137661896.859615.145750@g47g2000cwa.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:
> Does anyone remember the Univac 1108 FLD function?
>
> It extracted specified bits from a (36bit) word, and was unusual in
> that it could appear on the LHS of an assignment statement.
Yes, I remember that one. If FLD() was on the right of the equals
sign (or in an expression), then it extracted the bit field. If it
was on the left, then it inserted the bit field into its argument.
I forget the details now, but there were three arguments, the
integer word with the bits of interest, the field width, and the
starting bit.
However, I never really thought this was a bad extension. It is
basically like allowing a character substring expression to appear
on the left of an equals sign. I liked the later MIL-STD bit syntax
a little better, but it was fairly easy to change from one to the
other. Of course, if this had occurred in hundreds of places in my
code rather than a dozen places, I might have felt differently.
My candidate for worst extension was the cyber 205 array syntax
extension. It was not that the array syntax itself was so bad (it
was similar to f90 array syntax, in fact it was probably based on
early f8x drafts), the problem was that it worked only on vectors up
to 2^16-1 in length. If your vector happened to be longer than
that, then the operation worked only on the first 65K elements, the
remaining elements were ignored, and you got no runtime error or
warning what had happened.
$.02 -Ron Shepard
| |
| Clive Page 2006-01-26, 7:03 pm |
| In message <dqm6si$62r$1@meiner.onlinehome.de>, Thomas Koenig
<Thomas.Koenig@online.de> writes
>What you think was the worst extension to Fortran you've ever
>come across?
I would vote for the COME FROM statement - which I'm sure that someone
on this group assured me was actually implemented in a compiler -
presumably as a joke or "easter egg" as they are now called.
--
Clive Page
| |
| Richard E Maine 2006-01-26, 7:03 pm |
| Clive Page <junk@page.demon.co.uk> wrote:
> ...the COME FROM statement - which I'm sure that someone
> on this group assured me was actually implemented in a compiler -
> presumably as a joke or "easter egg" as they are now called.
Yep. In the mod 80's, when we had an Elxsi here, one of the
Fortran developers (I think it was Ralph Merkle, but it might have been
the Bob Corbett, who now posts here regularly) suggested to
me that I might be amused by perusing a certain area of the
compiler executable. Doing so, I recognized it as having a mostly
familliar list of keywords - the names of Fortran statements. It didn't
take long to notice COMEFROM in the middle of them. A quick check
revealed that it did indeed work.
I was suitably amused. I think I recall, however, that it came out of a
later version of the compiler after they got a bug report relating to
it. Not that its existance was a bug, but something along the lines of
loops done with comefrom optimizing poorly or some such thing that they
certainly didn't plan to spend time on.
I think I might also recall someone else mentioning a comefrom
implementation, but I recall the Elxsi one first hand.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Walter Spector 2006-01-27, 3:59 am |
| Another fun one:
On ancient Xerox Sigma 7 machines, if a user coded GO TO JAIL, the program
would print the obligatory "DO NOT PASS GO, DO NOT COLLECT $200".
Apparently this extension was hard coded into the compiler in such a way
as to be very difficult to find.
Walt
| |
| David Flower 2006-01-27, 3:59 am |
|
Thomas Koenig wrote:
> What you think was the worst extension to Fortran you've ever
> come across?
>
> My personal (dis)favorite was the AT statement in a Siemens/Fujitsu
> compiler, for debugging purposes. It actually implemented the
> infamous "come from" statement, and it also introduced different
> behavior when debugging.
>
> Code like
>
> 10 A = I+3
> 20 B = I+5
> DEBUG
> AT 10
> IF (I.LT.4) I=42
> GOTO 20
> END
>
> would, when debugging was turned on, magically yank control flow
> away at the statement label 10, change the value of I and then
> jump back.
>
> Urgh.
>
> Anything worse?
Who remembers ICL 1900 FORTRAN ?
This was FORTRAN 66, and its character handling was grotesque.
This was before CHARACTER variables, and the hardware had a habit ofd
renormalising floating-point variables, so, if CHARACTER data were
stored in B, the statement:
A = B
would not have the expected results. ICL provided procedures to help,
so the above statement would be replaced by:
CALL COPY8 ( A, B )
Now, it may be my personal idiosyncracy, but I expect input arguments
to proceed output arguments, l so the order of the above arguments
seems wrong - certainly I wrote them the wrong way round several times.
Needless to say, I regard CHARACTER variables as the greatest single
improvement in FORTRAN 77 compared to FORTRAN 66
Dave Flower
| |
| glen herrmannsfeldt 2006-01-27, 3:59 am |
| David Flower wrote:
(snip)
> This was before CHARACTER variables, and the hardware had a habit ofd
> renormalising floating-point variables, so, if CHARACTER data were
> stored in B, the statement:
> A = B
> would not have the expected results. ICL provided procedures to help,
> so the above statement would be replaced by:
> CALL COPY8 ( A, B )
> Now, it may be my personal idiosyncracy, but I expect input arguments
> to proceed output arguments, l so the order of the above arguments
> seems wrong - certainly I wrote them the wrong way round several times.
Many assemblers use a destination on the left format for instructions.
The C library string routines also have the destination first.
Also, it matches the order of an assignment statement.
-- glen
| |
| Arjen Markus 2006-01-27, 3:59 am |
| That seems to have been the very reason for that order. Only most
programmers do not seem to realise that (I never did, until I read
about that particular design decision). That does make you think - in
retrospect - about the usefulness of such a decision.
Regards,
Arjen
| |
| Harold Stevens 2006-01-27, 7:58 am |
| In <43D9ADF2.523B2587@earthlink.net> Walter Spector:
[Snip...]
> would print the obligatory "DO NOT PASS GO, DO NOT COLLECT $200".
That's a good one. I guess even ancient g s knew about "easter eggs" and
keeping a sense of humor in the workaday world. :)
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Kids jumping ship? Looking to hire an old-school type? Email me.
| |
| Richard E Maine 2006-01-27, 7:01 pm |
| David Flower <DavJFlower@AOL.COM> wrote:
> Who remembers ICL 1900 FORTRAN ?
>
> This was FORTRAN 66, and its character handling was grotesque.
>
> This was before CHARACTER variables, and the hardware had a habit ofd
> renormalising floating-point variables, so, if CHARACTER data were
> stored in B, the statement:
> A = B
> would not have the expected results.
I never worked with that particular system, but I do vaguely recall
similar issues on other systems. IBM 1130 perhaps? Or 1620? (But maybe
not - the recolections are too vague). Mostly I recall worrying about
whether it was best to use integer or real types for Hollerith data.
Seems to me that some systems had problems like that with real, while
other systems had different problems with integer. The details of the
problems and systems are too muddled in my memory, though I'm thinking I
recall the 1620 or 1130 being involved on one end or another.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Jim Klein 2006-01-27, 7:01 pm |
| There are no bad extensions. There are just the ones I use and the
ones I don't use.
Clive Page <junk@page.demon.co.uk> wrote:
>In message <dqm6si$62r$1@meiner.onlinehome.de>, Thomas Koenig
><Thomas.Koenig@online.de> writes
>
>I would vote for the COME FROM statement - which I'm sure that someone
>on this group assured me was actually implemented in a compiler -
>presumably as a joke or "easter egg" as they are now called.
James E. Klein
jameseklein@earthlink.net
Engineering Calculations
http://www.ecalculations.com
ecalculations@ecalculations.com
Engineering Calculations is the home of
the KDP-2 Optical Design Program
for Windows and (soon) MAC OSX
Free KDP-2 (Intro Version) downloadable!
1-818-507-5706 (Voice and Fax)
| |
| Richard E Maine 2006-01-27, 7:01 pm |
| Jim Klein <jameseklein@earthlink.net> wrote:
> There are no bad extensions. There are just the ones I use and the
> ones I don't use.
That philosophy works up to a point.
Then you find yourself having to work with someone else's code and
figure out what the heck it is doing, or perhaps what it is intended to
do, why it isn't working, and how to fix it. Then is when you start
cursing the existance of some extensions.
SOme of the ones mentioned here don't really come up in that context,
though. You don't really see comefrom used in codes that you have to
fix, for example.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| robert.corbett@sun.com 2006-01-27, 9:57 pm |
| The IMPORT statement added to Fortran 2003 is my pick for the
worst extension ever added to Fortran. The statement is far easier
to use incorrectly than correctly. The added functionality given as
the
reason for including the IMPORT statement could have been provided
with a safe construct, as was noted in the first public review.
Bob Corbett
| |
| Brooks Moses 2006-01-28, 3:57 am |
| Jim Klein wrote:
> There are no bad extensions. There are just the ones I use and the
> ones I don't use.
What about the ones you use by accident?
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Jim Klein 2006-01-28, 7:01 pm |
| nospam@see.signature (Richard E Maine) wrote:
>Jim Klein <jameseklein@earthlink.net> wrote:
>
>
>That philosophy works up to a point.
>
>Then you find yourself having to work with someone else's code and
>figure out what the heck it is doing, or perhaps what it is intended to
>do, why it isn't working, and how to fix it. Then is when you start
>cursing the existance of some extensions.
I generally reserve my curses for the programer. :-)
I had to port an old IBM fortran program to a PC in 1990. The original
programmer used the call to the console lights as flags. It only took
3 days to find a guy at TRW who had kept a copy of a an old manual. He
faxed me a copy.
That was fun.
>
>SOme of the ones mentioned here don't really come up in that context,
>though. You don't really see comefrom used in codes that you have to
>fix, for example.
There are no bad programing languages, just programmers whose brains
do not operate the way mine does.
James E. Klein
jameseklein@earthlink.net
Engineering Calculations
http://www.ecalculations.com
ecalculations@ecalculations.com
Engineering Calculations is the home of
the KDP-2 Optical Design Program
for Windows and (soon) MAC OSX
Free KDP-2 (Intro Version) downloadable!
1-818-507-5706 (Voice and Fax)
| |
| Jim Klein 2006-01-28, 7:01 pm |
| Brooks Moses <bmoses-nospam@cits1.stanford.edu> wrote:
>Jim Klein wrote:
>
>What about the ones you use by accident?
>
>- Brooks
I don't have accidents in my code, just FEATURES.
James E. Klein
jameseklein@earthlink.net
Engineering Calculations
http://www.ecalculations.com
ecalculations@ecalculations.com
Engineering Calculations is the home of
the KDP-2 Optical Design Program
for Windows and (soon) MAC OSX
Free KDP-2 (Intro Version) downloadable!
1-818-507-5706 (Voice and Fax)
|
|
|
|
|