Home > Archive > Fortran > December 2005 > Conversion of CDC Fortran program to g77
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 |
Conversion of CDC Fortran program to g77
|
|
| notanyspam@gmail.com 2005-12-11, 10:12 pm |
| I gave a program from the late 70's that originally ran on a CDC 6600.
I've been trying to convert it so I can run it on my PC. It is ove 500
lines and had a lot of issues compiling, but I've fixed most of them
leaving only three primary issues that have me stumped. Here they are:
1) ftshade.for:1:
PROGRAM FTSHADE(INPUT,OUTPUT,DATA,TAPE5=DATA)
^
Invalid form for PROGRAM statement at (^)
ftshade.for: In program `MAIN__':
2) ftshade.for:20:
IF(NBUG.EQ.2HNO) GO TO 1000
1 2
Equality operator at (1) must operate on two subexpressions of
arithmetic or character type, but the subexpression at (2) is not of
arithmetic or character type
3) ftshade.for:21:
IDENT=14HDISH SHADOWING
^
Truncating characters on right side of hollerith constant at (^)
Any suggestions on how I should proceed are much appreciated. By the
way, I am just a beginner, so please go easy on me. Many thanks in
advance.
Bob
| |
| glen herrmannsfeldt 2005-12-11, 10:12 pm |
| notanyspam@gmail.com wrote:
> I gave a program from the late 70's that originally ran on a CDC 6600.
> I've been trying to convert it so I can run it on my PC. It is ove 500
> lines and had a lot of issues compiling, but I've fixed most of them
> leaving only three primary issues that have me stumped. Here they are:
> 1) ftshade.for:1:
> PROGRAM FTSHADE(INPUT,OUTPUT,DATA,TAPE5=DATA)
^
> Invalid form for PROGRAM statement at (^)
> ftshade.for: In program `MAIN__':
I believe this is a CDC adaptation from Pascal, but isn't
needed for standard Fortran.
> 2) ftshade.for:20:
> IF(NBUG.EQ.2HNO) GO TO 1000
> 1 2
> Equality operator at (1) must operate on two subexpressions of
> arithmetic or character type, but the subexpression at (2) is not of
> arithmetic or character type
Best is to make NBUG a CHARACTER variable of the appropriate length.
Second best, if your compiler allows READ/WRITE of INTEGER variables
with A format (as Fortran 66 does), initialize a variable in a DATA
statement to 'NO'.
> 3) ftshade.for:21:
> IDENT=14HDISH SHADOWING
> ^
> Truncating characters on right side of hollerith constant at (^)
IDENT should be a CHARACTER variable, such as CHARACTER*14 (or more).
Hopefully this will agree with the other places it is used.
-- glen
| |
| James Giles 2005-12-11, 10:12 pm |
| glen herrmannsfeldt wrote:
> notanyspam@gmail.com wrote:
>
> ^
>
> I believe this is a CDC adaptation from Pascal, but isn't
> needed for standard Fortran.
Well, most likely it associates the asterisk units with files
called INPUT and OUTPUT, and it opens a file called
DATA and associates it with I/O unit number 5. At least,
I'm pretty sure about the DATA file and unit 5 (the INPUT
and OUTPUT may be special case names for terminal
connections, I'd have to get an old CDC document to
check). Since this causes some preconnection of I/O
files, you will have to replace it with some OPEN statements.
At least one for unit 5 anyway.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Louis Krupp 2005-12-12, 4:13 am |
| notanyspam@gmail.com wrote:
> I gave a program from the late 70's that originally ran on a CDC 6600.
> I've been trying to convert it so I can run it on my PC. It is ove 500
> lines and had a lot of issues compiling, but I've fixed most of them
> leaving only three primary issues that have me stumped. Here they are:
<snip>
> 2) ftshade.for:20:
> IF(NBUG.EQ.2HNO) GO TO 1000
> 1 2
> Equality operator at (1) must operate on two subexpressions of
> arithmetic or character type, but the subexpression at (2) is not of
> arithmetic or character type
>
> 3) ftshade.for:21:
> IDENT=14HDISH SHADOWING
> ^
> Truncating characters on right side of hollerith constant at (^)
<snip>
You may already know some or all of this (and other posters have said
pretty much the same thing in different words):
2HNO is Old Fortran for 'NO'. For best results, NBUG should be
CHARACTER*2. Out of curiosity, how is it declared (if it is declared)?
14HDISH SHADOWING means 'DISH SHADOWING'. If IDENT is a character
variable, it's probably too short. If it's not a character variable,
I'd sure like to know what it is.
Keep in mind that the CDC 6600 used 60-bit words which could be treated
as having 10 6-bit characters. This *might* have something to do with
the errors you're seeing. It might also affect floating point accuracy;
on a 32-bit machine, you may have to use double precision to achieve
the same results the CDC did with single precision.
Olde Fortran didn't have character variables. I found a CDC 6600
FORTRAN manual under http://www.bitsavers.org/pdf/cdc/6x00/fortran and I
couldn't find character variables mentioned at all. Could IDENT have
been declared double precision? This is kind of a scary thing to do,
but 120 bits would have held 20 characters, more than enough for the
Hollerith string in question.
Louis
| |
| Dave Seaman 2005-12-12, 8:17 am |
| On Sun, 11 Dec 2005 19:16:00 -0800, glen herrmannsfeldt wrote:
> notanyspam@gmail.com wrote:
[color=darkred]
> ^
[color=darkred]
> I believe this is a CDC adaptation from Pascal, but isn't
> needed for standard Fortran.
It's a CDC-ism, but it predates the first Pascal compiler, which was
implemented on a CDC 6600 at ETH Zurich and may have been influenced by
the already-established CDC conventions for program header statements.
The given header means that the program will use files named INPUT,
OUTPUT, and DATA, where runtime associations could be made by invoking
the executable program with order-dependent file name arguments to be
substituted for the default names.
The "TAPE5=DATA" in the header means that the file DATA is to be
associated with Fortran unit 5. This convention arose before Fortran 77
came along and introduced the OPEN statement.
--
Dave Seaman
U.S. Court of Appeals to review three issues
concerning case of Mumia Abu-Jamal.
<http://www.mumia2000.org/>
| |
|
|
<notanyspam@gmail.com> wrote in message
news:1134353577.837244.177890@f14g2000cwb.googlegroups.com...
>I gave a program from the late 70's that originally ran on a CDC 6600.
> I've been trying to convert it so I can run it on my PC. It is ove 500
> lines and had a lot of issues compiling, but I've fixed most of them
> leaving only three primary issues that have me stumped. Here they are:
>
> 1) ftshade.for:1:
> PROGRAM FTSHADE(INPUT,OUTPUT,DATA,TAPE5=DATA)
> ^
> Invalid form for PROGRAM statement at (^)
> ftshade.for: In program `MAIN__':
This is the form of the program statement for CDC fortran. While it was
required by one or the other of the CDC operating systems, that is no longer
the case.
>
> 2) ftshade.for:20:
> IF(NBUG.EQ.2HNO) GO TO 1000
> 1 2
> Equality operator at (1) must operate on two subexpressions of
> arithmetic or character type, but the subexpression at (2) is not of
> arithmetic or character type
The Hollerith form of the character conctant is confusing g77. Replace it
with 'No', and for good measure insure that nbug is a character variable.
This statement assumes that one puts characters into an integer variable
which method became extinct with F77.
>
> 3) ftshade.for:21:
> IDENT=14HDISH SHADOWING
> ^
> Truncating characters on right side of hollerith constant at (^)
Same as above.
>
> Any suggestions on how I should proceed are much appreciated. By the
> way, I am just a beginner, so please go easy on me. Many thanks in
> advance.
>
> Bob
>
Jim
| |
|
| Thank you, Glen. I commented outthe program statement and the compiler
did not complain. Now I'm down to only 12 issues of two types. Thank
you and the others for the help!
| |
|
| Thank you, Louis. You asked about how NBUG is declared. Her'e the code:
PRINT *,'DO YOU WANT THE STANDARD INPUT'
READ 3,NBUG
IF(NBUG.EQ.2HNO) GO TO 1000
It looks to me that it is declared by the READ statement with a length
of 3. I changed the 2HNO to NO and it passed the compiler checks. Do I
need to staate it as CHARACTER*2 or is this aautomatic? And, why not
CHARACTER*3 since YES has three chars?
Following the same logic, I changed a bunch of 3HYES's to YES's and
that knocks the compile time errors to only 6!
I then tried changing IDENT=14HDISH SHADOWING to IDENT=DISH SHADOWING
and again, compile did not complain. So then I removed the other [num
chars]H designations where I had errors and now it compiles without
those errors. Interestingly, there still aare some of these character
vars like ANSI=4HHALF but no complaints. I fear runtime errors may be
really ugly if I ever get this to run! Should I get rid of the 4H type
references everywhere?
After making the above changes, I'm getting this compile time issue:
C:\WINDOWS\TEMP\ccmQcaaa.o(.text+0x1b56):ftshade.for: undefined
reference to `sqpt_'
1.43 c:\g77\bin/g77.exe ftshade.for (return code 1)
| |
| Rich Townsend 2005-12-12, 7:16 pm |
| Jim wrote:
> <notanyspam@gmail.com> wrote in message
> news:1134353577.837244.177890@f14g2000cwb.googlegroups.com...
>
>
> This is the form of the program statement for CDC fortran. While it was
> required by one or the other of the CDC operating systems, that is no longer
> the case.
>
>
> The Hollerith form of the character conctant is confusing g77. Replace it
> with 'No', and for good measure insure that nbug is a character variable.
> This statement assumes that one puts characters into an integer variable
> which method became extinct with F77.
I think you meant 'NO' here. Also, for the benefit of the OP, the quotes ''
*must* be included.
>
> Same as above.
ie, replace 14HDISH SHADOWING by 'DISH SHADOWING'
cheers,
Rich
| |
| Paul Van Delst 2005-12-12, 7:16 pm |
| Bob wrote:
> Thank you, Louis. You asked about how NBUG is declared. Her'e the code:
>
> PRINT *,'DO YOU WANT THE STANDARD INPUT'
> READ 3,NBUG
> IF(NBUG.EQ.2HNO) GO TO 1000
>
> It looks to me that it is declared by the READ statement with a length
> of 3. I changed the 2HNO to NO and it passed the compiler checks. Do I
> need to staate it as CHARACTER*2 or is this aautomatic? And, why not
> CHARACTER*3 since YES has three chars?
>
> Following the same logic, I changed a bunch of 3HYES's to YES's and
> that knocks the compile time errors to only 6!
Assuming the question is asked iteractively, with input from stdin rather than a file, how
about something like:
CHARACTER*1 Answer
.....
PRINT *, 'Do you want the standard input? [y/n] '
READ(*,'(a)') Answer
IF ( Answer .EQ. 'N' .OR. Answer .EQ. 'n' ) GOTO 1000
Using y/n requires only 1 character regardless of answer, and you don't have to worry
about whether the user response is "no", "No", "nO", or "NO"
>
> I then tried changing IDENT=14HDISH SHADOWING to IDENT=DISH SHADOWING
> and again, compile did not complain. So then I removed the other [num
> chars]H designations where I had errors and now it compiles without
> those errors. Interestingly, there still aare some of these character
> vars like ANSI=4HHALF but no complaints. I fear runtime errors may be
> really ugly if I ever get this to run! Should I get rid of the 4H type
> references everywhere?
That's hard to say without knowing more about the code (don't want to make work just for
work's sake). My personal choice would be to get rid of all the Hollerith references
(mainly because I find them terribly confusing). One solution for your examples above
would be:
CHARACTER*14 Ident
CHARACTER*4 Ansi
.....
Ident = 'DISH SHADOWING'
.....
Ansi = 'HALF'
The quote characters above are important. Otherwise the compiler may be trying to assign
the contents of a REAL variable called DISHSHADOWING to the variable IDENT.
>
> After making the above changes, I'm getting this compile time issue:
>
> C:\WINDOWS\TEMP\ccmQcaaa.o(.text+0x1b56):ftshade.for: undefined
> reference to `sqpt_'
> 1.43 c:\g77\bin/g77.exe ftshade.for (return code 1)
That looks like a link problem or, given the name of the reference, a spelling problem in
your code? Maybe the reference in your code should be "SQRT"? If not, then you need to
supply the source code (for compilation) or library (for linking) containing the SQPT
function/subroutine.
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
| |
| Dan Nagle 2005-12-12, 7:16 pm |
| Hello,
Bob wrote:
> Thank you, Louis. You asked about how NBUG is declared. Her'e the code:
>
> PRINT *,'DO YOU WANT THE STANDARD INPUT'
> READ 3,NBUG
> IF(NBUG.EQ.2HNO) GO TO 1000
>
> It looks to me that it is declared by the READ statement with a length
> of 3.
Well, no. It's defined by reading unit 3.
There's no declaration in what you posted.
> I changed the 2HNO to NO and it passed the compiler checks. Do I
> need to staate it as CHARACTER*2 or is this aautomatic? And, why not
> CHARACTER*3 since YES has three chars?
I would declare it to be character( len= 3), but YMMV.
(I.e., if YE is good enough for you ;-)
> Following the same logic, I changed a bunch of 3HYES's to YES's and
> that knocks the compile time errors to only 6!
I hope you mean 3HYES --> 'YES'
> I then tried changing IDENT=14HDISH SHADOWING to IDENT=DISH SHADOWING
> and again, compile did not complain. So then I removed the other [num
> chars]H designations where I had errors and now it compiles without
> those errors. Interestingly, there still aare some of these character
> vars like ANSI=4HHALF but no complaints. I fear runtime errors may be
> really ugly if I ever get this to run! Should I get rid of the 4H type
> references everywhere?
Yes.
> After making the above changes, I'm getting this compile time issue:
>
> C:\WINDOWS\TEMP\ccmQcaaa.o(.text+0x1b56):ftshade.for: undefined
> reference to `sqpt_'
> 1.43 c:\g77\bin/g77.exe ftshade.for (return code 1)
Sorry, I don't recognize sqpt. Are you sure it's not a typo
for sqrt ?
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Dick Hendrickson 2005-12-12, 7:16 pm |
|
Dan Nagle wrote:
> Hello,
>
> Bob wrote:
>
>
>
> Well, no. It's defined by reading unit 3.
> There's no declaration in what you posted.
>
Well no ;). It's read from the standard input file using
format 3. read(3) would read unit 3 (without a format).
Given the PROGRAM statement from the earlier
posts, that would be the INPUT file which on CDC machines
was normally staged from the card reader to a disk file.
Nowdays, it's likely to be the keyboard.
Dick Hendrickson
| |
| Walter Spector 2005-12-12, 7:16 pm |
| Dan Nagle wrote:
> Bob wrote:
>
> Well, no. It's defined by reading unit 3.
> There's no declaration in what you posted.
Actually it is doing a READ from INPUT using the FORMAT found at label 3.
Back to the PROGRAM statement. Simply 'commenting it out' misses the point.
(Why do people always 'comment out' stuff they don't understand?)
The PROGRAM statement was originally:
PROGRAM FTSHADE(INPUT,OUTPUT,DATA,TAPE5=DATA)
Since Fortran-66 had no OPEN statement, this was CDCs way to indicate which
data files would be used. INPUT and OUTPUT are the default input and output
files. (Could to/from disk in the case of a batch job, or to/from the terminal
in an interactive session.)
Unit 5 is normally connected to INPUT by default. What the above does is
connect a file called DATA to unit 5 instead. So a more modern equivalent
would be to use an OPEN statement on unit 5 with FILE='data'.
The file names could be replaced when invoking the program by substituting
the desired names on the command line. (I'll spare the details.)
Walt
| |
| Dan Nagle 2005-12-12, 7:16 pm |
| In-Reply-To: <vsinf.271432$zb5.129276@bgtnsc04-news.ops.worldnet.att.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <sxinf.14911$hB6.13253@trnddc05>
Date: Mon, 12 Dec 2005 17:35:20 GMT
NNTP-Posting-Host: 70.21.34.98
X-Complaints-To: abuse@verizon.net
X-Trace: trnddc05 1134408920 70.21.34.98 (Mon, 12 Dec 2005 12:35:20 EST)
NNTP-Posting-Date: Mon, 12 Dec 2005 12:35:20 EST
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:140694
Hello,
Dick Hendrickson wrote:
<snip a bunch>
> Well no ;). It's read from the standard input file using
> format 3. read(3) would read unit 3 (without a format).
> Given the PROGRAM statement from the earlier
> posts, that would be the INPUT file which on CDC machines
> was normally staged from the card reader to a disk file.
> Nowdays, it's likely to be the keyboard.
>
> Dick Hendrickson
Oh, yea... Why I always use () for the control list. :-(
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard E Maine 2005-12-12, 7:16 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
>
> I hope you mean 3HYES --> 'YES'
I'm guessing that he literally meant changing it to YES, without the
quotes. That would compile, but would not have the expected result. It
would be using an implicitly declared variable named YES, the value of
which is undefined. While one could plausibly turn this into the use of
a variable named YES, one would also have to define the value of that
variable. I'd guess that the OP doesn't need that level of indirection.
In any case, let me restate Dan's question in the form of affirmative
advice. The OP *DOES* need the quotes around all the strings in
question. Without the quotes, it might well compile, but will not work
as expected.
--
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
| |
| Dick Hendrickson 2005-12-12, 7:16 pm |
|
Bob wrote:
> Thank you, Louis. You asked about how NBUG is declared. Her'e the code:
>
> PRINT *,'DO YOU WANT THE STANDARD INPUT'
> READ 3,NBUG
> IF(NBUG.EQ.2HNO) GO TO 1000
>
> It looks to me that it is declared by the READ statement with a length
> of 3. I changed the 2HNO to NO and it passed the compiler checks. Do I
> need to staate it as CHARACTER*2 or is this aautomatic? And, why not
> CHARACTER*3 since YES has three chars?
Hollerith was a funny thing in Fortran 77 In fact, it
wasn't in F77 (what could be funnier?), but was described in
an appendix. F77 replaced Hollerith with character
variables, but most compilers continued to support
Hollerith. A major issue with Hollerith was that it
was word oriented. So, your NBUG was implemented as
an 8 character thingo. And, constants were implemented
with blank fill, so 2HNO is the same as 'NO '.
It's relatively easy to change this, the rules for
character comparisions all do the right thing. Declare
your character variables with whatever size you need,
for example CHARACTER(3) :: NBUG and compare them
against whatever value you need. IF (NBUG == 'NO')
will work just fine, 'NO' has 2 characters, so it will
be padded automatically during the comparision with
as many blanks as needed (1 here).
Also, changing 2HNO to NO doesn't do what you want
(unless you didn't explain it the way I read it ;))
It implicitly creates a variable named NO. This
variable won;t have any predictable value, so at
run time nothing good will happen. Ditto for YES
>
> Following the same logic, I changed a bunch of 3HYES's to YES's and
> that knocks the compile time errors to only 6!
>
> I then tried changing IDENT=14HDISH SHADOWING to IDENT=DISH SHADOWING
> and again, compile did not complain. So then I removed the other [num
Ditto, this creates a variable named DISHSHADOWING.
Remember, blanks are not significant.
Dick Hendrickson
> chars]H designations where I had errors and now it compiles without
> those errors. Interestingly, there still aare some of these character
> vars like ANSI=4HHALF but no complaints. I fear runtime errors may be
> really ugly if I ever get this to run! Should I get rid of the 4H type
> references everywhere?
>
> After making the above changes, I'm getting this compile time issue:
>
> C:\WINDOWS\TEMP\ccmQcaaa.o(.text+0x1b56):ftshade.for: undefined
> reference to `sqpt_'
> 1.43 c:\g77\bin/g77.exe ftshade.for (return code 1)
>
| |
| James Van Buskirk 2005-12-12, 7:16 pm |
| "Walter Spector" <w6ws_xthisoutx@earthlink.net> wrote in message
news:439DB478.EAB0FCAA@earthlink.net...
> Unit 5 is normally connected to INPUT by default. What the above does is
> connect a file called DATA to unit 5 instead. So a more modern equivalent
> would be to use an OPEN statement on unit 5 with FILE='data'.
Doesn't this create problems on processors where unit 5 is
preconnected to standard input? Doesn't the statement
OPEN(5,FILE='DATA')
in that case reopen standard input so that then
READ 3, JUNK
and
READ(5,3) JUNK
both read from the same device? Well, I always endeavor to
use unit numbers greater than 9 or so, in which case this
problem can't happen so that I don't know for sure whether
it's really a problem and a workaround if it is.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Richard E Maine 2005-12-12, 7:16 pm |
| James Van Buskirk <not_valid@comcast.net> wrote:
> Doesn't this create problems on processors where unit 5 is
> preconnected to standard input?
Yes.
> Doesn't the statement
> OPEN(5,FILE='DATA')
> in that case reopen standard input so that then
> READ 3, JUNK
> and
> READ(5,3) JUNK
> both read from the same device?
Hard to say. I don't off-hand recall that the standard requires that
reopening of the standard input file is necessarily allowed at all. That
probably falls under the general loophole that the user isn't allowed to
do anything that isn't supported by the device. A vendor could well
claim that reopening isn't supported on that device, in which case the
vendor could do almost anything as an extension.
Note, by the way, that the standard disallows having 2 different unit
numbers connected to the same file. A compiler might plausibly allow
this as an extension, but don't count on it as being portable.
I recommend against fiddling with the default input/output units at all
unless you have real reason to and are willing and able to port as
needed for different compilers. While it might work, it just seems to me
that it adds a bunch of complicating issues that are best avoided.
> Well, I always endeavor to use unit numbers greater than 9 or so,
Me too.
--
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
| |
|
| Thank you All! I am overwhelmed by the quantity of knowledge by the
folks here for such outdated technology. Alas, I'm also feeling like I
am only peeling back another layer of the onion with no idea how many
more layers there may be. It's a 550 line program and I've spent maybe
10 hours so far. It's at that point where I'm wishing I just dove into
the logic and rewrote it in something with which I'm familiar. I
haven't even gotten to the nasty runtime issues I'd expect. I know the
program worked fine on a CDC 6600 back in 1979, but that's a far cry
from my PC with g77.
Would anyone be interested in taking the code and converting it for me?
I'm happy to pay a small fee for the help. Know this is a program to
determine the shading caused at different sun angles on a solar
concentrator by other concentrators in a field of concentrators. More
details on request.
| |
| James Giles 2005-12-12, 7:16 pm |
| Rich Townsend wrote:
....
> I think you meant 'NO' here. Also, for the benefit of the OP, the
> quotes '' *must* be included.
To switch on the "extremely pedantic mode", the Fortran
standard agrees with the ASCII standard that the name
of the symbol ' is apostrophe. The name of another symbol,
written ", is quote. Fortran 77 required the use of apostrophes.
Fortran 90 and beyond allows either apostrophes or quotes
to delimit strings. Most F77 compilers these days allow
quotes as well.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Walter Spector 2005-12-12, 7:16 pm |
| James Van Buskirk wrote:
>
> "Walter Spector" <w6ws_xthisoutx@earthlink.net> wrote in message
> news:439DB478.EAB0FCAA@earthlink.net...
>
>
> Doesn't this create problems on processors where unit 5 is
> preconnected to standard input?
Not necessarily.
> Doesn't the statement
> OPEN(5,FILE='DATA')
> in that case reopen standard input so that then
> READ 3, JUNK
> and
> READ(5,3) JUNK
> both read from the same device?
Again not necessarily.
For example on IRIX, unit-numberless READs and WRITEs are on units 100 and 101.
So there is no conflict with opening something else on units 5 and 6. But by
default, units 5 and 6 are *also* connected to stdin and stdout.
The way to think about it is that, in the absense of an OPEN statement, unit 5
is not actually 'opened and connected' until the first READ (5...) takes place.
Since it has not been opened explicitly, it is then connected to stdin by default.
Walt
| |
| Louis Krupp 2005-12-12, 7:16 pm |
| Dick Hendrickson wrote:
<snip>
> Hollerith was a funny thing in Fortran 77 In fact, it
> wasn't in F77 (what could be funnier?), but was described in
> an appendix. F77 replaced Hollerith with character
> variables, but most compilers continued to support
> Hollerith. A major issue with Hollerith was that it
> was word oriented. So, your NBUG was implemented as
> an 8 character thingo. And, constants were implemented
> with blank fill, so 2HNO is the same as 'NO '.
<snip>
Wouldn't that have been 10 characters on the 6600? (On a Burroughs
B5500, with a 48-bit word and 6-bit characters, it would have been 8
characters.)
With any luck, this has nothing to do with the OP's code, but you never
know. If integers (or maybe even double precision variables) used to
store character data are equivalenced to other variables, things could
get weird.
Louis
| |
| James Giles 2005-12-12, 7:16 pm |
| James Van Buskirk wrote:
> "Walter Spector" <w6ws_xthisoutx@earthlink.net> wrote in message
> news:439DB478.EAB0FCAA@earthlink.net...
>
>
> Doesn't this create problems on processors where unit 5 is
> preconnected to standard input? Doesn't the statement
> OPEN(5,FILE='DATA')
> in that case reopen standard input so that then
> READ 3, JUNK
> and
> READ(5,3) JUNK
> both read from the same device? [...}
I don't think CDC used 5 as the unit corresponding to
asterisk (or the READ 3... syntax). I don't recall for
sure, but I think that default unit was 100 or more.
I no longer have a CDC Fortran manual :-(. There's
probably one on the web, but I didn't find it a year
or so back when I looked. Maybe it's time to look
agai.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard E Maine 2005-12-12, 7:16 pm |
| Bob <notanyspam@gmail.com> wrote:
> It's a 550 line program and I've spent maybe
> 10 hours so far.
If it's only 500 lines, why not just post the thing to the newsgroup
(unless it is proprietary or otherwise not postable)? I won't promise
anything, but odds of someone, perhaps even me, helping out seem good if
you could post the code and enough data for someone to be able to run a
small test and verify that it seems to give right answers.
There was a time when I thought 500 cards^h^h^h^h^hlines was a
substantial program. You can still get a rubber band around a deck that
big, but just barely. :-) That was back when I was using CDC machines.
Times have changed.
P.S. If I do look at it, I *CAN'T* charge you even a token fee. While
that might get me "free rent" for a while, I think I'll pass; I doubt
I'd like the food, much less the company. :-)
--
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
| |
| Dick Hendrickson 2005-12-12, 7:16 pm |
|
Louis Krupp wrote:
> Dick Hendrickson wrote:
> <snip>
>
>
> <snip>
>
> Wouldn't that have been 10 characters on the 6600? (On a Burroughs
> B5500, with a 48-bit word and 6-bit characters, it would have been 8
> characters.)
Yes, sorry, I had temporarily put on my old Cray programmers
hat, where it was 8 characters per word. Differences like
that were one of the many interesting Hollerith features
in portable codes.
Dick Hendrickson
>
> With any luck, this has nothing to do with the OP's code, but you never
> know. If integers (or maybe even double precision variables) used to
> store character data are equivalenced to other variables, things could
> get weird.
>
> Louis
| |
|
|
"Bob" <notanyspam@gmail.com> wrote in message
news:1134413586.908609.260390@z14g2000cwz.googlegroups.com...
> Thank you All! I am overwhelmed by the quantity of knowledge by the
> folks here for such outdated technology. Alas, I'm also feeling like I
> am only peeling back another layer of the onion with no idea how many
> more layers there may be. It's a 550 line program and I've spent maybe
> 10 hours so far. It's at that point where I'm wishing I just dove into
> the logic and rewrote it in something with which I'm familiar. I
> haven't even gotten to the nasty runtime issues I'd expect. I know the
> program worked fine on a CDC 6600 back in 1979, but that's a far cry
> from my PC with g77.
>
> Would anyone be interested in taking the code and converting it for me?
> I'm happy to pay a small fee for the help. Know this is a program to
> determine the shading caused at different sun angles on a solar
> concentrator by other concentrators in a field of concentrators. More
> details on request.
>
Many a time, the easiest way out is a complete rewrite. It might not be so
hard to fix a program of only 550 lines.
Sorry, I don't do things like that anymore.
Jim
| |
| Dave Seaman 2005-12-12, 7:16 pm |
| On Mon, 12 Dec 2005 19:02:12 GMT, James Giles wrote:
> James Van Buskirk wrote:
[color=darkred]
> I don't think CDC used 5 as the unit corresponding to
> asterisk (or the READ 3... syntax). I don't recall for
> sure, but I think that default unit was 100 or more.
> I no longer have a CDC Fortran manual :-(. There's
> probably one on the web, but I didn't find it a year
> or so back when I looked. Maybe it's time to look
> agai.
The common idiom on CDC systems was to use a program statement like
PROGRAM NAME(INPUT,OUTPUT,TAPE5=INPUT,TAPE6=OUTP
UT)
to establish your preconnections at compile time. The point is that
there was no association of INPUT with unit 5 unless you asked for it.
--
Dave Seaman
U.S. Court of Appeals to review three issues
concerning case of Mumia Abu-Jamal.
<http://www.mumia2000.org/>
| |
|
|
| Richard E Maine 2005-12-12, 7:16 pm |
| Bob <notanyspam@gmail.com> wrote:
> OK, Richard, you asked for it. here it is in all it's (ugly) glory:
>
> http://www.greenvolts.com/ftshade.for
Ok. I just put a modified version at
<ftp://ftp.dfrc.nasa.gov/incoming/ftshade.f>
If you can't get it from there, let me know and I'll post or email it.
At 18k, it isn't unreasonable for just posting directly here.
This was a real hasty job. I just got it to compile and link. I didn't
have a handy check case. I also didn't actually sit down and study the
code beyond looking at the compilation error messages. (The compiler's
warnings about variables used but not defined, or defined but not used,
were a significant help, I might add). Please note the large number of
typos that look suspiciously like scanning errors. This suggests the
possibility that there might be more of the like, which I just didn't
happen to detect.
At a quick glance, I think that single precision will probably be
enough. Statements like the
DLAT=35.054367944
DLON=106.543293056
jumped out at me right at first, but I don't think it actually needs all
that precision.
Oh, and I wasn't actually using g77 to do the diagnosis; I used NAG f90
instead. Should be ok for g77, though. I guess I do have a copy of g77
installed on this mac for a quick check... yep. Seems to compile anyway.
Summary of changes follows
Added character declarations for nbug, ident, ansi, nshape, noutans,
imo, ans
Note that ident is defined, but never referenced anyway.
Initialized noutans to 'NO'. It was used, but never defined.
(All it does is control whether some extra output is done).
Added the missing quotes from a few of your Hollerith conversions.
(You got some of them, but not all).
Did the missed Hollerith conversion for ANS.
Corrected a typo of FE8 to FEB.
Corected a typo of L1NE to LINE (was this stuff scanned?)
Corrected a typo of ID to II (There is no variable ID; II looks right).
Corrected a typo of PFREFF to PEREFF
Corrected a typo of FCOTR to ECOR
Corrected a typo of OLATP to DLATR
Corrected a typo of Z to 2 (There is no Z, but there are several
occurances of WW/2. near this WW/Z).
Corrected a typo of FLANGR to ELANGR.
Corrected a typo of FAR to EAR
Corrected a typo of FM0 to FMO
Corrected a typo of SQPT to SQRT
--
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
| |
| James Giles 2005-12-12, 7:16 pm |
| Richard E Maine wrote:
....
> Added the missing quotes from a few of your Hollerith conversions.
> (You got some of them, but not all).
[... list of changes ...]
The procedure ECBDATA needs a SAVE attribute. You
could probably identify all the variables that need to be saved,
but a SAVE statement with no variable list is probably easiest.
(I think the only one is FCOR, or is it ECOR.)
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
|
| Thank you, Richard! What a nice treat after I returned to my desk from
lunch. Diving in now.
| |
| James Van Buskirk 2005-12-12, 7:16 pm |
| "James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:UOjnf.148377$qk4.7959@bgtnsc05-news.ops.worldnet.att.net...
> I don't think CDC used 5 as the unit corresponding to
> asterisk (or the READ 3... syntax). I don't recall for
> sure, but I think that default unit was 100 or more.
> I no longer have a CDC Fortran manual :-(. There's
> probably one on the web, but I didn't find it a year
> or so back when I looked. Maybe it's time to look
> agai.
I wasn't worried so much about what CDC did, but rather
what g77 or whatever might do if an OPEN statement that
uncritically opened unit 5 were simply inserted at the
start of the program. Might the modern processor
possibly take default input from whatever file were
opened as unit 5 rather than from the card reader or
keyboard or pipe or whatever...
But looking at the program I guess I shouldn't have
been so concerned: there seems to be no READs or
WRITEs to unit 5 in any case.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
|
| Hi Richard. Yes, I did scan it as you guessed! I did find a few more
typos and some actual errors in the code, but it's running! I am now
testing, simplifying, and cleaning things up.
Thanks again!
| |
| glen herrmannsfeldt 2005-12-13, 8:14 am |
| Richard E Maine wrote:
(snip)
> I'm guessing that he literally meant changing it to YES, without the
> quotes. That would compile, but would not have the expected result. It
> would be using an implicitly declared variable named YES, the value of
> which is undefined. While one could plausibly turn this into the use of
> a variable named YES, one would also have to define the value of that
> variable. I'd guess that the OP doesn't need that level of indirection.
Yes, but the usual Fortran 66 way would be to have a variable named
YES initialized in a DATA statement to the characters YES.
If the compiler will do A format to integers it will likely also
still do that.
But CHARACTER variables and constants are a better solution.
-- glen
| |
|
| <notanyspam@gmail.com> wrote in message
news:1134353577.837244.177890@f14g2000cwb.googlegroups.com...
> I gave a program from the late 70's that originally ran on a CDC 6600.
> I've been trying to convert it so I can run it on my PC. It is ove 500
> lines and had a lot of issues compiling, but I've fixed most of them
> leaving only three primary issues that have me stumped. Here they are:
>
> 1) ftshade.for:1:
> PROGRAM FTSHADE(INPUT,OUTPUT,DATA,TAPE5=DATA)
> ^
> Invalid form for PROGRAM statement at (^)
Delete the parentheses and everything between them.
All the files referenced inthe program needed to be
listed "up front".
INPUT and OUTPUT are the standard names for card input
and line printer output.
5 is the internal name for the file called DATA.
You may need to include / modify an OPEN statement
for unit 5.
> ftshade.for: In program `MAIN__':
>
> 2) ftshade.for:20:
> IF(NBUG.EQ.2HNO) GO TO 1000
> 1 2
> Equality operator at (1) must operate on two subexpressions of
> arithmetic or character type, but the subexpression at (2) is not of
> arithmetic or character type
Better to change this to character variable and char constant.
IF (NB .EQ. 'NO') go to 1000
> 3) ftshade.for:21:
> IDENT=14HDISH SHADOWING
> ^
> Truncating characters on right side of hollerith constant at (^)
Again, conversion to character is appropriate.
Is Ident double precision?
If so, on CDC could accommodate 20 characters.
A double precision variable on PC can accommodate
only 8 characters.
Error message is saying that the string is too long.
> Any suggestions on how I should proceed are much appreciated. By the
> way, I am just a beginner, so please go easy on me. Many thanks in
> advance.
>
> Bob
| |
|
| "Bob" <notanyspam@gmail.com> wrote in message
news:1134406448.165500.151020@g47g2000cwa.googlegroups.com...
> Thank you, Louis. You asked about how NBUG is declared. Her'e the code:
>
> PRINT *,'DO YOU WANT THE STANDARD INPUT'
> READ 3,NBUG
> IF(NBUG.EQ.2HNO) GO TO 1000
>
> It looks to me that it is declared by the READ statement with a length
> of 3.
3 is a reference to a FORMAT statement elsewhere in the porogram;
it is not the length.
You can more conveniently change this to READ *, NBUG
> I changed the 2HNO to NO and it passed the compiler checks. Do I
> need to staate it as CHARACTER*2 or is this aautomatic? And, why not
> CHARACTER*3 since YES has three chars?
>
> Following the same logic, I changed a bunch of 3HYES's to YES's and
> that knocks the compile time errors to only 6!
No; it needs to be 'YES', not YES.
>
> I then tried changing IDENT=14HDISH SHADOWING to IDENT=DISH SHADOWING
> and again, compile did not complain.
No, you need apostrophes.
Your compiler is treating DISSHADOWING as a variable,
not a constant. It won;t give an error, but will likely crash at run time
or someother un[predictable behaviour.
> So then I removed the other [num
> chars]H designations where I had errors and now it compiles without
> those errors. Interestingly, there still aare some of these character
> vars like ANSI=4HHALF but no complaints. I fear runtime errors may be
> really ugly if I ever get this to run! Should I get rid of the 4H type
> references everywhere?
You need ANSI = 'HALF'
etc everywhere.
> After making the above changes, I'm getting this compile time issue:
>
> C:\WINDOWS\TEMP\ccmQcaaa.o(.text+0x1b56):ftshade.for: undefined
> reference to `sqpt_'
sqpt? should this be sqrt?
> 1.43 c:\g77\bin/g77.exe ftshade.for (return code 1)
| |
|
| How can you tell/set precision? I have the program running, but the
calculations have errors. I suspect it is a precision issue.
| |
| Louis Krupp 2005-12-14, 7:57 am |
| Bob wrote:
> How can you tell/set precision? I have the program running, but the
> calculations have errors. I suspect it is a precision issue.
By default, REAL variables are probably (depending on your machine)
32-bit IEEE floating point. The CDC 6600 had 60-bit floating point.
There are (or at least were) lots of floating point formats out there,
each with its own tradeoff between range and precision, so there's more
to it than just the bit count.
If you want more precision, you'll have to change relevant variable
declarations from REAL to DOUBLE PRECISION and constants from n.nnnEnn
to n.nnnDnn (and n.nnn to n.nnnD0). That should at least get you closer
to the results you were getting on the 6600 (if a discrepancy with the
6600 is what you mean by an error).
I'm sure others here can give you more information, but this should be a
good start.
There are other possible sources of trouble -- uninitialized variables,
for example. I'm willing to bet that Richard added "IMPLICIT NONE" to
your program, which should eliminate a lot of problems.
Louis
| |
| Richard E Maine 2005-12-14, 9:58 pm |
| Louis Krupp <lkrupp@pssw.nospam.com.invalid> wrote:
> Bob wrote:
>
> There are other possible sources of trouble -- uninitialized variables,
> for example. I'm willing to bet that Richard added "IMPLICIT NONE" to
> your program, which should eliminate a lot of problems.
I should have, but I'm embarassed to say that I didn't. :-( I just did
the bare minimum job needed to get it compiling and linking. As I
recall, the code had no type declarations at all (or maybe only one or
two), so it would all have to be done from scratch, which wouldn't be
horribly difficult for a code of that size, but would probably have
doubled the work that I did.
Before going on, I want to add the caveat that there are many potential
problems other than precision. It is certainly possible that you'll go
to all the work to change the precision and then find that it doesn't
help. Or maybe it will. I leave that to your judgement and better
understanding of your problem.
Anyway, to answer first a little in the abstract, and then in the more
specific...
Fortran 90 added significant features for specification of precision
requirements and inquiry about numeric properties including precision.
However g77 is a Fortran 77 compiler. You could use the f90 features,
but you'd have to add them to the code (not horribly difficult) and also
switch to an f90 compiler (g95 and gfortran are free ones). There are
long term benefits to this, but it probably doesn't really help your
imediate problem much.
In f77, you mostly just have to know what precision your compiler
supplies. The standard says that there have to be two precisions
available, and says how to declare them in the code, but it says nothing
about their detailed properties, leaving that to the hardware (which
varied quite a bit in f77 days). The precision achieved is different
with different compilers and the standard provides no way to inquire
about it. There are carefully crafted routines that try to deduce it,
but it is surprisingly tricky to get such routines to give the expected
results. Fortunately, we know the answers for the compilers relevant to
your problem. As Louis said, the CDC single (aka default) precision used
60-bit floating point format - details probably not interesting here.
The CDC was a bit notorious for being "sloppy" with the last few bits,
apparently on the theory that having relatively many of bits gave leeway
for such "sloppiness", and speed was a higher priority.
Most versions of g77 (and maybe all, but I'm not sure) use a 32-bit
floatting point format for single precision. If that isn't enough, you
can switch to double precision, which is a 64-bit format and should be
adequate for porting code from a 60-bit CDC.
Changing f77 code from single to double precision can be a horrible mess
in some cases. Been there. Fortunately, yours isn't a bad case. The code
is structurally simple and doesn't use the things that cause the worst
problems. The only things you need to worry about are variable type
declarations and literal constants.
Ideally, the way to do it would be to, as Louis suggested, add "implicit
none" to the top of the main program and each subroutine. ALthough
"implicit none" is not standard in f77, I think all current f77
compilers (certainly including g77) support it. It will cause the
compiler to XXXXX about every variable whose type isn't declared. Then
add declarations for all the variables, either "integer" or "double
precision", as appropriate. Or even more ideally (an oxymoron, I'm
aware), get an f90 compiler and use f90-style declarations, but that's
not necesssary.
If you are feeling lazier than that, the following hack is not
recommended. Everyone but the OP should stop reading here. And the OP
should not let anyone know I even mentioned it. :-) But it should work.
Instead of "imlpicit none", add the declaration
implicit double precision(a-h,o-z)
at the top of the main program and each subroutine. That says that
variables whose names begin with a-h and o-z are assumed to be double
precision unless declared otherwise; With no implicit statement, they
were assumed to be single precision. Note that implicit declaration is
very error-prone... as exemplified by many cases of bugs that we have
helped people find by using "implicit none". Others can start reading
again now.
In addition to variable declarations, either explicit or implicit, the
other thing you need to deal with is literal constants. *ALL* your real
constants are single precision. In some cases, it probably doesn't much
matter, because either the value doesn't need the higher precision or
because it is a value that happens to be exactly representable anyway
(for example, the real literal 2.0, which I recall running across in
your code, will be exactly repreesentable even in single precision). You
need to change a literal real constant to double precision if either of
2 things hold.
1. Obviously, you need to change it if the constant numerically needs
the extra precision.
2. There are some contexts where the precisions of two things have to
match, so if one is double precision, the other also must be. I don't
think I recall seeing any of these in your code, but I might have missed
them. Most notable is that if a procedure dummy argument is double
precision, the actual argument must also be. I don't think I recall
seeing literal reals used as actual arguments in your code, though.
To make a literal constant double precision, append a D0 (that's a
letter D, followed by a digit zero) to it. That is, change 1.23 to
1.23D0. Or, if the literal constant already has the letter E in it,
change that E to a D.
In larger codes, it can be a bit of a pain to find all the literal
constants, as it is tricky to reliably automate searching for them. For
your code, an eyeball should be able to do the job.
--
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
| |
| Thierry Boudet 2005-12-14, 9:59 pm |
| On 2005-12-12, Bob <notanyspam@gmail.com> wrote:
> OK, Richard, you asked for it. here it is in all it's (ugly) glory:
>
> http://www.greenvolts.com/ftshade.for
>
mmmm... look at it...
tth@flo:~/Essais$ LANG=C ftnchek ftshade.f
[...]
28 syntax errors detected in file ftshade.f
43 warnings issued in file ftshade.f
--
"Les calculs avec l'ordinateur, je les vérifies toujours avec la
calculatrice : des fois que le fils il m'ait foutu une vérole, tu
crois que le percepteur il me la foutrait pas, l'amende ?"
| |
|
| Thank you very much, Richard. I have been playing with the precision
issues and fixing other bugs (like replacing AMIN1 and AMAX1). Now the
program runs, but I much have made an error as the results are
incorrect. Unlike the earlier errors, it now shows values of 1 where I
would expect decimal values less than one. I baked out the precision
changes, and same thing. I must have missed something somewhere. Will
keep at it...
| |
| Dave Thompson 2005-12-18, 9:57 pm |
| On Mon, 12 Dec 2005 11:07:28 -0800, nospam@see.signature (Richard E
Maine) wrote:
<snip>
<OT>
> P.S. If I do look at it, I *CAN'T* charge you even a token fee. While
> that might get me "free rent" for a while, I think I'll pass; I doubt
> I'd like the food, much less the company. :-)
Not to mention the lack of 'net access. You'd be missed. :-}
- David.Thompson1 at worldnet.att.net
|
|
|
|
|