oldie but goody

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Dann Corbit
Posts: 11518
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: oldie but goody

Post by Dann Corbit » Wed Nov 06, 2019 11:03 pm

I would be interested in trying to compile it with gfortran, g95 and the like. Some of them have flags that allow older standards.
I expect that there would be OCR bugs, but those will probably be easy to find.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

bob
Posts: 20916
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: oldie but goody

Post by bob » Thu Nov 07, 2019 5: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...

User avatar
mhull
Posts: 13079
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Sat May 30, 2020 6:05 am

bob wrote:
Thu Nov 07, 2019 5: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...
From my initial investigations of Blitz 6 (1977):

Fortran IV more or less. Indeed, the "implicit integer a-z" is a challenge since Fortran, prior to version 77, used integers (well, anything actually) to store characters and strings. One example of this is that various elements of the text array (which is used as a raw data buffer) are routinely treated as both text and integers. No worries in Fortran IV, all you have to do is indicate which interpretation to use in a FORMAT statement or just start doing math on the elements. You can increment by 1 to change the character, like moving from file a to file b (when looking at data from the book file).

Of course, Fortran 77 (i.e. gfortran -std=legacy) goes into shock (because characters are supposed to be typed as such).

Then there are the OCR glitches where some kerning is misinterpreted as a space (e.g. "in board" instead of "inboard") or an apostrophe is translated to a comma, e.g. "READ(5,key)..." which should be "READ(5 ' key)", which is synonymous with READ(5, REC=key).

And then there's the issues I don't even suspect at this juncture. :wink:

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.
Matthew Hull

Dann Corbit
Posts: 11518
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: oldie but goody

Post by Dann Corbit » Sat May 30, 2020 7: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.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
Ajedrecista
Posts: 1473
Joined: Wed Jul 13, 2011 7:04 pm
Location: Madrid, Spain.
Contact:

Re: Oldie but goody.

Post by Ajedrecista » Sat May 30, 2020 9:49 am

Hello:
mhull wrote:
Sat May 30, 2020 6: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.

User avatar
mhull
Posts: 13079
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Sat May 30, 2020 3:00 pm

Dann Corbit wrote:
Sat May 30, 2020 7: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.
Thanks for the tip. I'm definitely looking into this emulation option.
Matthew Hull

User avatar
mhull
Posts: 13079
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: Oldie but goody.

Post by mhull » Sat May 30, 2020 3:01 pm

Ajedrecista wrote:
Sat May 30, 2020 9:49 am
Hello:
mhull wrote:
Sat May 30, 2020 6: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.
That's worth a look. Thanks very much!
Matthew Hull

bob
Posts: 20916
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: oldie but goody

Post by bob » Sun May 31, 2020 2: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...

User avatar
mhull
Posts: 13079
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Sun May 31, 2020 10:59 pm

bob wrote:
Sun May 31, 2020 2: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...
Yes. If a legacy compiler (or even an f77 with legacy switches) can be found, it would make it "easy". I've been trying to find compilers among the emulated legacy hardware. It turns out that while the public domain IBM MVS 3.8 on Hercules emulator (emulates a 3033) is incredibly cool (TK4- just boots and gives you an operational system with 4 predefined TSO user IDs), none of the IBM Fortran compilers are there because IBM continues to hold the copyright on them, even the ancient F66/IV versions. Argh. You can do assembler (but with open sources assembler/linker/etc., not the IBM one). Haven't found any legacy third party s/370 compilers either.

I looked at the existing PDP and VAX emulations, but PDP-11 is a 16-bit architecture with 16-bit integers and VAX compilers with OpenVMS and Open Watcom are all f77 and later, with no f66/IV switches. Even though VAX came out before Fortran 77, I've found none of the period legacy compilers that ran on it.

However, as pointed out above, the current Intel Fortran compiler has an F66 switch which is unique. That should work in theory but it requires purchasing a license and it doesn't run on AMD chips which is all I have at home at the moment. So for me, the easy route may have to wait. :)

I'll see how far I can get in "hard mode", i.e. translate to >= f77. :shock:
Matthew Hull

User avatar
Ajedrecista
Posts: 1473
Joined: Wed Jul 13, 2011 7:04 pm
Location: Madrid, Spain.
Contact:

Re: Oldie but goody.

Post by Ajedrecista » Mon Jun 01, 2020 10:21 am

Hello:

I have found some IBM compilers, tough I do not know if they are what you are looking for:

http://www.retroarchive.org/dos/lang/index.html

ftp://ftp.oldskool.org/pub/ANORMAL%20ex ... 00list.txt

ftp://ftp.oldskool.org/pub/ANORMAL%20ex ... rs%20Pack/

Regards from Spain.

Ajedrecista.

Post Reply