Strange FORTRAN IV to F77 conversion occurrence
Terence
getting one to work again (sort of), I decided to change all the
Hollerith text to apostrophied text ( "for the future")
.
On compiling and running with my test data I found that the screen
showed all the expected "stuff" but the output disk file written the
same way(for optional printing), at the same time, stopped writting to
disk, with no error signalled at this point in the program, although
the screen continued happily.
All previous lines were written to disk but none after the one before
this one below:-
This was the code where the problem was determined to becaused by the
mix of the apostrophy delimited text with the remaining Holerith
part.
WRITE(0,8001) SIG
WRITE(6,8001) SIG
8001 FORMAT(//,' SIGNIFICANCE LEVEL =',F7.4,
1 21H ONE-SIDED AT THE LEFT)
The problem disappeared on replacing the last line with
1 ' ONE-SIDED AT THE LEFT')
It seems something set a switch to make the output file a nul file
suddenly.
Adding this to my 'gotcha' list!
Glen Herrmannsfeldt
(snip)
> This was the code where the problem was determined to becaused by the
> mix of the apostrophy delimited text with the remaining Holerith
> part.
>
> WRITE(0,8001) SIG
> WRITE(6,8001) SIG
> 8001 FORMAT(//,' SIGNIFICANCE LEVEL =',F7.4,
> 1 21H ONE-SIDED AT THE LEFT)
>
> The problem disappeared on replacing the last line with
> 1 ' ONE-SIDED AT THE LEFT')
>
> It seems something set a switch to make the output file a nul file
> suddenly.
There are 22 characters after your 21H including the T at the end.
That would leave a T format descriptor with no column number,
which shouldn't do anything bad, but you never know.
Try it with 22H.
-- glen
e p chandler
Off by one. There are 22 characters after the H and before the ).
g95 gives the following error:
1 21H ONE-SIDED AT THE LEFT)
1
Error: Positive width required in format string at (1)
Apparently it allows a missing comma and interprets T as the start of
a TAB edit descriptor.....
-- e
George
I wouldn't miss this list if you published it.
--
George
The wisest use of American strength is to advance freedom.
George W. Bush
Tim Prince
> WRITE(0,8001) SIG
> WRITE(6,8001) SIG
> 8001 FORMAT(//,' SIGNIFICANCE LEVEL =',F7.4,
> 1 21H ONE-SIDED AT THE LEFT)
>
> The problem disappeared on replacing the last line with
> 1 ' ONE-SIDED AT THE LEFT')
>
This would not have been accepted by the brand of Fortran IV I learned on.
Nor by any compiler with strict standard checking.
Dave Seaman
Notice that ' ONE-SIDED AT THE LEFT' has 22 characters, not 21. Therefore,
21H ONE-SIDED AT THE LEFT is approximately equivalent to
' ONE-SIDED AT THE LEF'T with the final 'T' left hanging outside the
string. I don't know what this does, but it obviously isn't what you
expected.
Some compilers do not attempt to analyze FORMAT statements at compile
time but leave them to be interpreted at run time. Some runtimes do not
insist on commas to separate format items, and therefore the 'T' may be
interpreted as a tab specification with the number missing.
--
Dave Seaman
Third Circuit ignores precedent in Mumia Abu-Jamal ruling.
<http://www.indybay.org/newsitems/2008/03/29/18489281.php>
user1
Do you expect to someday make the same mistake with the same obsolete
compiler ?
Terence
leading everybody astray!
Cut and paste doesn't do it right on this posting medium, because the
font here is proportional.
It's also d ..m small font - far smaller than anything elsel that
passes my screen.
So I (carefully??) typed...
The original source does NOT have the hyphen in the phrase 'ONE-
SIDED'.
So there REALY WERE 21 characters inthe Hollerith!
And someone missed the point that the original source IS Fortran IV
and DOES compile as such. It was my incomplete change to F77 that
caused the first of (count 'em) three problems.
One (problem #1) was the reaction of the F77 compiler (actually
runtime) to the mixed text type in the format statement.
Another (problem #2) was that the original source neither opens nor
closes files (JCL control, but DOES have an endfile statement).
The AT F77 Fortran compiler runtime requires a CLOSE to flush any
unwritten bufered output.
Due to my only putting in an OPEN statement, but not a later CLOSE
file, (where the program asks the IBM console operator to continue
with another tape, or not), describes the origin of this problem.
Because I supplied an OPEN statement and opened the file as FORMATTED,
the intenal buffer is not written, in case the next line is a
continuation of the same output.
The other binary UNFORMATTED outputs were up-to-date in time.
Apparently on a control -C the flush does not occur and the file is
automatically closed, without the last "written" data present. It make
sense only when you think about it.
Hence the simultaneous screen showed all the output lines; the file
didn't.
Problem #3 is that to run on an AT, I needed to call an ASM module to
cover bit-wise logical functions not in the Fortran compiler till F90.
With DEBUG set, I got an integer overlow on calling this module. SInce
I was running with no implicit statement, all integer valiables and
constants are 4-byte. I found that by specifically declaring the name
of the ASM module, in this Fortran source as INTEGER*2, the problem
disappeared.
This one I don't understand. Its an external public identifier in the
ASM and has no "integer" qualities. The module is just linked in at
link time.
I am still studying problem #4; (all but one computation is correct).
Now why not...?
I've checked the code 6 times already against the algoritm (yes
really!).
George
For whatever I've had to do with older versions of fortrans, I've found as
many gotchas as I've had time for. Since Terence can actually get results
with these tools, I would figure that his list of "thou shalt not's" would
be very much worth the having.
--
George
We cannot let terrorists hold this nation hostile or hold our allies
hostile.
George W. Bush
Picture of the Day http://apod.nasa.gov/apod/
user1
>
> Problem #3 is that to run on an AT, I needed to call an ASM module to
> cover bit-wise logical functions not in the Fortran compiler till F90.
> With DEBUG set, I got an integer overlow on calling this module. SInce
> I was running with no implicit statement, all integer valiables and
> constants are 4-byte. I found that by specifically declaring the name
> of the ASM module, in this Fortran source as INTEGER*2, the problem
> disappeared.
>
Many F77 compilers include the MIL-STD 1753 extensions. I guess you have one
that doesn't
user1
I'm waiting for the OP to hit some sort of 64k segment limit, DGROUP overflow,
or similar with that rusty old compiler he is using ...
Gary Scott
I've personnally never seen one that didn't (or the Purdue
equivalents?). They were required if you anticipated having any
military sales.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
user1
> user1 wrote:
>
>> Terence wrote:
>>
>>>
>>> Problem #3 is that to run on an AT, I needed to call an ASM module to
>>> cover bit-wise logical functions not in the Fortran compiler till F90.
>>> With DEBUG set, I got an integer overlow on calling this module. SInce
>>> I was running with no implicit statement, all integer valiables and
>>> constants are 4-byte. I found that by specifically declaring the name
>>> of the ASM module, in this Fortran source as INTEGER*2, the problem
>>> disappeared.
>>>
>>
>> Many F77 compilers include the MIL-STD 1753 extensions. I guess you
>> have one that doesn't
>>
>>
>>
> I've personnally never seen one that didn't (or the Purdue
> equivalents?). They were required if you anticipated having any
> military sales.
>
Early versions of 16-bit Microsoft Fortran. Except maybe for version 5.1, they
were mostly toy compilers. Back in the day, I switched to Ryan-McFarland or Lahey.
Richard Maine
> user1 wrote:
> > Many F77 compilers include the MIL-STD 1753 extensions. I guess you have
> > one that doesn't
> >
> I've personnally never seen one that didn't (or the Purdue
> equivalents?). They were required if you anticipated having any
> military sales.
I've worked with quite a few that didn't support all of 1753. I don't
have a handy list, but it is substantial, not just an odd exception or
two.
I don't actually recall much in the way of details about the bit
intrinsic stuff, but on other features...
I've worked with f77 compilers that didn't have the do/endd or DOWHILE.
In fact, I've had to fix doce that used these things when I ported it to
such compilers.
It has been a while since I've seen a compiler without implicit none,
but I know I ran into that with some of the early f77 compilers. Back
then, I had developed the habit of using implicit character*1 as about
the next best thing; that often resulted in some kind of compilation
error if I forgot to declare something.
Likewise, it has been a while since I've seen one without include, but I
certainly recall seeing early ones without it... or with different
syntax variations, such as the C preprocessor form. Hmm... for that
matter... a quick check to make sure I recall the right form for the mil
std one. Odd. The standard looks a bit ambiguous to me. Maybe that's
just a 3rd-hand summary... Nope. Found an obvious scan of the actual
standard. (I've got a copy somewhere here, but it turned out to be
quicker to find one by google than by getting off my duff to go look
where I think I have it). I don't see where the std says the file name
is quoted. Perhaps that's part of the system dependency in the form of
file names. Anyway, I've seen forms without the quotes, unlike the f90
form, which has them. I've also worked on systems that didn't have
anything much like include, but where I cobled together something myself
written in Fortran. Those were mostly pre-f77, but I think some were
early f77 ones.
And then there is the reading past end-of-file stuff. I've certainly
used plenty of systems that don't support that. In fact, it seems to me
that most systems these days don't.
Now if you were talking only about the bit intrinsics, I'd say you were
on stronger ground. Perhaps that's what you meant. I was taking it as
meaning support of the whole standard instead of just bits (so to speak
:-)) and pieces of it.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Gary Scott
They're in my like new copy of version 5.0.
Gary Scott
> Gary Scott <garyl...@sbcglobal.net> wrote:
>
>
>>user1 wrote:
>
>
>>>Many F77 compilers include the MIL-STD 1753 extensions. I guess you have
>>>one that doesn't
>>>
>>
>>I've personnally never seen one that didn't (or the Purdue
>>equivalents?). They were required if you anticipated having any
>>military sales.
>
>
> I've worked with quite a few that didn't support all of 1753. I don't
> have a handy list, but it is substantial, not just an odd exception or
> two.
>
> I don't actually recall much in the way of details about the bit
> intrinsic stuff, but on other features...
>
> I've worked with f77 compilers that didn't have the do/endd or DOWHILE.
> In fact, I've had to fix doce that used these things when I ported it to
> such compilers.
That I've seen. I was annoyed because I was spoiled by all the nice
extension in Harris' compilers, a large number of which are now standard .
>
><snip>
> Likewise, it has been a while since I've seen one without include, but I
> certainly recall seeing early ones without it... or with different
> syntax variations, such as the C preprocessor form.
This one i've seen. While it may have had include, I cant recall but
think not (manual is at work), Harris Fortran used a JCL statement
called $add <fileid>
One sometimes nice, sometimes not so nice feature: when you edited the
file, if you had $add mode turned on, the editor imbedded the include
file into the edit stream at the point of the $add statement.
> Hmm... for that
> matter... a quick check to make sure I recall the right form for the mil
> std one. Odd. The standard looks a bit ambiguous to me. Maybe that's
> just a 3rd-hand summary... Nope. Found an obvious scan of the actual
> standard. (I've got a copy somewhere here, but it turned out to be
> quicker to find one by google than by getting off my duff to go look
> where I think I have it). I don't see where the std says the file name
> is quoted. Perhaps that's part of the system dependency in the form of
> file names. Anyway, I've seen forms without the quotes, unlike the f90
> form, which has them. I've also worked on systems that didn't have
> anything much like include, but where I cobled together something myself
> written in Fortran. Those were mostly pre-f77, but I think some were
> early f77 ones.
VS Fortran expects the name to be inside parentheses (INCLUDE(<fileid>))
>
> And then there is the reading past end-of-file stuff. I've certainly
> used plenty of systems that don't support that. In fact, it seems to me
> that most systems these days don't.
I mentioned earlier that Harris included an "EOT" (end of tape) to
terminate disk file areas such that you could have multiple EOFs
(multiple files) within a single disk area. It worked similarly to tape
drives. (i.e. <file1 EOF file2 EOF fileN EOF EOT>)
>
> Now if you were talking only about the bit intrinsics, I'd say you were
> on stronger ground. Perhaps that's what you meant. I was taking it as
> meaning support of the whole standard instead of just bits (so to speak
> :-)) and pieces of it.
>
I was referring mostly to the bit intrinsics because that was the nature
of the problem causing the OP to resort to ASM.
user1
> user1 wrote:
>
>> Gary Scott wrote:
>>
>>> user1 wrote:
>>>
>>>> Terence wrote:
>>>>
>>>>>
>>>>> Problem #3 is that to run on an AT, I needed to call an ASM module to
>>>>> cover bit-wise logical functions not in the Fortran compiler till F90.
>>>>> With DEBUG set, I got an integer overlow on calling this module. SInce
>>>>> I was running with no implicit statement, all integer valiables and
>>>>> constants are 4-byte. I found that by specifically declaring the name
>>>>> of the ASM module, in this Fortran source as INTEGER*2, the problem
>>>>> disappeared.
>>>>>
>>>>
>>>> Many F77 compilers include the MIL-STD 1753 extensions. I guess you
>>>> have one that doesn't
>>>>
>>>>
>>>>
>>> I've personnally never seen one that didn't (or the Purdue
>>> equivalents?). They were required if you anticipated having any
>>> military sales.
>>>
>>
>> Early versions of 16-bit Microsoft Fortran. Except maybe for version
>> 5.1, they were mostly toy compilers. Back in the day, I switched to
>> Ryan-McFarland or Lahey.
>>
> They're in my like new copy of version 5.0.
>
I doubt they were versions 3.x and earlier.
Ron Shepard
Gary Scott <garyl...@sbcglobal.net> wrote:
> > Now if you were talking only about the bit intrinsics, I'd say you were
> > on stronger ground. Perhaps that's what you meant. I was taking it as
> > meaning support of the whole standard instead of just bits (so to speak
> > :-)) and pieces of it.
> >
>
> I was referring mostly to the bit intrinsics because that was the nature
> of the problem causing the OP to resort to ASM.
There were many compilers that did not support the MIL-STD bit
intrinsics. Instead, the f2c convention was fairly common. Sun
fortran was one example, but there were many others. I can't think
of a fortran 77 compiler that did not support either one or the
other of those conventions as extensions. Before f77, there were
fortran compilers that supported other bit manipulation approaches.
One that comes to mind is the fld() and sfld() approach used by
Univac fortran -- if I remember correctly, fld() occurred on the
right hand side in expressions, and sfld() occurred on the left of
the equals sign.
$.02 -Ron Shepard
George
But imagine the stuff you'll be talking about when you're 72.
1) Having had fixed form in college.
2) Fortran without allocate.
3) PDT's stumping everyone.
4) Presidents that had less than a commodore 64's brainpower.
5) A Mars landers that proved that feet and meters are different.
6) Winning elections by pushing the Diebold button.
--
George
Our Nation must defend the sanctity of marriage.
Terence
user1 wrote:
>
> I'm waiting for the OP to hit some sort of 64k segment limit, DGROUP overflow,
> or similar with that rusty old compiler he is using ...
No, never meet that problem. Whenever I suspect it might be close, I
just put the biggest non-common matrix in a named COMMON statement.
Richard Maine mentioned a few items worth explaining.
MS 3.31 has IMPLICIT NONE, has $DEBUG, has INCLUDE,
It doesn't have DO..ENDDO or DO WHILE.
It doesn't have IAND, IOR, IEOR, INOT, ISHR etc for bit-wise work on
integer variables.
These last logic operations are the first routines in ASM I wrote as a
work-around in 1985, and one thing led to another, which was a TUI
which made the commercial work a huge success and put all the kids
through university, and more.
I never got around to any read-past-eof. I don't think I ever tried.
For the record, I have an MS 3.31 F77 compiler, a Lahey F90 compiler,
a DVF 6.6c that I use for commercial native Windows, and an Intel 9.1
compiler.
I also have MS Development studio. I tried Ryan McFarland in the late
eighties I think and I preferred the MS version (or the Burroughs semi-
identical one of June 1986, which I suspect IS the same, with a
Burroughs file system add-on).
But the result of 44 years Fortran (mainly) programming experience
is:-
I use the MS F77 V3.31 compiler wherever possible, and for commercial
work for the vast speed at which I get a program designed and running
and out there, for DOS and Windows DOS-emulation environments. If I
switch I will go open-source.
And I DO know how to program F90, where I STILL use fixed format for
readability of flow and of course identical source code for both
compilers.
And same call-names and parameters for F77 and F90 text user
interfaces.
I can't recall a "gotcha" in this F77 compiler except running out of
label space (I had two cases) and that one text parsing suspected bug
(and that would be the first if true). And I may be wrong about the
effect of that one, even though DEBUG didn't find anything else and
something happened right around there and went away after changing the
source.
I always use IMPLICIT INTEGER*2 (I-N) in spite of Robin's wise
suggestion to use IMPLICIT NONE (which requires far far more typing of
variable names and intentions and interfaces) On my normal screen (not
this forum font), typos in variable names are extremely rare.
Then I define INTEGER*4 variables for accounting in cents and
statistics of demographic counts and all direct file record indices..
I define REAL*8 variables whenever I am working with matrices,
otherwise REAL*4 is then implied.
I use only FORMATTED SEQUENTIAL, BINARY SEQUENTIAL and UNFORMATTED
DIRECT files, never UNFORMATTED SEQUENTIAL, which I think was a 1956
design mistake.
I do use IF..THEN..ELSE which the compiler has but I didn't find out
for some 10 years; it gets rid of a lot of labels.
I use EQUIVALENCE only to get a CHARACTER*1 out of an INTEGER*2 in
text parsing work, since this F77 is limited character strings of 127
unless defined in IMPLICIT as 256.
I use SYSTEM calls for finding files and size estimates and calling
batch files, external sorting facilities and running batches.
I use SPAWN calls for daughter menu-selected programs.
I use a TUI for mouse, keyboard and screen work which is an enormous
help in user interfacing, allowing some 48 Function keys for services,
arrow keys for navigation, mouse/or keystroke pick-up, key testing/
waiting. Several programs can act as Word simulations and write
compatable RTF files.
I break up big programs with lots of labels (e.g. above 3000 lines)
into groups of subroutines, then the copiler is used on the part being
worked on.
Compiling speed is way under 1/10 sec; it just look instantaneaous.
Equally PAS2 and LINK
I use a compare program to check current versus previous versions of
source code which lets me select blocks of code, delete, insert and so
on, for my vast prototyping of source. Another "oldie" is my Wordstar
editor which allows direct typing in any roman-alphabet european or
language, but only lower-case simple greek. This is vastly useful
because it has column editing and moving facilities and find-and
replace with some 230 posible characters.
Now my younger 34-year old son has just picked up a working Commodore
64 on Ebay.....
I gave each of them one at 14 years, way back; second-best investment
I ever made. Now both are top animation experts.
Terence
George wrote:
> But imagine the stuff you'll be talking about when you're 72.
Er.. 75? Was flying planes in 1946, courtesy of UK AIr League.
user1
> user1 wrote:
>> I'm waiting for the OP to hit some sort of 64k segment limit, DGROUP overflow,
>> or similar with that rusty old compiler he is using ...
>
> No, never meet that problem. Whenever I suspect it might be close, I
> just put the biggest non-common matrix in a named COMMON statement.
>
Yes, I remember that trick now that you mention it. Each named common block gets
its own segment, outside of DGROUP.
OK - I dug up an old MS Fortran 3.3. It does indeed compile code amazingly
quickly on modern hardware. But I am so far unable to verify the original
problem, with quoted text and Hollerith in the same format statement.
Richard Maine
> But I am so far unable to verify the original
> problem, with quoted text and Hollerith in the same format statement.
I'm not about to try to dig out the particular compiler in question to
check whether or not I can duplicate the bug. But note that, if
accurately reported, that would be a bug, pure and simple. The practice
in question is perfectly standard Fortran 77. It doesn't even require
the Hollerith Appendix, as this isn't actually Hollerith. It is instead
an H edit descriptor. Admitedly, it sure looks a lot like a Hollerith,
complete with the otherwise inscrutable letter H, but it is not part of
the Hollerith feature that was relegated to the Appendix. Any compiler
that fails to compile it correctly just plain has a bug. It isn't a
property of Fortran 77 in general; it might possibly be a bug in the one
compiler mentioned.
Terence
Richard Maine wrote:
> ... But note that, if
> accurately reported, that would be a bug, pure and simple. The practice
> in question is perfectly standard Fortran 77. It doesn't even require
> the Hollerith Appendix, as this isn't actually Hollerith. It is instead
> an H edit descriptor. Admitedly, it sure looks a lot like a Hollerith,
> complete with the otherwise inscrutable letter H, but it is not part of
> the Hollerith feature that was relegated to the Appendix. Any compiler
> that fails to compile it correctly just plain has a bug. It isn't a
> property of Fortran 77 in general; it might possibly be a bug in the one
> compiler mentioned.
I put back the text example and it doesn't fail anymore, so I'm gong
to have to assume the bug was the bit kind, i.e. a weird space or non-
printing non-visible character like hex #a0 which doesn't show on the
screen but kills things (well, compilers).
Too easy to blame the faithful compiler, even if one thinks one has
tried all other possibilities.
I should have run a binary display on the original before I changed it
forever.
There are several others ways to get this, using Wordstar in document
mode by mistake, (which adds the top bit onto start and stop
characters of each changed word, but shows it on screen WITHOUT the
high orde bit).
Copying source out of a "passed-through-Windows Word" or similar
editor can do that, too.
I put my old Fortran IV and other "stuff" off tape onto floppies then
dikettes and finally CD-roms, so a bit might have crept in.
I know I lost my BMD Fortran source stored on an unreadable 800 bpi
tape from the '70s.
I extracted fragments, but not enough. Which brings me full circle to
why I am converting/re-writing an interesting Fortran IV tool.
George
You're our senior member, Terence. I won't let you forget it, ...
unless you do.
--
George
Some folks look at me and see a certain swagger, which in Texas is called
"walking."
Gib Bogle
>
> Richard Maine wrote:
>
>> ... But note that, if
>> accurately reported, that would be a bug, pure and simple. The practice
>> in question is perfectly standard Fortran 77. It doesn't even require
>> the Hollerith Appendix, as this isn't actually Hollerith. It is instead
>> an H edit descriptor. Admitedly, it sure looks a lot like a Hollerith,
>> complete with the otherwise inscrutable letter H, but it is not part of
>> the Hollerith feature that was relegated to the Appendix. Any compiler
>> that fails to compile it correctly just plain has a bug. It isn't a
>> property of Fortran 77 in general; it might possibly be a bug in the one
>> compiler mentioned.
>
> I put back the text example and it doesn't fail anymore, so I'm gong
> to have to assume the bug was the bit kind, i.e. a weird space or non-
> printing non-visible character like hex #a0 which doesn't show on the
> screen but kills things (well, compilers).
> Too easy to blame the faithful compiler, even if one thinks one has
> tried all other possibilities.
> I should have run a binary display on the original before I changed it
> forever.
>
> There are several others ways to get this, using Wordstar in document
> mode by mistake, (which adds the top bit onto start and stop
> characters of each changed word, but shows it on screen WITHOUT the
> high orde bit).
Wordstar! That takes me back.
user1
C:\temp>type test1.for
c
do 10 i=1,10
write(7,8000)
10 continue
8000 format('MS Fortran ',8HForever.)
end
C:\temp>for1 test1.for;
Microsoft FORTRAN77 V3.31 August 1985
(C) Copyright Microsoft Corp 1982, 1983, 1984, 1985
Pass One No Errors Detected
9 Source Lines
C:\temp>pas2
Code Area Size = #005A ( 90)
Cons Area Size = #000C ( 12)
Data Area Size = #002F ( 47)
Pass Two No Errors Detected.
C:\temp>link test1;
Microsoft (R) 8086 Object Linker Version 3.04
Copyright (C) Microsoft Corp 1983, 1984, 1985. All rights reserved.
C:\temp>test1 file7
C:\temp>type file7
MS Fortran Forever.
MS Fortran Forever.
MS Fortran Forever.
MS Fortran Forever.
MS Fortran Forever.
MS Fortran Forever.
MS Fortran Forever.
MS Fortran Forever.
MS Fortran Forever.
MS Fortran Forever.
C:\temp>
Walter Spector
> ...
> MS 3.31 has IMPLICIT NONE, has $DEBUG, has INCLUDE,
So I still have a 1985 copy of MS 2.1 F77 for the 68k Macintosh.
(Still have my old Mac Plus too - but it has not been powered up
in years.) Dragging out the manual...
> It doesn't have DO..ENDDO or DO WHILE.
The 2.1 compiler has both. It also has (unlabeled) EXIT and CYCLE.
And it has the F90 SELECT CASE.
> It doesn't have IAND, IOR, IEOR, INOT, ISHR etc for bit-wise work on
> integer variables.
The 2.1 compiler does not have them either. However it was extended
allow the operators .AND., .OR., .NOT., .EQV. and .NEQV. (xor) to
perform bitwise operations when given integer arguments. It also has
a SHIFT intrinsic.
If I were forced to use this compiler nowadays for bit operations,
I would write a set of statement functions that implement the F90
bit intrinsics, to the extent possible. (MVBITS would be a problem.)
This would be both easier and faster to write, and likely faster in
execution time than calling an external routine - whether it was
written in asm or not.
Was the MS compiler for x86 really that much worse than the one
for the Mac?
W.
Glen Herrmannsfeldt
(snip)
> Another (problem #2) was that the original source neither opens nor
> closes files (JCL control, but DOES have an endfile statement).
OPEN was added with F77. For compatibility with F66 code,
it should be able to work without OPEN.
> The AT F77 Fortran compiler runtime requires a CLOSE to flush any
> unwritten bufered output.
It shouldn't be needed with normal termination, again for
compatibility with Fortran 66, but also for convenience.
C will close files at normal termination, Java won't.
> Due to my only putting in an OPEN statement, but not a later CLOSE
> file, (where the program asks the IBM console operator to continue
> with another tape, or not), describes the origin of this problem.
> Because I supplied an OPEN statement and opened the file as FORMATTED,
> the intenal buffer is not written, in case the next line is a
> continuation of the same output.
That would be true for non-advancing I/O, much more recent
than Fortran 77. It may be that the buffer isn't full, though.
> The other binary UNFORMATTED outputs were up-to-date in time.
> Apparently on a control -C the flush does not occur and the file is
> automatically closed, without the last "written" data present. It make
> sense only when you think about it.
> Hence the simultaneous screen showed all the output lines; the file
> didn't.
Some systems don't give the program a chance on control-C.
I believe VMS allows the program to take control with control-C,
but not with control-Y. For unix, the signal mechanism allows
interception of control-C. I don't know if any I/O libraries
use that to flush I/O buffers.
-- glen
-- glen
Gary Scott
VOS did allow the application to intercept control-\ which was the
control-c equivalent.
>
> -- glen
>
> -- glen
user1
>
> Was the MS compiler for x86 really that much worse than the one
> for the Mac?
>
> W.
Worse? Perhaps. Or perhaps just different.
I had always thought that The MS Fortran compiler for mid 80's Macs was a
repackaged Absoft product.
robin
news:d86c9459-500c-493e...@o4g2000pra.googlegroups.com...
> I was re-writing/converting some old statistics routines, which after
> getting one to work again (sort of), I decided to change all the
> Hollerith text to apostrophied text ( "for the future")
> .
> On compiling and running with my test data I found that the screen
> showed all the expected "stuff" but the output disk file written the
> same way(for optional printing), at the same time, stopped writting to
> disk, with no error signalled at this point in the program, although
> the screen continued happily.
> All previous lines were written to disk but none after the one before
> this one below:-
On converting a program of that vintage, the first thing that
you need to do is to compile with all checks on
+ IMPLICIT NONE
Or even get a modern compiler for the task.
robin
>
> I use the MS F77 V3.31 compiler wherever possible, and for commercial
> work for the vast speed at which I get a program designed and running
Using an F90 compiler or later gets a program running in one-third
to one-tenth of the time compared to Fortran IV.
How much time did you waste with this and the similar problem
that you had two weeks ago? [Curious "bug" in F77]
Walter Spector
> Walter Spector wrote:
>> Was the MS compiler for x86 really that much worse than the one
>> for the Mac?
Gosh - just about every Fortran compiler since The Beginning was
extended with some form of bit masking and shifting functionality.
For starters, one needed them for dealing with Hollerith constant
based code.
I would think that the MS x86 compiler had similar extensions to
the Mac compiler. That is, allowing the logical operators to work
on integers in a 'boolean' fashion. It was a very common extension.
Of course one might have to RTFM to find out about it. (And other
things like the availability of IF..THEN..ELSE..ENDIF... :-)
> I had always thought that The MS Fortran compiler for mid 80's Macs was
> a repackaged Absoft product.
It was. Even says so in some fine print on the copyright page.
W.