From: Tim Prince on
On 6/9/2010 10:27 PM, rfengineer55 wrote:
> By popular demand, here is one of my FCC programs that Is
> generating Gfortran errors, two to be exact.
>

As you've quoted it, there are many broken lines, which have to be fixed
by inspection, not by any magic compiler option "fix my broken source."
You haven't supplied the file amkeys.inc . Other than that, you
haven't shown anything which isn't accepted by default in ifort, however
"dodgy" some of that stuff may be.
The worst of it may be this:
character*2 escape /'1B'x/
presumably intended to mean something like
escape=char(z'1B')
which could easily have been written in a more standard way, even back then,
followed by displaying escape with a1 format, which presumably is
intended to take escape(1:1), provoking an apparent bug in gfortran
error diagnostics.

There are commented out VAX specific library calls, and comments to the
effect that some of the code had been tested at one time on a 36-bit
Honeywell.

--
Tim Prince
From: glen herrmannsfeldt on
e p chandler <epc8(a)juno.com> wrote:
(snip)

> http://www.bitsavers.org/pdf/dec/vax/lang/fortran/

That is where they should be. I write to Al some time ago that
some of the bits are missing. Specifically, the distinction between
blue and black ink. Some DEC manuals marked extensions to the
standard in blue, but that distinction is lost in the scanning.

IBM Fortran manuals mark extensions by shading (gray) over the
words describing the extension. That usually survives the scanning,
though in some cases it covers up the words.

> looks like it may have what you want. You may prefer to download from a
> mirror of this archive. Sorry I don't have a URL for one of those handy.
> Also there may be more general VMS manuals there. Sorry, I don't know the
> DEC term for the IBMism "Principles of Operation".

The "Principles of Operation" manuals describe the hardware.
There are VAX Architecture manuals that do that for VAX.

For compilers, IBM produces two manuals, usually with names
like "Language Reference" and "Programmers Guide." The Language
Reference describes the language, including extensions.
The Programmers Guide gives details on running the compiler,
and things to know about the object code, among others.

> Do you have a pointer to a site from which this source code can be
> downloaded directly from "Uncle Charlie" in electronic form?

-- glen
From: Tobias Burnus on
On 06/10/2010 08:47 AM, Tim Prince wrote:
> On 6/9/2010 10:27 PM, rfengineer55 wrote:
>> By popular demand, here is one of my FCC programs that Is
>> generating Gfortran errors, two to be exact.
>>
>
> As you've quoted it, there are many broken lines, which have to be fixed
> by inspection, not by any magic compiler option "fix my broken source."
> You haven't supplied the file amkeys.inc . Other than that, you
> haven't shown anything which isn't accepted by default in ifort, however
> "dodgy" some of that stuff may be.
> The worst of it may be this:
> character*2 escape /'1B'x/
> presumably intended to mean something like
> escape=char(z'1B')

First, gfortran supports as extension which allows to initialize
variables in the form
type variable /initialization/
However, it does not support initializing a CHARACTER variable with an
INTEGER (without )

I think Tim found the line, which causes the error you are seening. You
could try replacing
character*2 escape /'1B'x/
by
character(2) :: escape = achar(z'1B')

Tobias
From: robin on
"Richard Maine" <nospam(a)see.signature> wrote in message news:1jjue01.1hqn9cj5zesgmN%nospam(a)see.signature...

| Be aware that the forms like
|
| > integer out/6/
|
| are a nonstandard variant of a DATA statement.

Actually, it's a non-standard INTEGER statement.


From: mecej4 on
On 6/10/2010 1:47 AM, Tim Prince wrote:
> On 6/9/2010 10:27 PM, rfengineer55 wrote:
>> By popular demand, here is one of my FCC programs that Is
>> generating Gfortran errors, two to be exact.
>>
>
> As you've quoted it, there are many broken lines, which have to be fixed
> by inspection, not by any magic compiler option "fix my broken source."
> You haven't supplied the file amkeys.inc . Other than that, you haven't
> shown anything which isn't accepted by default in ifort, however "dodgy"
> some of that stuff may be.
> The worst of it may be this:
> character*2 escape /'1B'x/
> presumably intended to mean something like
> escape=char(z'1B')
> which could easily have been written in a more standard way, even back
> then,
> followed by displaying escape with a1 format, which presumably is
> intended to take escape(1:1), provoking an apparent bug in gfortran
> error diagnostics.
>
> There are commented out VAX specific library calls, and comments to the
> effect that some of the code had been tested at one time on a 36-bit
> Honeywell.
>
To add to what Tim has stated:

I fixed the wrapped lines, provided a blank AMKEYS.INC and got the code
to compile and link with two different compilers. Here are some
observations on making the code run successfully:

i) There are references to keyed-access files, which have been commented
out and replaced by I/O with formatted files. The 'database' file,
'bam:amdb.dat' has a name which may not be acceptable (because of the
DeviceName:FileName format) on some OSes. It is important that this file
be available, correctly formatted and be compatible with the source code.

ii) The program assumes that it is writing to an ANSI/VT-100 terminal.
Specifically, BELL (ASCII 7) and escape sequences are output in WRITE
statements. These will need to be fixed if you do not want to slow down
the program considerably.

iii) The program will not work unless variables are allocated statically
and initialized to zero.

HTH

-- mecej4
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Intel Fortran compiler
Next: Intel Fortran etc.