TalkChess.com

bob wrote: ↑Thu Nov 07, 2019 6:46 pm I will warn you: they are NOT easy to find. If Fortran only required type declarations for all variables, it would be pretty easy. But with the "implicit" declaration (IE implicit integer a-z) we are pretty much screwed. Each piece will have to be debugged pretty much line by line since it won't produce any errors. I think I have the book stuff (probably in the .zip I sent you). So it would be pretty complete, except for pondering. It has the code, but it doesn't use a unix or windows compatible to check to see if console input is available. Code could probably be stolen from Crafty, but it has to be converted to FORTRAN and the correct system calls would have to be figured out.

When this version was done, it was comparable in speed with chess 4.x, searching about 6 plies normally with occasional dips into 7 plies, until nearing the endgame. Be interesting to see how a basic full-width search does (this WAY before any algorithm-based forward pruning like reductions, WAY before Beal's null-move paper. IE a basic Shannon type-A search.

I believe that program hit around 1800 or so with it's USCF rating back then. Wonder how much higher it would be today. I think it was less than 1K on the xerox. Started at 2-3K on the Cray until it was cleaned up for that architecture a couple of years later.

Edit: actually I suspect that NPS would be closer to 100 in the xerox. After thinking about it. Previous version, highly selective, was 1 NPS on that hardware. This was significantly faster, but also significantly smaller (version 5 was > 100,000 lines of code, this version being under 10K. MUCH easier to work on, improve, and debug...

mhull wrote: ↑Sat May 30, 2020 8:05 am[...]

Self-evidently, the level of effort might be reduced if we could but find a Fortran IV compiler. But where?

Maybe here.
http://www.bsp-gmbh.com/turnkey/herc_mvs.html

This distribution of IBM's MVS 3.8 runs on a Hercules emulator (Cygwin or Linux). This version might have IBM's "Fortran IV G" compiler. Then all you'd need to do is fix the OCR glitches and a few other things and run the program under MVS/TSO in emulation. If not MVS, you can instead run OS/360, DOS/360 or VM/370, versions of which are available in the public domain.

Otherwise, getting the code to >= Fortran77 with required character typing, to build with gfortran, will require combing carefully through every character/integer overlap and figuring out how to deal with each of them, which means getting to know the program very, very well. That level of understanding would be the same needed to transcribe it into C. But I think Fortran is much more in the spirit of things.

'Compaq Visual Fortran' wrote:/[no]f66

Syntax:

/f66 or /nof66

The /f66 option requests that the compiler select FORTRAN-66 interpretations in cases of incompatibility (default is /nof66). Differences include the following:

· DO loops are always executed at least once (see Execution of DO Constructs)
· FORTRAN-66 EXTERNAL statement syntax and semantics are allowed (see FORTRAN-66 Interpretation of the External Statement)
· If the OPEN statement STATUS specifier is omitted, the default changes to STATUS='NEW' instead of STATUS='UNKNOWN'
· If the OPEN statement BLANK specifier is omitted, the default changes to BLANK='ZERO' instead of BLANK='NULL'

In the visual development environment, specify Enable FORTRAN-66 Semantics in the Fortran Language Compiler Option Category.

'Compaq Visual Fortran' wrote:FORTRAN-66 Interpretation of the EXTERNAL Statement

If you specify compiler option /f66, the EXTERNAL statement is interpreted in a way that was specified by the FORTRAN IV (FORTRAN-66) standard. This interpretation became incompatible with FORTRAN 77 and later revisions of the Fortran standard.

The FORTRAN-66 interpretation of the EXTERNAL statement combines the functionality of the INTRINSIC statement with that of the EXTERNAL statement.

This lets you use subprograms as arguments to other subprograms. The subprograms to be used as arguments can be either user-supplied functions or Fortran 95/90 library functions.

The FORTRAN-66 EXTERNAL statement takes the following form:

EXTERNAL [*]v [, [*]v] ...

*
Specifies that a user-supplied function is to be used instead of a Fortran 95/90 library function having the same name.

v
Is the name of a subprogram or the name of a dummy argument associated with the name of a subprogram.

Rules and Behavior

The FORTRAN-66 EXTERNAL statement declares that each name in its list is an external function name. Such a name can then be used as an actual argument to a subprogram, which then can use the corresponding dummy argument in a function reference or CALL statement.

However, when used as an argument, a complete function reference represents a value, not a subprogram name; for example, SQRT(B) in CALL SUBR(A, SQRT(B), C). It is not, therefore, defined in an EXTERNAL statement (as would be the incomplete reference SQRT).

Examples

The following example demonstrates the FORTRAN-66 EXTERNAL statement:

Code: Select all

Main Program                        Subprograms

EXTERNAL SIN, COS, *TAN, SINDEG     SUBROUTINE TRIG(X,F,Y)
   .                                Y = F(X)
   .                                RETURN
   .                                END
CALL TRIG(ANGLE, SIN, SINE)
   .
   .                                FUNCTION TAN(X)
   .                                TAN = SIN(X)/COS(X)
CALL TRIG(ANGLE, COS, COSINE)       RETURN
   .                                END
   .
   .
CALL TRIG(ANGLE, TAN, TANGNT)       FUNCTION SINDEG(X)
   .                                SINDEG = SIN(X*3.1459/180)
   .                                RETURN
   .                                END
CALL TRIG(ANGLED, SINDEG, SINE)

The CALL statements pass the name of a function to the subroutine TRIG. The function reference F(X) subsequently invokes the function in the second statement of TRIG. Depending on which CALL statement invoked TRIG, the second statement is equivalent to one of the following:

Y = SIN(X)
Y = COS(X)
Y = TAN(X)
Y = SINDEG(X)

The functions SIN and COS are examples of trigonometric functions supplied in the Fortran 95/90 library. The function TAN is also supplied in the library, but the asterisk (*) in the EXTERNAL statement specifies that the user-supplied function be used, instead of the library function. The function SINDEG is also a user-supplied function. Because no library function has the same name, no asterisk is required.

Dann Corbit wrote: ↑Sat May 30, 2020 9:43 am I used to run a fortran iv compiler on IBM 360 and 370 hardware in the late 1970s.
You will need:
// exec fortfclg
for execute fortran (f) compile, link, go
I don't remember if the F is for fortran (f)our or if it was the (F) version of the compiler.

Ajedrecista wrote: ↑Sat May 30, 2020 11:49 am Hello:

mhull wrote: ↑Sat May 30, 2020 8:05 am[...]

Self-evidently, the level of effort might be reduced if we could but find a Fortran IV compiler. But where?

Maybe here.
http://www.bsp-gmbh.com/turnkey/herc_mvs.html

This distribution of IBM's MVS 3.8 runs on a Hercules emulator (Cygwin or Linux). This version might have IBM's "Fortran IV G" compiler. Then all you'd need to do is fix the OCR glitches and a few other things and run the program under MVS/TSO in emulation. If not MVS, you can instead run OS/360, DOS/360 or VM/370, versions of which are available in the public domain.

Otherwise, getting the code to >= Fortran77 with required character typing, to build with gfortran, will require combing carefully through every character/integer overlap and figuring out how to deal with each of them, which means getting to know the program very, very well. That level of understanding would be the same needed to transcribe it into C. But I think Fortran is much more in the spirit of things.

I found an option called 'Enable FORTRAN 66 Semantics' in Intel Compiler. Take a look on page 68 of a book titled "Digital Visual Fortran Programmer's Guide":

https://books.google.es/books?id=sGpdrV ... &q&f=false

You can search it in Google, for example here:

Intel(R) Fortran Compiler Options

Here is how it looks in the help file of Compaq Visual Fortran 6.6.0 Developer Studio:

'Compaq Visual Fortran' wrote:/[no]f66

Syntax:

/f66 or /nof66

The /f66 option requests that the compiler select FORTRAN-66 interpretations in cases of incompatibility (default is /nof66). Differences include the following:

· DO loops are always executed at least once (see Execution of DO Constructs)
· FORTRAN-66 EXTERNAL statement syntax and semantics are allowed (see FORTRAN-66 Interpretation of the External Statement)
· If the OPEN statement STATUS specifier is omitted, the default changes to STATUS='NEW' instead of STATUS='UNKNOWN'
· If the OPEN statement BLANK specifier is omitted, the default changes to BLANK='ZERO' instead of BLANK='NULL'

In the visual development environment, specify Enable FORTRAN-66 Semantics in the Fortran Language Compiler Option Category.

'Compaq Visual Fortran' wrote:FORTRAN-66 Interpretation of the EXTERNAL Statement

If you specify compiler option /f66, the EXTERNAL statement is interpreted in a way that was specified by the FORTRAN IV (FORTRAN-66) standard. This interpretation became incompatible with FORTRAN 77 and later revisions of the Fortran standard.

The FORTRAN-66 interpretation of the EXTERNAL statement combines the functionality of the INTRINSIC statement with that of the EXTERNAL statement.

This lets you use subprograms as arguments to other subprograms. The subprograms to be used as arguments can be either user-supplied functions or Fortran 95/90 library functions.

The FORTRAN-66 EXTERNAL statement takes the following form:

EXTERNAL [*]v [, [*]v] ...

*
Specifies that a user-supplied function is to be used instead of a Fortran 95/90 library function having the same name.

v
Is the name of a subprogram or the name of a dummy argument associated with the name of a subprogram.

Rules and Behavior

The FORTRAN-66 EXTERNAL statement declares that each name in its list is an external function name. Such a name can then be used as an actual argument to a subprogram, which then can use the corresponding dummy argument in a function reference or CALL statement.

However, when used as an argument, a complete function reference represents a value, not a subprogram name; for example, SQRT(B) in CALL SUBR(A, SQRT(B), C). It is not, therefore, defined in an EXTERNAL statement (as would be the incomplete reference SQRT).

Examples

The following example demonstrates the FORTRAN-66 EXTERNAL statement:

Code: Select all

Main Program                        Subprograms

EXTERNAL SIN, COS, *TAN, SINDEG     SUBROUTINE TRIG(X,F,Y)
   .                                Y = F(X)
   .                                RETURN
   .                                END
CALL TRIG(ANGLE, SIN, SINE)
   .
   .                                FUNCTION TAN(X)
   .                                TAN = SIN(X)/COS(X)
CALL TRIG(ANGLE, COS, COSINE)       RETURN
   .                                END
   .
   .
CALL TRIG(ANGLE, TAN, TANGNT)       FUNCTION SINDEG(X)
   .                                SINDEG = SIN(X*3.1459/180)
   .                                RETURN
   .                                END
CALL TRIG(ANGLED, SINDEG, SINE)

The CALL statements pass the name of a function to the subroutine TRIG. The function reference F(X) subsequently invokes the function in the second statement of TRIG. Depending on which CALL statement invoked TRIG, the second statement is equivalent to one of the following:

Y = SIN(X)
Y = COS(X)
Y = TAN(X)
Y = SINDEG(X)

The functions SIN and COS are examples of trigonometric functions supplied in the Fortran 95/90 library. The function TAN is also supplied in the library, but the asterisk (*) in the EXTERNAL statement specifies that the user-supplied function be used, instead of the library function. The function SINDEG is also a user-supplied function. Because no library function has the same name, no asterisk is required.

It is not a genuine FORTRAN IV compiler itself, but could it do the trick?

Regards from Spain.

Ajedrecista.

bob wrote: ↑Sun May 31, 2020 4:31 am I actually got it to compile using f77 (part of gcc project) many years ago when (I think) the source was released. But I think that was the more current version, not the version 6 stuff...