FCC VAX VMS Fortran program AMDIST
in [Fortran]
|
Prev: Intel Fortran compiler
Next: Intel Fortran etc.
From: Tim Prince on 10 Jun 2010 02:47 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 10 Jun 2010 03:21 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 10 Jun 2010 04:39 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 10 Jun 2010 07:04 "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 10 Jun 2010 09:44
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 |