Cray Blitz source (Carey)

[Dann Corbit]

Damn, this is harder than I thought. I've been fiddling around with g77 and f2c for a while, but neither worked. The f2c option seems closer to working.

Thanks for making an effort on this... Better you than me!

I had some idea how much time it'd take, which is why I told him it'd be at least a couple days before I could even try.

I will warn you though that the f2c output is _hideous_, so I wouldn't bet on the C version being any easier to get to work. I think most library calls aren't translated to C anyways, but rather handled by a library.

I've seen the kind of output f2c produces. Along with Pascal to C converters and other '-to-c' converters.

Hideous is definetly the right word.

Anyways, for f2c, it appears that there are a bunch of library functions missing, as the linker goes crazy with undefined reference errors like these:

Code: Select all

asyncio.c:(.text+0xa): undefined reference to `s_rsfe'
asyncio.c:(.text+0x1e): undefined reference to `do_fio'
asyncio.c:(.text+0x23): undefined reference to `e_rsfe'
asyncio.c:(.text+0x44): undefined reference to `s_stop

Right now I'm going to try out the Intel fortran compiler. I don't have Linux, but I hope my Linux emulation is up to the task...

Hmmm.... Odd.

I would certainly expect it to include all the library files it'd need. Maybe the current build has some Windows issues.

F2c needs the Fortran I/O libraries.
You get it here:
http://www.netlib.org/f2c/
Get file http://www.netlib.org/f2c/libf2c.zip
Don't just get the binaries because you might want to do 64 bit builds and the binaries only have 32 bit libraries.

The main issue is that the internal assumption is that integer == 64 bits. If the compiler can deal with that in a 32 bit machine, it will work. Otherwise, this will be a problem. The intel C compiler for linux is free and works just fine, and the included make file will compile cleanly...

I tried with various Fortran compilers including g77 (constant overflow)
G95 and GFortran (64 bit versions) failed, so I tried:
implicit integer(16) (a-z)
instead of
implicit integer (a-z)
but then I get function call errors.
I guess that only Intel Fortran can handle it without a lot of changes.

[swami]

Reviving the ancient Cray Blitz? Interesting, Thanks Bob. Can I expect it to be rated around 1700-2000?

We have had a lot of oldies now with added wb/uci support...Colossus, Chenard, Bugchess, NOW etc CrayBlitz is indeed good to our collection.

What a wonderful little hobby this is.

[LarsA]

I will try to get both that and my dissertation scanned. My dissertation was written using "interleaf" and before I knew it, the electronic version was unusable due to changes to interleaf over the years. Be nice to have that back in a text form as well...

There's a lot to be said for plain ASCII text.

Perhaps today's students are using HTML for their papers. There's so much communal inertia in the basic HTML text and diagram features that I expect the format to be readable a half century from now.

PDF is another format that I expect to have a long life. It's certainly taken hold in the Mac community and also with Linux users. It's the standard export format for material produced with Pages; that's the semi-pro document processor application on the Macintosh. I use it when I have to have embedded tables or images.

In earlier days, and there were many of these earlier days before mice and bitmapped displays, I used good old Emacs and nroff/troff.

When I graduated from university a couple of years ago, everything was written in .tex, and had been so for a long time. (This was in europe)

[Carey]

Realistically, it's just because it is an ancestor of CrayBlitz. Who knows, now Blitz 6.9 might be stronger than CrayBlitz because of the vector stuff running so poorly on modern processors....

It is a world apart from Cray Blitz. No null-move. Minimal search extensions. Etc. But it would be interesting to get it running as it was very "vanilla fortran" to say the least...

I was just joking that because of all the 64 bit & vector issues of CrayBlitz, it might run so poorly that its simpler ancestor might end up being better.

[Carey]

back in the early 90's, I bought a commercial fortran-to-c translator. I think made by Zortech.

I remember Zortech.

They were originally called Zorland but when they started doing business in the US, they changed their name to Zortech. Probably Borland complained.

Back when they were Zortech, they released a C games 'toolkit', like Borland did for Pascal.

It had a chess program in there that was very heavily based on Chess 4.x description & the Chess 0.5 Pascal program.

The bitboard operations were done as function calls to loops. Rather than updating & downdating the database, it'd just copy all of it.

Definetly an example of how not to write a bitboard program.

But it produced code so damned ugly, and it kept all the "fortranisms" such as array subscripts starting at 1, wasting an array element, and such, that I decided to forget the whole thing.

It is possible to write good code in a translator, and properly hide those array indxing differences. But most translaters don't bother on the asumption that you enjoy working in the original language and absolutely love running their converter program.

By then Cray had a good C compiler (probably not as good at optimizing as the Cray fortran compiler (but then again, _nobody_ has ever beaten that compiler to my knowledge) and I wanted something more portable with respect to dymamic memory allocation, multiple threads, and such...

Well.... if you ask people in here really really nicely, maybe somebody will convert CrayBlitz into C just for fun. It's not going to be me, though!

Seriously though, I wonder how far people are going to go with CrayBlitz. Is it going to just be a 'run it and see what it does' or are people going to want to actually start modifying and improving it so it runs better on regular systems.

Who knows, by the next chess championship, there might be an IntelBlitz or AMDBlitz instead of CrayBlitz.

[bob]

Damn, this is harder than I thought. I've been fiddling around with g77 and f2c for a while, but neither worked. The f2c option seems closer to working.

Thanks for making an effort on this... Better you than me!

I had some idea how much time it'd take, which is why I told him it'd be at least a couple days before I could even try.

I will warn you though that the f2c output is _hideous_, so I wouldn't bet on the C version being any easier to get to work. I think most library calls aren't translated to C anyways, but rather handled by a library.

I've seen the kind of output f2c produces. Along with Pascal to C converters and other '-to-c' converters.

Hideous is definetly the right word.

Anyways, for f2c, it appears that there are a bunch of library functions missing, as the linker goes crazy with undefined reference errors like these:

Code: Select all

asyncio.c:(.text+0xa): undefined reference to `s_rsfe'
asyncio.c:(.text+0x1e): undefined reference to `do_fio'
asyncio.c:(.text+0x23): undefined reference to `e_rsfe'
asyncio.c:(.text+0x44): undefined reference to `s_stop

Right now I'm going to try out the Intel fortran compiler. I don't have Linux, but I hope my Linux emulation is up to the task...

Hmmm.... Odd.

I would certainly expect it to include all the library files it'd need. Maybe the current build has some Windows issues.

F2c needs the Fortran I/O libraries.
You get it here:
http://www.netlib.org/f2c/
Get file http://www.netlib.org/f2c/libf2c.zip
Don't just get the binaries because you might want to do 64 bit builds and the binaries only have 32 bit libraries.

The main issue is that the internal assumption is that integer == 64 bits. If the compiler can deal with that in a 32 bit machine, it will work. Otherwise, this will be a problem. The intel C compiler for linux is free and works just fine, and the included make file will compile cleanly...

I tried with various Fortran compilers including g77 (constant overflow)
G95 and GFortran (64 bit versions) failed, so I tried:
implicit integer(16) (a-z)
instead of
implicit integer (a-z)
but then I get function call errors.
I guess that only Intel Fortran can handle it without a lot of changes.

I'll try to test it with gcc's f77 option and see if I can make it work...

BTW should that be implicit integer*8 (a-z) instead???

[bob]

Reviving the ancient Cray Blitz? Interesting, Thanks Bob. Can I expect it to be rated around 1700-2000?

We have had a lot of oldies now with added wb/uci support...Colossus, Chenard, Bugchess, NOW etc CrayBlitz is indeed good to our collection.

What a wonderful little hobby this is.

I suspect it will be significantly stronger than that. It was rated 2258 (against humans) on a real cray-1, running under 10K nodes per second. It runs at over 500K on my laptop, closer to 900K if I use nm=2

[Jim Ablett]

Cray Blitz 49h
Windows build compiled with Intel Fortran compiler (compiled without problem)

http://www.mediafire.com/?uibnxhd0qou

Jim.

[bob]

I will try to get both that and my dissertation scanned. My dissertation was written using "interleaf" and before I knew it, the electronic version was unusable due to changes to interleaf over the years. Be nice to have that back in a text form as well...

There's a lot to be said for plain ASCII text.

Perhaps today's students are using HTML for their papers. There's so much communal inertia in the basic HTML text and diagram features that I expect the format to be readable a half century from now.

PDF is another format that I expect to have a long life. It's certainly taken hold in the Mac community and also with Linux users. It's the standard export format for material produced with Pages; that's the semi-pro document processor application on the Macintosh. I use it when I have to have embedded tables or images.

In earlier days, and there were many of these earlier days before mice and bitmapped displays, I used good old Emacs and nroff/troff.

When I graduated from university a couple of years ago, everything was written in .tex, and had been so for a long time. (This was in europe)

used to be nroff/troff. Then Knuth came long with tex/latex. Both are no longer used very much nowadays since we have things like openoffice and such tat provide WYSIWYG type document preparation.

[Dann Corbit]

{snip}
I'll try to test it with gcc's f77 option and see if I can make it work...

BTW should that be implicit integer*8 (a-z) instead???

To us 'old-school' guys, the new sizing looks like array dimentions. But the new format wants do do away with integer*8 and make it integer(8). See, for instance:
http://www.soks.org/view/Fortran95ForFo ... clarations

Quite frankly, this looks *hideous* to me:

Code: Select all

Precision
F77:   real*8 dblpre
F95: real, parameter :: dp = selected_real_kind(15,307)

real(dp) :: double_precision = 3.2_dp

But my Fortran programming days were from 1976 to 1984. I have to pull out the manual to program in Fortran 90 or F95.