Sign in with
Sign up | Sign in
Your question

Update for Byte Chess 0.5

Last response: in Video Games
Share
Anonymous
June 12, 2005 4:45:43 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I've made some additions to the short text file that goes with Byte Chess
0.5, plus a 'diff' list of changes from the version I originally
distributed.

Some of the changes may already be in the copy you have. In fact, it's
extremely likely the important ones already are. The rest are just
corrections to some comments.

Byte Chess 0.5 in Pascal, from 1978 can be downloaded from here:

http://www.moorecad.com/standardpascal/misc.html

Again, I do realize that not everybody cares about a chess program from
1978, but it is a classic, so I feel it's worth posting about.

****Begin file ByteChess05.txt
Chess 0.5, Release 3 - 2005-05-30

*********************************************************************************
If you find errors, please report them to the rec.games.chess.computer
newsgroup.
Please use a subject with "Byte Chess 0.5" in it to make it easily searched.
*********************************************************************************



Notes about Chess 0.5
*********************

This is a classic chess program written by Peter Frey and Larry Atkin in
1978. Larry Atkin was the co-author (along with David Slate and Keith
Gorlen) of the famous "Chess" line of programs back in the 1970's. At the
time of the article, Chess was at about version 4.5.

This program, Chess 0.5, is based on his intimate knowledge of that program,
but is, of course, a brand new and seperate program.

I speculate that Chess 0.5 was also done as an experimental program for
their own purposes. In 1977 (more than a year before Chess 0.5 was
published), they were already planning a new chess program, eventually
called NuChess, which debuted in 1980. It's possible Chess 0.5 was used by
them to test a few concepts and compilers. (Chess 4.x was written in
COMPASS macro assembly. NuChess was in FORTRAN.) In other words, a
portability and compiler experiment.

Chess 0.5 was written in a very old (although new at the time) dialect of
Pascal that predates any standard. Scott Moore lists it as Pascal 6000-3.4
on the CDC 6400 computer. The actual original Wirth / Amman compiler
itself!

It's very similar to regular ISO-7185 Pascal, but there are a few
differences, since it predates the standard. Standard Pascal has tightend
up the TYPE's even more and put a few restrictions on GOTO that the author's
Pascal obviously didn't have.

Although it was written for portability, there were a few CDC specific
items. A few routines have alternate cdc 6x00 specific versions, it uses
the CDC character set (which wasn't ASCII), and it uses GOTO's in a way that
many other Pascal compilers (then and now) don't bother to implement fully.


Chess 0.5 was published in Byte Magazine in November and December of 1978,
with a couple of additional articles in October 1978 and January 1979.

The program was designed to be able to play chess vaguely well on the
hardware of the time, and to do so with readable demonstration program.

It was not designed to play extremely well or for modern hardware. It was
not designed for efficiency.

There were many techniques, ideas, and methods that were deliberately left
out in order to keep the program as a demonstration program, and to let it
run on limited hardware.

That doesn't mean it can't play a decent game if you adjust some settings to
let it search deep enough. But don't expect it to compare well against
modern programs. Especially since the program is written for clairity in
Pascal, rather than for efficiency.

The value of the program is historical, not as a quality chess player.


Copyright
*********

I don't see an explicit copyright in the program or article, but I would
assume that both Peter Frey and Larry Atkin still own it. However, I
seriously doubt that either one of them woud care about the distribution of
their 27 year old article and program.

If anything, I would expect them to be glad (and surprised) that anybody
still cares about it, and looks upon it fondly.

It is possible that Byte Magazine might claim copyright, but I don't know
whether Peter Frey and Larry Atkin signed it over. I have trouble beliving
Larry Atkin would have, since it was based on Chess 4.5

Additionally, there were two public tounament programs in the early 80's
that were based on Chess 0.5. Merlin and Shy. Byte didn't complain about
that.

And in 1978, the spirit of Byte Magazine was as a hobbiest magazine sharing
programs, etc. That's why they published programs such as Chess 0.5! Not
at all like how Byte evolved into yet another "Me too" review magazine.

So any complaints by Byte would be hard to justify.

Still, it's good maners to say that it's "Chess 0.5 by Peter Frey and Larry
Atkin, published in Byte Magazine."


About this copy
***************

My copy was originally a photocopy that was made in the late 80's.

I scanned it in and used the ABBYY FineReader OCR program on it.

Considering the small print of the original listing, and the quality of my
photocopy, I am impressed with its OCR abilities.

I am, however, significantly less than impressed with its abilities to
output in a usable format.

If all you want is the OCR ability, then FineReader will probably do the
job. But do NOT expect to be able to easily use the output!

If you need to work with the output, then you should definetly find another
OCR program, or expect to spend a lot of time trying to get it into a usable
format.


Reporting an error
******************

Since this was an OCR copy, it's possible there are still errors in it.

My copy was poor and the font was small, and it was hard for the program to
tell the difference betwwen M and N, and D and O, O and 0, 1 and l, 8 and
B, and so on.

Pascal's type checking took care of most of that, but there were a few that
could be either one.

I'm pretty sure I've corrected all the important stuff, but there may still
be errors. And of course, typo's in the comments.

I have also attempted to restore the original formatting of the program.

Also, there may be errors in the program itself, that aren't related my
work.

In function YRMHIT, a comment has the word "firt". That's a genuine typo
error in the original program.

There may or may not have been bug reports sent to Byte Magazine, Peter
Frey, or Larry Atkin. I don't know.


******************************************************************************
If you spot any, please report them to the rec.games.chess.computer
newsgroup.
Please use a subject with "Byte Chess 0.5" in it to make it easily searched.
******************************************************************************


Why Pascal?
***********
I'm sure many of you are wondering why they chose Pascal....

Simple.

There weren't many portable languages available. Things were different back
then.

Although there were a variety of languages around, they didn't have all of
them on the cdc 6400 computer they used, and most weren't available at all
for the smaller computers of the time. And that was one of the goals of
Chess 0.5

The choices were basically: BASIC, Fortran, Forth, Pascal.

C is not included because it was still relatively obscure. Especially in
micros. Even an early version of Small-C didn't come along until 1980.

BASIC wasn't really suitable.

Forth could have certainly been chosen. It's a small language. Interpreted
it's tolerably fast, and compiled, it's as fast as any other. But in 1978 it
wasn't really wide spread. Wide enough that it could have been a
possibility, though. And Forth is small enough that it could have been
implemented by hobbiests. But since Chess 0.5 was based on Chess 4.5,
trying to convert that into Forth would have been difficult. And Larry
Atkin probably wasn't familiar with Forth, anyway.

Fortran could have been chosen. It wasn't structured well for things like
this, but it could have been done. Compilers weren't widely available for
micros, though. However I suspect it was a strong possibility, since the
successor to Chess 4.x ended up being written in FORTRAN. They chose
Fortran because all the other compilers they had that had better language
syntax were too inefficient.

That leaves Pascal. A language pretty much designed for portability,
tutorials, and such. It was highly structured, easy to understand,
fashionably strongly typed. Pretty much an ideal language for the purpose
of the program and article. The only real problems were that it wasn't wide
spread either. And the authors ended up using features that were not widely
available in the compilers that were available at the time, so the few micro
pascal's that were available were unable to compile the program. (A
situation that hasn't changed since then, actually.)

So, given the choices, they made the right choice.



Compiling the program
*********************

The program uses interprocedural goto's, and procedural parameters. Both
are standard, official Pascal, but most compilers don't bother to implement
them. This does mean that Borland / Turbo Pascal can not compile it. The
same for FPC (Free Pascal Compiler).

In fact, most free compilers and most older compilers are not likely to have
bothered to implement official standard pascal, but only a subset with some
private extensions. (The Borland / Turbo pascal compilers are infamous.)

You can easily modify the program to not need the procedural parameters, but
the goto's are much more difficult to get rid of.

You will probably have to use the GNU Pascal compiler. It's the only free
pascal compiler that I know of that can handle it.


Changes to compile under GPC.

1) The constants AC and ZC aren't needed.

2) Type SC should be changed to
SC = SET OF CHAR;

3) Type 'RC' should be moved above RB

4) In RB, RBIS should be changed to type RC

5) Var MBORD should be changed to type RC

6) Var ATKTO should be changed to type RX

7) Var ATKFR should be changed to type RX

8) Var MOVES should be changed to type RF

9) Var VALUE should be changed to type RE

10) In RDRGNT, the statement:
WHILE (JNTJ < ZJ) AND (ORD(ILINE[JNTJ]) >= ORD('+')) DO
should be replaced with:
WHILE (JNTJ < ZJ) AND (NOT (ILINE[JNTJ] IN ['A'..'Z','0'..'9'])) DO

11) In RDRGNT, the statement:
WHILE (JNTJ < ZJ) AND (INTJ < ZA) AND (ILINE[JNTJ] IN ['A'..'9']) DO
should be replaced with:
WHILE (JNTJ < ZJ) AND (INTJ < ZA) AND
(ILINE[JNTJ] IN ['A'..'Z','0'..'9']) DO

12) In RDRGNT, the statement:
WHILE (INTJ < ZJ) AND (JNTJ < ZJ) AND (ILINE[JNTJ] IN ['A'..'9']) DO
should be replaced with:
WHILE (INTJ < ZJ) AND (JNTJ < ZJ) AND
(ILINE[JNTJ] IN ['A'..'Z','0'..'9']) DO

13) In BOACMD replace line:
IF ILINE[JNTJ] IN ['A'..'9'] THEN
with:
IF ILINE[JNTJ] IN ['A'..'Z','0'..'9'] THEN

14) In NCHIN, replace line:
AND ((ILINE[JNTJ]= ' ') OR (ORD(ILINE[JNTJ]) > ORD(ZC))) DO
with:
AND ((ILINE[JNTJ]= ' ') ) DO

15) The program uses double quote " to delimit strings, where as Pascal uses
single quote ' to do that. Either do a global search and replace, or
give
the compiler the --gnu-pascal switch.




Additional helpful changes
1) If desired, in function inicon, you can change the piece letters to
upper and lower case, instead of letters and numbers.
The CDC character set didn't have lower case.

2) In prinam, before the final write(' ') you can put
if (intf <> f8) then

3) In RDLINE, you might want to add the lines:
IF ( (ICARD[INTJ] >= 'a') AND (* LOWER CASE *)
(ICARD[INTJ] <= 'z') ) THEN
ICARD[INTJ] := CHR(ORD(ICARD[INTJ])-32); (*ASCII ONLY*)
The lines should be placed right after the line: read(icard[intj]);
This allows the program to understand lower case ASCII

4) In YRMOVE, right after LSTMOV, you can add the following lines to make
the program give you a list of the moves available. Just in case you
can't remember how to do classic chess move notation.
FOR INTW := AW TO JNTW-1 DO
BEGIN
MINENG(MOVES[intw],'');
WRITeln(intw:2,' ',movms);
END;


To realistically run this on non-8 bit micros (or anything with more than a
few hundred thousand instructions per second!), increase ZW to at least 1000
or so, and increase FNODEL, which controls how many nodes are searched.

FNODEL is basically the control of how deep you want to search and therefor
how long you search. Expect anywhere from 100 nodes per second on an old
old computer, to 10,000 per second on newer hardware.

You might also want to increase ZK to 30 or so, but it's not required.



Running the program
*******************

Everything should be entered in upper case, unless you make the modification
suggested above.

Depending on the compiler used, the program may occasionally skip a full
line of input! This is due to Pascal's infamous problem with keyboard
input, and dealing with EOLn, and so on.

Some compilers get it right, others don't. It obviously worked right with
the original Pascal compiler the authors used, but it may not with yours.

There is no quick and easy fix because the failure may vary depending on
what compiler you use, what library it uses, and so on.

With the version of GPC I used during debuggin, it would always miss the
first line of input, the 'pause' line of input, and an occasional one
depending on what command I had just done.

This is only annoying, and doesn't actually effect play.


The first move listed with PM seems to be the move that was just made. This
is probably a feature.

Moves are entered using old style chess notation. You know, p-kb3 and that
kind of stuff. The program doesn't know about any fancy "algebraic"
notation.


The list of commands are:

BO - BOARD Set up a position
Start at the lower left. L means Lite, D means Dark. P, N, B, R, Q, K
should
be obvious. Empty square are done as a number 1-8.
board lrnbqkb1rpppp1ppp5n24p34dp33n4pppp1pppr1bqkbnr

EN - END program

GO - GO 'n' moves

IN - INITIALIZE for a new game

LE - LET (set) variable
FKPSHD
FKSANQ
FMAXMT
FNODEL
FPADQR
FPADQN
FPADQB
FPADQF
FPADKF
FPADKB
FPADKN
FPADKR
FPBLOK
FPCONN
FPFLNX
FRDUBL
FRK7TH
FTRADE
FTRDSL
FTRPDK
FTRPWN
FWKING
FWMAJM
FWMINM
FWPAWN
FWROOK
WINDOW

PB - Print attack map Boards
TO - to squares
FROM - from squares

PO - Print Other stuff

PL - Print 'Let' variables
FKPSHD
FKSANQ
FMAXMT
FNODEL
FPADQR
FPADQN
FPADQB
FPADQF
FPADKF
FPADKB
FPADKN
FPADKR
FPBLOK
FPCONN
FPFLNX
FRDUBL
FRK7TH
FTRADE
FTRDSL
FTRPDK
FTRPWN
FWKING
FWMAJM
FWMINM
FWPAWN
FWROOK
WINDOW

PM - Print Move list
Unfortunately, this wont be in english, but only as numbers.

PR - PRint board
An optional argument (anything) will show mbord.
Useful for verifying detecting errors in update & downdate.

ST - STatus change
D - Dark
EP - Enpassant (qr, qn, rb, q, k, kb, kn, kr)
G - set side to move
L - Lite
N - set move number
OO - allow king side castle
OOO - allow queen side castle

SW - SWitch xxx (on off or none to print)
EC - echo input
PA - paging
PS - print preliminary scores
RE - reply with move
SU - print statistics summary
TR - trace tree search

WH - WHat? reprint last message

Generally, only the first two letters are used to identify a command and
subcommand.


2005-05-30
Initial release

2005-05-30
A couple of typos in this doc were fixed.
Some strings were too long.
I forgot to convert some ' back to "
Fixed typo. "IMWALID MOVE"
A few misc. typos in comments.

2005-06-01
Typo in comment

2005-06-03
Work on this doc.
minor Work on a few comments in the program.
****End ByteChess.txt

***Begin Chess05-diff.txt
65c65
< TY = AY..ZY; (* NUMBER OF TX'S IN A BOARD *)
---
> TY = AY..ZY; (* NUMBER OF TX"S IN A BOARD *)
76c76
< (* RECOROS *)
---
> (* RECORDS *)
78,82c78,82
< RB = RECORD (* BOARDS *)
< RBTM : TM; (* SIDE TO MOVE *)
< RBTS : TT; (* ENPASSANT SQUARE *)
< RBTI : TI; (* MOVE NUMBER *)
< RBSQ : SQ; (* CASTLE FLAGS *)
---
> RB = RECORD (* BOARDS *)
> RBTM : TM; (* SIDE TO MOVE *)
> RBTS : TT; (* ENPASSANT SQUARE *)
> RBTI : TI; (* MOVE NUMBER *)
> RBSQ : SQ; (* CASTLE FLAGS *)
84c84
< 0: ( RBIS : ARRAY [TS] OF TP); (* INDEXED BY SQUARE *)
---
> 0: ( RBIS : ARRAY [TS] OF TP); (* INDEXED BY SQUARE *)
168c168
< SRCHM : ARRAY [TK] OF TH; (* SEARCH MOVES *)
---
> SRCHM : ARRAY [TK] OF TH; (* SEARCH MODES *)
214c214
< (* COMMAND PROCESSING OATA *)
---
> (* COMMAND PROCESSING DATA *)
432c432
< (*** FOLLOWING CODE REQUIRES THE 'EXPO' FUNCTION TO RETURN
---
> (*** FOLLOWING CODE REQUIRES THE "EXPO" FUNCTION TO RETURN
478c478
< (*** FOLLOWING COOE REQUIRES THE 'CARD' FUNCTION TO
---
> (*** FOLLOWING COOE REQUIRES THE "CARD" FUNCTION TO
940,941c940,941
< ICARD[ZJ] := ';';
< ILINE[ZJ] := ';';
---
> ICARD[ZJ] := ";";
> ILINE[ZJ] := ";";
3016,3042c3016,3042
< LETONE("FKPSHD ",FKPSHD);
< LETONE("FKSANQ ",FKSANQ);
< LETONE("FMAXMT ",FMAXMT);
< LETONE("FNODEL ",FNODEL);
< LETONE("FPADQR ",FPADCR[F1]);
< LETONE("FPADQN ",FPADCR[F2]);
< LETONE("FPADQB ",FPADCR[F3]);
< LETONE("FPADQF ",FPADCR[F4]);
< LETONE("FPADKF ",FPADCR[F5]);
< LETONE("FPADKB ",FPADCR[F6]);
< LETONE("FPADKN ",FPADCR[F7]);
< LETONE("FPADWR ",FPADCR[F8]);
< LETONE("FPBLOK ",FPBLOK);
< LETONE("FPCONN ",FPCONN);
< LETONE("FPFLNX ",FPFLNX);
< LETONE("FRDUBL ",FRDUBL);
< LETONE("FRK7TH ",FRK7TH);
< LETONE("FTRADE ",FTRADE);
< LETONE("FTRDSL ",FTRDSL);
< LETONE("FTRPDK ",FTRPDK);
< LETONE("FTRPWN ",FTRPWN);
< LETONE("FWKING ",FWKING);
< LETONE("FWMAJM ",FWMAJM);
< LETONE("FWMINM ",FWMINM);
< LETONE("FWPAWN ",FWPAWN);
< LETONE("FWROOK ",FWROOK);
< LETONE("WINDOW ",WINDOW);
---
> LETONE("FKPSHD ",FKPSHD);
> LETONE("FKSANQ ",FKSANQ);
> LETONE("FMAXMT ",FMAXMT);
> LETONE("FNODEL ",FNODEL);
> LETONE("FPADQR ",FPADCR[F1]);
> LETONE("FPADQN ",FPADCR[F2]);
> LETONE("FPADQB ",FPADCR[F3]);
> LETONE("FPADQF ",FPADCR[F4]);
> LETONE("FPADKF ",FPADCR[F5]);
> LETONE("FPADKB ",FPADCR[F6]);
> LETONE("FPADKN ",FPADCR[F7]);
> LETONE("FPADWR ",FPADCR[F8]);
> LETONE("FPBLOK ",FPBLOK);
> LETONE("FPCONN ",FPCONN);
> LETONE("FPFLNX ",FPFLNX);
> LETONE("FRDUBL ",FRDUBL);
> LETONE("FRK7TH ",FRK7TH);
> LETONE("FTRADE ",FTRADE);
> LETONE("FTRDSL ",FTRDSL);
> LETONE("FTRPDK ",FTRPDK);
> LETONE("FTRPWN ",FTRPWN);
> LETONE("FWKING ",FWKING);
> LETONE("FWMAJM ",FWMAJM);
> LETONE("FWMINM ",FWMINM);
> LETONE("FWPAWN ",FWPAWN);
> LETONE("FWROOK ",FWROOK);
> LETONE("WINDOW ",WINDOW);
3070,3096c3070,3096
< PRIONE("FKPSHD ",FKPSHD);
< PRIONE("FKSANQ ",FKSANQ);
< PRIONE("FMAXMT ",FMAXMT);
< PRIONE("FNODEL ",FNODEL);
< PRIONE("FPADQR ",FPADCR[F1]);
< PRIONE("FPADQN ",FPADCR[F2]);
< PRIONE("FPADQB ",FPADCR[F3]);
< PRIONE("FPADQF ",FPADCR[F4]);
< PRIONE("FPADKF ",FPADCR[F5]);
< PRIONE("FPADKB ",FPADCR[F6]);
< PRIONE("FPADKN ",FPADCR[F7]);
< PRIONE("FPADKR ",FPADCR[F8]);
< PRIONE("FPBLOK ",FPBLOK);
< PRIONE("FPCONN ",FPCONN);
< PRIONE("FPFLNX ",FPFLNX);
< PRIONE("FRDUBL ",FRDUBL);
< PRIONE("FRK7TH ",FRK7TH);
< PRIONE("FTRADE ",FTRADE);
< PRIONE("FTRDSL ",FTRDSL);
< PRIONE("FTRPDK ",FTRPDK);
< PRIONE("FTRPWN ",FTRPWN);
< PRIONE("FWKING ",FWKING);
< PRIONE("FWMAJM ",FWMAJM);
< PRIONE("FWMINM ",FWMINM);
< PRIONE("FWPAWN ",FWPAWN);
< PRIONE("FWROOK ",FWROOK);
< PRIONE("WINDOW ",WINDOW);
---
> PRIONE("FKPSHD ",FKPSHD);
> PRIONE("FKSANQ ",FKSANQ);
> PRIONE("FMAXMT ",FMAXMT);
> PRIONE("FNODEL ",FNODEL);
> PRIONE("FPADQR ",FPADCR[F1]);
> PRIONE("FPADQN ",FPADCR[F2]);
> PRIONE("FPADQB ",FPADCR[F3]);
> PRIONE("FPADQF ",FPADCR[F4]);
> PRIONE("FPADKF ",FPADCR[F5]);
> PRIONE("FPADKB ",FPADCR[F6]);
> PRIONE("FPADKN ",FPADCR[F7]);
> PRIONE("FPADKR ",FPADCR[F8]);
> PRIONE("FPBLOK ",FPBLOK);
> PRIONE("FPCONN ",FPCONN);
> PRIONE("FPFLNX ",FPFLNX);
> PRIONE("FRDUBL ",FRDUBL);
> PRIONE("FRK7TH ",FRK7TH);
> PRIONE("FTRADE ",FTRADE);
> PRIONE("FTRDSL ",FTRDSL);
> PRIONE("FTRPDK ",FTRPDK);
> PRIONE("FTRPWN ",FTRPWN);
> PRIONE("FWKING ",FWKING);
> PRIONE("FWMAJM ",FWMAJM);
> PRIONE("FWMINM ",FWMINM);
> PRIONE("FWPAWN ",FWPAWN);
> PRIONE("FWROOK ",FWROOK);
> PRIONE("WINDOW ",WINDOW);
3203,3208c3203,3208
< SWIONE("EC ",SWEC);
< SWIONE("PA ",SWPA);
< SWIONE("PS ",SWPS);
< SWIONE("RE ",SWRE);
< SWIONE("SU ",SWSU);
< SWIONE("TR ",SWTR);
---
> SWIONE("EC ",SWEC);
> SWIONE("PA ",SWPA);
> SWIONE("PS ",SWPS);
> SWIONE("RE ",SWRE);
> SWIONE("SU ",SWSU);
> SWIONE("TR ",SWTR);
3274,3281c3274,3281
< STAEPF("QR ",F1);
< STAEPF("QN ",F2);
< STAEPF("QB ",F3);
< STAEPF("Q ",F4);
< STAEPF("K ",F5);
< STAEPF("KB ",F6);
< STAEPF("KN ",F7);
< STAEPF("KR ",F8);
---
> STAEPF("QR ",F1);
> STAEPF("QN ",F2);
> STAEPF("QB ",F3);
> STAEPF("Q ",F4);
> STAEPF("K ",F5);
> STAEPF("KB ",F6);
> STAEPF("KN ",F7);
> STAEPF("KR ",F8);
3378c3378
< RDRERR("* IMWALID COMMAND ");
---
> RDRERR("* INVALID COMMAND ");
3579c3579
< ADDWRD("O-O ",3);
---
> ADDWRD("O-O ",3);
3581c3581
< ADDWRD("-O ",2);
---
> ADDWRD("-O ",2);
3593c3593
< ADDWRD(". ",3);
---
> ADDWRD(". ",3);
3596c3596
< ADDWRD("CHECK ",5);
---
> ADDWRD("CHECK ",5);
3598c3598
< ADDWRD("MATE ",4);
---
> ADDWRD("MATE ",4);

***End Chess05-diff.txt



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

More about : update byte chess

Anonymous
June 13, 2005 8:10:01 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I Forget wrote:
>
> I've made some additions to the short text file that goes with Byte Chess
> 0.5, plus a 'diff' list of changes from the version I originally
> distributed.
>

The follow list of errors are from a run of GPC20021128/gcc-3.2.1

[1] c:\p\src\chess05>gpc chess0~1.pas
chess0~1.pas: In procedure `Inisyn':
chess0~1.pas:674: warning: ISO Pascal forbids this use of packed
record fields
chess0~1.pas:683: warning: ISO Pascal forbids this use of packed
record fields
chess0~1.pas: In procedure `Lstmov':
chess0~1.pas:2207: warning: `;' after `then'
chess0~1.pas: In function `Rdrgnt':
chess0~1.pas:2792: warning: specified set member range is empty
chess0~1.pas:2792: warning: `... in []' (empty set) is always
`False'
chess0~1.pas:2799: warning: specified set member range is empty
chess0~1.pas:2799: warning: `... in []' (empty set) is always
`False'
chess0~1.pas: In procedure `Boacmd':
chess0~1.pas:2974: warning: specified set member range is empty
chess0~1.pas:2974: warning: `... in []' (empty set) is always
`False'
chess0~1.pas: In procedure `Pamcmd':
chess0~1.pas:3136: passing arg 1 of `Prinam' from incompatible
array
chess0~1.pas:3139: passing arg 1 of `Prinam' from incompatible
array
chess0~1.pas: In procedure `Yrmove':
chess0~1.pas:3959: warning: `;' after `then'
chess0~1.pas:3960: warning: `;' after `then'
chess0~1.pas:3961: warning: `;' after `then'
chess0~1.pas:3968: warning: `;' after `then'
chess0~1.pas:3969: warning: `;' after `then'
chess0~1.pas:3970: warning: `;' after `then'



The following list of non-warning errors from a run of PascalP on
it primarily shows failure to declare labels properly. Some of
them are due to the fact that PascalP only keeps 8 chars of
identifiers (the line 100 error), and has a maxint of 32767. The
implementation restriction errors appear to be from passing
procedures/functions, which are not implemented. You can pick up a
DOS/Windows executable version of PascalP on my site.

Contrary to appearances, the identifier declared twice is
arraytkoftw, and shouldn't show up on other compilers.

PASCALP (pasctext, pasclist, prr, ef, output) [parm] V 3.1.9T
33000 0:D  PZX8 = 16777216; (*
2^(ZX-7) *)
**** ^100
100. Numeric constant exceeds range
149000 0:D  arraytkoftw = array [tk] of tw;
**** ^30
30. Identifier declared twice
1261000 141: 2 DIV (4*INTI+FTRPWN) DIV
262144,16320),MBLTE);
**** ^100
100. Numeric constant exceeds range
1658000 54: 4 LINDX[JNTK] := JNTW; (*
MOVES ARRAY LIMIT *)
**** ^55
55. Operand type conflict
1782000 442: 4 JNTW := LINDX[JNTK]; (*
RESET MOVE GENERATION
**** ^55
55. Operand type conflict
1812000 140: 4 LINDX[JNTK] := JNTW; (*
MOVES ARRAY LIMIT *)
**** ^55
55. Operand type conflict
2399000 28: 3 BSTMV[A] := INDEX[A+1]; (*
SAVE BEST MOVE *)
**** ^55
55. Operand type conflict
2402000 58: 5 INRM := MOVES[BSTMV[A]]; (*
SAVE BEST MOVE *)
**** ^41,65^55
41. Index type must be scalar or subrange
55. Operand type conflict
65. Index type incompatible with declaration
2403000 86: 6 FOR INTW := BSTMV[A]-1 DOWNTO AW+1 DO
**** ^60
60. Illegal type of operand(s)
2406000 166: 5 BSTMV[AK] := AW+1; (*
POINTS TO BEST MOVE *)
**** ^55
55. Operand type conflict
2409000 191: 5 IF NOT MOVES[BSTMV[A]].RMCA THEN
**** ^41,65^78
41. Index type must be scalar or subrange
65. Index type incompatible with declaration
78. No such field in this record
2410000 222: 3 KILLR[JNTK] := MOVES[BSTMV[A]];(*
SAVE KILLER MOVE *)
****
^41,65^55
41. Index type must be scalar or subrange
55. Operand type conflict
65. Index type incompatible with declaration
2474000 66: 4 GOTO 22; (*
EXIT SELECT *)
**** ^90
90. Undeclared label
2493000 130: 4 GOTO 22; (*
EXIT SELECT *)
**** ^90
90. Undeclared label
2503000 32: 4 INDEX[JNTK+1] := LINDX[JNTK]-1; (*
RESET MOVES POINTER *)
**** ^60
60. Illegal type of operand(s)
2505000 49: 4 GOTO 21; (*
EXECUTE NEXT MODE *)
**** ^90
90. Undeclared label
2581000 668: 6 FOR IMTW := LINDX[JNTK] TO
JNTW-1 DO
**** ^70
70. Illegal type of expression
2599000 843: 6 FOR IMTW := LINDX[JNTK] TO
JNTW-1 DO
**** ^70
70. Illegal type of expression
2649000 1239: 5 JNTW := LINDX[AK+1]; (*
POINT TO ALREADY GENERATED MOVES *)
**** ^55
55. Operand type conflict
2665000 15: 2 BSTMV[AK] := AW; (*
INITIALIZE MOVE *)
**** ^55
55. Operand type conflict
2736000 753: 2 SEARCH := BSTMV[AK]; (*
RETURN BEST MOVE *)
**** ^55
55. Operand type conflict
2770000 206: 3 GOTO 11; (*
COMMAND EXIT *)
**** ^90
90. Undeclared label
2821000 28: 3 PROCEDURE XXXCMD); (*
PROCEDURE TO EXECUTE COMNAND *)
**** ^108
108. Implementation restriction
2827000 18: 5 GOTO 11; (*
EXIT *)
**** ^90
90. Undeclared label
2989000 3: 3 GOTO 9; (*
END PROGRAM *)
**** ^90
90. Undeclared label
3001000 36: 3 GOTO 2; (*
EXECUTE MACHINES MOVE *)
**** ^90
90. Undeclared label
3008000 3: 3 GOTO 1; (*
INITIALIZE FOR A NEW GAME *)
**** ^90
90. Undeclared label
3025000 27: 6 GOTO 21; (*
EXIT *)
**** ^90
90. Undeclared label
3079000 42: 6 GOTO 21; (*
EXIT *)
**** ^90
90. Undeclared label
3211000 153: 6 GOTO 21; (*
SWITCH OPTION EXIT *)
**** ^90
90. Undeclared label
3251000 74: 6 GOTO 21; (*
EXIT STATUS OPTION *)
**** ^90
90. Undeclared label
3328000 18: 4 PROCEDURE STAXXX); (*
PROCEDURE TO EXECUTE IF EQUAL *)
**** ^108
108. Implementation restriction
3334000 18: 6 GOTO 21; (*
EXIT STATUS OPTION *)
**** ^90
90. Undeclared label
3345000 47: 5 STAOPT('D ',STADRK);
**** ^108
108. Implementation restriction
3346000 67: 5 STAOPT('EP ',STAENP);
**** ^108
108. Implementation restriction
3347000 87: 5 STAOPT('G ',STAGOS);
**** ^108
108. Implementation restriction
3348000 107: 5 STAOPT('L ',STALIT);
**** ^108
108. Implementation restriction
3349000 127: 5 STAOPT('N ',STANUM);
**** ^108
108. Implementation restriction
3350000 147: 5 STAOPT('OO ',STACAK);
**** ^108
108. Implementation restriction
3351000 167: 5 STAOPT('OOO ',STACAQ);
**** ^108
108. Implementation restriction
3382000 243: 4 RDRCMD('BO ',BOACMD);
**** ^108
108. Implementation restriction
3383000 263: 4 RDRCMD('EN ',ENDCMD);
**** ^108
108. Implementation restriction
3384000 283: 4 RDRCMD('GO ',GONCMD);
**** ^108
108. Implementation restriction
3385000 303: 4 RDRCMD('IN ',INICMD);
**** ^108
108. Implementation restriction
ABORT on errorcount=50


--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Anonymous
June 13, 2005 4:22:28 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:42ACB917.39442342@yahoo.com...
>
> The follow list of errors are from a run of GPC20021128/gcc-3.2.1

Hmmm... I used the djgpp version:
D:\BChess>gpc -v
Reading specs from f:/djgpp/lib/gcc-lib/djgpp/3.23/specs
Configured with: /djgpp/b/gnu/gcc-3.23/configure
i586-pc-msdosdjgpp --prefix=/de
v/env/DJDIR --disable-nls --enable-languages=pascal --enable-checking
Thread model: single
gpc version 20041218, based on gcc-3.2.3

About 2 years newer than yours.

After making the limited changes as described in my doc, I get the following
warnings.

D:\BChess>gpc chess05.pas -o chess05.exe
chess05.pas: In procedure `INICON':
chess05.pas:857: warning: `for' loop counter is threatened in a subroutine
chess05.pas: In procedure `LSTMOV':
chess05.pas:2194: warning: `;' after `then'
chess05.pas: In procedure `BOACMD':
chess05.pas:2945: warning: `for' loop counter is threatened in a subroutine
chess05.pas:2965: warning: `for' loop counter is threatened in a subroutine
chess05.pas: In procedure `YRMOVE':
chess05.pas:3928: warning: `;' after `then'
chess05.pas:3929: warning: `;' after `then'
chess05.pas:3930: warning: `;' after `then'
chess05.pas:3937: warning: `;' after `then'
chess05.pas:3938: warning: `;' after `then'
chess05.pas:3939: warning: `;' after `then'

None of those are significant. They don't effect compilation or play. So I
don't bother providing changes to fix those.

It runs. I've played a couple games with it and a few test positions.
Things appear to work properly.

Remember, my version is *not* ISO compatable. The version I do is as close
to the original published version as possible. And that was written in
1978, which predates the ISO standard.

Scott Moore already distributes one that can compile with ISO. I didn't
write that one, so I don't know a lot about it.

I've never really used pure ISO pascal compiler. Back when I was using a
Pascal compiler on an 8 bit micro, mine was much more relaxed. When I
switched later to a PC, I used Turbo Pascal briefly then switched to C.

What few experiences I had with ISO pascal convinced me it was a worthless
piece of ^%$@! not fit to exist. They seemed to have gone out of their way
to make it difficult to use. Nit pickingly tedious. You spend more time
making the compiler happy than you do getting the job done.


As I've stated a few times, my concern is to get the original program, with
all the typos removed, etc. To me, that's the value of the program.
Historical.

Heck, even I've written a chess program that could probably easily beat
Chess 0.5 (mostly due to modern techniques and language efficiency. Larry
Atkin really "jumped through hoops" to get the program written in Pascal.)
So playing Chess 0.5 is not really a big deal to me.

If I do need to run it, well, the current gpc can do it.


> [1] c:\p\src\chess05>gpc chess0~1.pas
> chess0~1.pas: In procedure `Inisyn':
> chess0~1.pas:674: warning: ISO Pascal forbids this use of packed
> record fields
> chess0~1.pas:683: warning: ISO Pascal forbids this use of packed
> record fields

Well, the program was written in 1978... Long before the ISO standard.

It was written on an actual Wirth compiler. That's one of the things that
makes the program so significant.

So realistically, if there's an ISO problem, it's ISO's fault for not
adhering to the original Wirth spec...[grin]

> chess0~1.pas: In procedure `Lstmov':
> chess0~1.pas:2207: warning: `;' after `then'

Yup. Sloppy coding. Still, there are only a few places like that, so over
all, not too bad.

> chess0~1.pas: In function `Rdrgnt':
> chess0~1.pas:2792: warning: specified set member range is empty
> chess0~1.pas:2792: warning: `... in []' (empty set) is always

These and the others are due to the original program using the CDC character
set.

In the docs I posted, it does describe the simple changes needed in these
areas to make them work under ASCII.

> chess0~1.pas: In procedure `Pamcmd':
> chess0~1.pas:3136: passing arg 1 of `Prinam' from incompatible
> array
> chess0~1.pas:3139: passing arg 1 of `Prinam' from incompatible

ISO pascal is apparently much more picky about types.

It seems to have gotten rid of the very useful 'equivelent type' and now
requires 'exact type'.

The ISO people back then didn't ask for my advice, so I can't help
that...[grin]

> chess0~1.pas: In procedure `Yrmove':
> chess0~1.pas:3959: warning: `;' after `then'
> chess0~1.pas:3960: warning: `;' after `then'
> chess0~1.pas:3961: warning: `;' after `then'
> chess0~1.pas:3968: warning: `;' after `then'
> chess0~1.pas:3969: warning: `;' after `then'
> chess0~1.pas:3970: warning: `;' after `then'

Yup.... LSTMOV and YRMOVE do that. Sloppy coding.

Most of the program is written pretty well. Impressively so, considering he
was basing it on an assembly program. But it does have a few warts.

> The following list of non-warning errors from a run of PascalP on
> it primarily shows failure to declare labels properly. Some of

Actually, they did *NOT* fail to declare labels properly.

Remember, they used an original Wirth/Amman compiler.

The rules were different for it. What they did was 100% valid. Otherwise
they would have done it differently.


> them are due to the fact that PascalP only keeps 8 chars of
> identifiers (the line 100 error), and has a maxint of 32767. The

I think most 8 bit micros only had 16 bit ints, too.

That is an area where Chess 0.5 is not all that portable.

I don't know if any later issues of Byte had any notes about things like
that.

I suspect not.

Which is kind of telling, because it suggests that few people managed to
type it in that tiny printing and get it to work on their particular version
of Pascal.

I know of two groups (who did Merlin and Shy chess programs), but I doubt
many others did.

The goto's, the procedural parameters and the very small printing were
definetly problems.

As I mention in the "why did they choose Pascal" section of my doc, they
just didn't have many other choices.

> PASCALP (pasctext, pasclist, prr, ef, output) [parm] V 3.1.9T
> 33000 0:D  PZX8 = 16777216; (*
> 2^(ZX-7) *)
> **** ^100
> 100. Numeric constant exceeds range

Not really a problem, because that constant is used only in the CDC specific
part of the code.

They should have commented that and the RK record out, but they didn't.

> 149000 0:D  arraytkoftw = array [tk] of tw;
> **** ^30
> 30. Identifier declared twice

That would be Scott Moore's version....

He's the one who did the ISO modifications.

I don't think his web page points out that distinction, though. It should.

> 1261000 141: 2 DIV (4*INTI+FTRPWN) DIV
> 262144,16320),MBLTE);
> **** ^100
> 100. Numeric constant exceeds range

There are some areas where I've wondered about integer overflow.

I haven't studied the code that carefully, though.

I figure it works fine with 32+ bit ints, which is what the original
computer and compiler used.

If I was going to try and do it with an 8 bit, or convert it to C or
something, then I'd look more closely.


Still, as I said above, my interest in it is definetly 'historical'. As
long as I can make a few relatively simple changes (mentioned in my docs) to
get it to compile and run with at least one readily available compiler
(current gpc, in this case), then that's enough.

(True, I would have actually prefered something like P4 or even UCSD.
Something from that time period. But it didn't work out. So GPC will have
to do.)

If I was actually going to want to get the program to run well, to actually
play it, I'd convert it to C, use "unsigned long long", get rid of the 8 and
16 bit portability, get rid of a bunch of other stuff. (Basically, rewrite
it into something Larry Atkin hopefully would have done if he had written it
today.)




----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Related resources
Anonymous
June 13, 2005 4:22:29 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I Forget wrote:
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
> news:42ACB917.39442342@yahoo.com...
>
>>The follow list of errors are from a run of GPC20021128/gcc-3.2.1
>
>
> Hmmm... I used the djgpp version:
> D:\BChess>gpc -v
> Reading specs from f:/djgpp/lib/gcc-lib/djgpp/3.23/specs
> Configured with: /djgpp/b/gnu/gcc-3.23/configure
> i586-pc-msdosdjgpp --prefix=/de
> v/env/DJDIR --disable-nls --enable-languages=pascal --enable-checking
> Thread model: single
> gpc version 20041218, based on gcc-3.2.3
>
> About 2 years newer than yours.

Humm, then perhaps the "with packed record" complaint from GCC was removed
in later compilers.

>
> After making the limited changes as described in my doc, I get the following
> warnings.
>
> D:\BChess>gpc chess05.pas -o chess05.exe
> chess05.pas: In procedure `INICON':
> chess05.pas:857: warning: `for' loop counter is threatened in a subroutine
> chess05.pas: In procedure `LSTMOV':
> chess05.pas:2194: warning: `;' after `then'
> chess05.pas: In procedure `BOACMD':
> chess05.pas:2945: warning: `for' loop counter is threatened in a subroutine
> chess05.pas:2965: warning: `for' loop counter is threatened in a subroutine
> chess05.pas: In procedure `YRMOVE':
> chess05.pas:3928: warning: `;' after `then'
> chess05.pas:3929: warning: `;' after `then'
> chess05.pas:3930: warning: `;' after `then'
> chess05.pas:3937: warning: `;' after `then'
> chess05.pas:3938: warning: `;' after `then'
> chess05.pas:3939: warning: `;' after `then'
>
> None of those are significant. They don't effect compilation or play. So I
> don't bother providing changes to fix those.
>
> It runs. I've played a couple games with it and a few test positions.
> Things appear to work properly.
>
> Remember, my version is *not* ISO compatable. The version I do is as close
> to the original published version as possible. And that was written in
> 1978, which predates the ISO standard.
>
> Scott Moore already distributes one that can compile with ISO. I didn't
> write that one, so I don't know a lot about it.

There were invalid gotos and invalid variable threats still left in the
"ISO" program I provided. Unfortunately, IP Pascal passed these (invalid
constructs) as valid. This was pointed out to me by Mr. Stewart of Irie Pascal.
I'm working to correct that now, then I will post a corrected ISO version of
chess.

>
> I've never really used pure ISO pascal compiler. Back when I was using a
> Pascal compiler on an 8 bit micro, mine was much more relaxed. When I
> switched later to a PC, I used Turbo Pascal briefly then switched to C.
>

Deleted, thanks.

>
>
> As I've stated a few times, my concern is to get the original program, with
> all the typos removed, etc. To me, that's the value of the program.
> Historical.
>
> Heck, even I've written a chess program that could probably easily beat
> Chess 0.5 (mostly due to modern techniques and language efficiency. Larry
> Atkin really "jumped through hoops" to get the program written in Pascal.)
> So playing Chess 0.5 is not really a big deal to me.
>
> If I do need to run it, well, the current gpc can do it.
>
>
>
>>[1] c:\p\src\chess05>gpc chess0~1.pas
>>chess0~1.pas: In procedure `Inisyn':
>>chess0~1.pas:674: warning: ISO Pascal forbids this use of packed
>>record fields
>>chess0~1.pas:683: warning: ISO Pascal forbids this use of packed
>>record fields
>
>
> Well, the program was written in 1978... Long before the ISO standard.
>
> It was written on an actual Wirth compiler. That's one of the things that
> makes the program so significant.
>
> So realistically, if there's an ISO problem, it's ISO's fault for not
> adhering to the original Wirth spec...[grin]

Or it may be specific to GPC, as mentioned above.

In general, the ISO 7185 spec clarified the grey areas in Wirth's original
specification of the language, and Wirth himself checked off on those
issues, and on the ISO 7185 standard itself. So ISO 7185 is Wirth's Pascal.
There were only two classes of programs that having been written before
the standard would have had to be changed. The first would be programs
using features that needed to be made secure because the original
language was ambiguous. An example would be procedure and function parameters.
The second would be programs that played fast and loose, testing the edge
of the language. An example would be a goto from inside one block to the
inside of another.

The chess program bent many of the rules of original Pascal to the breaking
point, it has parallel but equivalent types, gotos into different nested
statements, undiscriminated variants, etc. It is hardly a normal program
from that era, and it is hardly suprising that it was difficult to standardize.

And yet it was standardized with very little trouble. The ISO 7185 standard
is a good one, one of the best standards ever produced.

>
>
>>chess0~1.pas: In procedure `Lstmov':
>>chess0~1.pas:2207: warning: `;' after `then'
>
>
> Yup. Sloppy coding. Still, there are only a few places like that, so over
> all, not too bad.
>
>
>>chess0~1.pas: In function `Rdrgnt':
>>chess0~1.pas:2792: warning: specified set member range is empty
>>chess0~1.pas:2792: warning: `... in []' (empty set) is always
>
>
> These and the others are due to the original program using the CDC character
> set.
>
> In the docs I posted, it does describe the simple changes needed in these
> areas to make them work under ASCII.
>
>
>>chess0~1.pas: In procedure `Pamcmd':
>>chess0~1.pas:3136: passing arg 1 of `Prinam' from incompatible
>>array
>>chess0~1.pas:3139: passing arg 1 of `Prinam' from incompatible
>
>
> ISO pascal is apparently much more picky about types.
>
> It seems to have gotten rid of the very useful 'equivelent type' and now
> requires 'exact type'.

Doing so eliminated a lot of ambiguity in the language. It was a good
step.

>
> The ISO people back then didn't ask for my advice, so I can't help
> that...[grin]

The ISO 7185 and ANSI meetings were open. No, I didn't go either.

>
>
>>chess0~1.pas: In procedure `Yrmove':
>>chess0~1.pas:3959: warning: `;' after `then'
>>chess0~1.pas:3960: warning: `;' after `then'
>>chess0~1.pas:3961: warning: `;' after `then'
>>chess0~1.pas:3968: warning: `;' after `then'
>>chess0~1.pas:3969: warning: `;' after `then'
>>chess0~1.pas:3970: warning: `;' after `then'
>
>
> Yup.... LSTMOV and YRMOVE do that. Sloppy coding.
>
> Most of the program is written pretty well. Impressively so, considering he
> was basing it on an assembly program. But it does have a few warts.
>
>
>>The following list of non-warning errors from a run of PascalP on
>>it primarily shows failure to declare labels properly. Some of
>
>
> Actually, they did *NOT* fail to declare labels properly.
>
> Remember, they used an original Wirth/Amman compiler.
>
> The rules were different for it. What they did was 100% valid. Otherwise
> they would have done it differently.
>
>
>
>>them are due to the fact that PascalP only keeps 8 chars of
>>identifiers (the line 100 error), and has a maxint of 32767. The
>
>
> I think most 8 bit micros only had 16 bit ints, too.
>
> That is an area where Chess 0.5 is not all that portable.
>
> I don't know if any later issues of Byte had any notes about things like
> that.
>
> I suspect not.
>
> Which is kind of telling, because it suggests that few people managed to
> type it in that tiny printing and get it to work on their particular version
> of Pascal.
>
> I know of two groups (who did Merlin and Shy chess programs), but I doubt
> many others did.
>
> The goto's, the procedural parameters and the very small printing were
> definetly problems.
>
> As I mention in the "why did they choose Pascal" section of my doc, they
> just didn't have many other choices.
>
>
>>PASCALP (pasctext, pasclist, prr, ef, output) [parm] V 3.1.9T
>> 33000 0:D  PZX8 = 16777216; (*
>>2^(ZX-7) *)
>> **** ^100
>>100. Numeric constant exceeds range
>
>
> Not really a problem, because that constant is used only in the CDC specific
> part of the code.
>
> They should have commented that and the RK record out, but they didn't.
>
>
>> 149000 0:D  arraytkoftw = array [tk] of tw;
>> **** ^30
>>30. Identifier declared twice
>
>
> That would be Scott Moore's version....
>
> He's the one who did the ISO modifications.
>
> I don't think his web page points out that distinction, though. It should.
>
>
>>1261000 141: 2 DIV (4*INTI+FTRPWN) DIV
>>262144,16320),MBLTE);
>> **** ^100
>>100. Numeric constant exceeds range
>
>
> There are some areas where I've wondered about integer overflow.
>
> I haven't studied the code that carefully, though.
>
> I figure it works fine with 32+ bit ints, which is what the original
> computer and compiler used.

Actually, it would have been 60 bit integers, see:

http://www.moorecad.com/standardpascal/cdc6400.html

The CDC machines only implemented 48 bits of that on all instructions, so
the integer length was effectively 48 bits.

>
> If I was going to try and do it with an 8 bit, or convert it to C or
> something, then I'd look more closely.
>
>
> Still, as I said above, my interest in it is definetly 'historical'. As
> long as I can make a few relatively simple changes (mentioned in my docs) to
> get it to compile and run with at least one readily available compiler
> (current gpc, in this case), then that's enough.
>
> (True, I would have actually prefered something like P4 or even UCSD.
> Something from that time period. But it didn't work out. So GPC will have
> to do.)
>
> If I was actually going to want to get the program to run well, to actually
> play it, I'd convert it to C, use "unsigned long long", get rid of the 8 and
> 16 bit portability, get rid of a bunch of other stuff. (Basically, rewrite
> it into something Larry Atkin hopefully would have done if he had written it
> today.)
>
>
>
>
> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
> ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 13, 2005 6:53:23 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"Scott Moore"

>> Scott Moore already distributes one that can compile with ISO. I didn't
>> write that one, so I don't know a lot about it.
>
> There were invalid gotos and invalid variable threats still left in the
> "ISO" program I provided. Unfortunately, IP Pascal passed these (invalid
> constructs) as valid. This was pointed out to me by Mr. Stewart of Irie
> Pascal.
> I'm working to correct that now, then I will post a corrected ISO version
> of
> chess.

Well, have fun....

I don't have any way to check for ISO stuff, so I can't do it.

The most I'd want to do would be convert it to run under Turbo Pascal, but
if you start doing that, then you might as well go even further and produce
a 'modern' version of chess 0.5


>> Well, the program was written in 1978... Long before the ISO standard.
>>
>> It was written on an actual Wirth compiler. That's one of the things
>> that
>> makes the program so significant.
>>
>> So realistically, if there's an ISO problem, it's ISO's fault for not
>> adhering to the original Wirth spec...[grin]
>
> Or it may be specific to GPC, as mentioned above.

Nope. If the original compiler accepted it, then you *have* to consider it
as valid Pascal for the time.

The code is correct. It's modern compilers that are 'broken'.


> In general, the ISO 7185 spec clarified the grey areas in Wirth's original
> specification of the language, and Wirth himself checked off on those
> issues, and on the ISO 7185 standard itself. So ISO 7185 is Wirth's
> Pascal.

More like Wirth's Pascal version 2.0

Basically it would mean he broke programs that his own compiler considered
valid.


> The second would be programs that played fast and loose, testing the edge
> of the language. An example would be a goto from inside one block to the
> inside of another.

Well, considering the compiler used for Chess 0.5 *was* the Wirth / Amman
compiler, it's hard to make the argument that the version of Pascal it uses
is invalid.

The goto's in Chess 0.5 were always to an outer block. That's something
every Pascal compiler should be able to handle, since all it requires is
unwiding the stack and actually jumping.

If the standard doesn't allow that, then it's an arbitrary change from the
original Pascal that breaks original working programs.


The Chess 0.5 program is valid Pascal for the time.

If the goto's were a problem (an unintended effect or such), then the
compiler wouldn't have been able to generate code that would have actually
worked. The stack wouldn't have been unwound and so on.

The compiler would have needed to be specifically designed to allow jumps to
outer blocks, because it would have needed to unwind the stack. That had to
be deliberately programmed in.

And since that was the offical Wirth / Amman compiler, that makes the
behavior official.

That makes it valid.

It's modern compilers (and ISO) that's the problem. Not Chess 0.5


> The chess program bent many of the rules of original Pascal to the
> breaking
> point, it has parallel but equivalent types, gotos into different nested

Well... Maybe.

I don't necessarily consider equivalent types to be a failing. I think it's
one of the stupid arbitrary limitations of ISO.

And the goto's are done only into outer blocks. (And they are only done at
all because Pascal doesn't have a macro language. You have to use
subprocedures.) Realistically, no pascal compiler should have a problem
with that. It's not a difficult concept. The fact that the original
compiler could do that says pretty clearly it was specifically designed into
the compiler, and not an accident that it just happened to work.

Realistically, the program is *not* very complex. It's just more than what
ISO Pascal is confortable with.

But they did have major problems converting the Chess 4.5 structure into
Pascal. But they did it. And I bet it compiled with out any warnings on
the original compiler. They wrote the program to the spec of the language
at the time.

They screwed up with the CDC character set dependancy, and it was careless
programming to do semicolons right after a "then", but it's an excellent
example of a chess program of the time. It's excellent programming.

And I bet it compiled without any warnings on the original Pascal compiler
they used.

They were excellent programmers. Their chess programs had a 10 year history
behind it. They wrote Chess 0.5 based on the Pascal spec of the time and
what their compiler could do. They wouldn't have knowingly or willingly
used anything that was suspect.

Since they were using the official Wirth compiler and pascal language def,
Chess 0.5 was written correctly for the time.

Any problems with it is a modern problem, not a Chess 0.5 problem.

That's like complaining that people in 1800's England misspelled words and
had poor grammar, simply because it doesn't match American spelling and
grammar of today.


> statements, undiscriminated variants, etc. It is hardly a normal program
> from that era, and it is hardly suprising that it was difficult to
> standardize.

It is probably more complex.

Larger.

More, well, realistic of a program.

Not some little toy program or 500 line real program.

For the time, that would have been a pretty major program regardless of the
language.


>> It seems to have gotten rid of the very useful 'equivelent type' and now
>> requires 'exact type'.
>
> Doing so eliminated a lot of ambiguity in the language. It was a good
> step.

That's debatable. But let's not actually debate it...[grin]

Let's just say that various people have varying opinions of that, and that
their opinions may not be valid to anybody else, but are valid for
themselves.

>> I haven't studied the code that carefully, though.
>>
>> I figure it works fine with 32+ bit ints, which is what the original
>> computer and compiler used.
>
> Actually, it would have been 60 bit integers, see:

Right, right. I thought of that after I wrote it, so I put 32+ bit ints.

I'd have to actually examine the code carefully to see how many bits it
truely needs.

> http://www.moorecad.com/standardpascal/cdc6400.html

Yup, I've seen it. Interesting.

> The CDC machines only implemented 48 bits of that on all instructions, so
> the integer length was effectively 48 bits.

That I missed. That may have just been load & store stuff. For regular
math operations in registers, it should have been full width.

Awkward size. Still, not as bad as floating point. I've tried porting old
Fortran programs before. Lots of fun.



As I've said before, it would have been nice if I could have provided an
executable done with a compiler of the time. P4 or such.

But, that wasn't possible.

And since the value of the program is *historical* rather than functional,
having one readily available compiler (GPC) be able to handle it is enough.

To me, it doesn't make the slightest bit of difference if it matches with
modern day Pascal standards.




----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 13, 2005 6:53:24 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I Forget wrote:

>>Or it may be specific to GPC, as mentioned above.
>

I was referring to GPCs complaint about with references of packed records,
but that got clipped out of the conversation.

>
> The goto's in Chess 0.5 were always to an outer block. That's something
> every Pascal compiler should be able to handle, since all it requires is
> unwiding the stack and actually jumping.

No, there were several gotos to labels inside nested statements.
>
> If the standard doesn't allow that, then it's an arbitrary change from the
> original Pascal that breaks original working programs.

No, a goto to the inside of a nested statement can easily cause the compiler
to crash. Its an entirely appropriate error.

>
> I don't necessarily consider equivalent types to be a failing. I think it's
> one of the stupid arbitrary limitations of ISO.

It was meant to solve basic ambiguity problems in Pascal. In order to see why
that is, you have to read the standard and understand the concerns that it
addressed.

> They screwed up with the CDC character set dependancy, and it was careless
> programming to do semicolons right after a "then", but it's an excellent
> example of a chess program of the time. It's excellent programming.
>

Why would the CDC character set dependency be any less valid Pascal than the
goto or type equivalence dependencies ? By your logic, we should be emulating
the CDC character set when we run Pascal, then that would be "true" Pascal.


> And I bet it compiled without any warnings on the original Pascal compiler
> they used.
>
> They were excellent programmers. Their chess programs had a 10 year history
> behind it. They wrote Chess 0.5 based on the Pascal spec of the time and
> what their compiler could do. They wouldn't have knowingly or willingly
> used anything that was suspect.

Nobody is debating that. The program ran on CDC. The ISO standard was meant
to make Pascal run on all computers, not just the CDC. The chess program,
which had a fair to more than just a little bit of dependence on the original
CDC implementation was easily brought into compliance with the ISO standard,
and thus made portable, otherwise we'd all be stuck with CDCs being gone and
all. Whats the problem ?

>
> Since they were using the official Wirth compiler and pascal language def,
> Chess 0.5 was written correctly for the time.
>
> Any problems with it is a modern problem, not a Chess 0.5 problem.

And chess ported to modern compilers with little problem. There is no
problem. The system works, ISO works.

Ok, I get it. You don't like ISO Pascal. Thats your decision. Thanks again
for the program.
Anonymous
June 13, 2005 8:40:07 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"Scott Moore"

>> The goto's in Chess 0.5 were always to an outer block. That's something
>> every Pascal compiler should be able to handle, since all it requires is
>> unwiding the stack and actually jumping.
>
> No, there were several gotos to labels inside nested statements.

It is always to a section of code that is at a higher block level or within
the same section.

Sometimes at the end of a routine. Sometimes to the begining of one, and so
on.

Never to just some 'random' spot. There is always some logical connection
(and code flow) between the point they are jumping from to the point they
are jumping to.

>>
>> If the standard doesn't allow that, then it's an arbitrary change from
>> the
>> original Pascal that breaks original working programs.
>
> No, a goto to the inside of a nested statement can easily cause the
> compiler
> to crash. Its an entirely appropriate error.

453: Equivelent to 'return' in C
2460: Forced exit of function. 'return' except from sub-proc.
2479: Same as above.
2491: Jumping to beginning of routine.
2673: Equivelent to 'continue' in C
2677: Basically like 'continue', except skipping one statement.
2682: Plain ordinary goto.
2687: 'continue'
2691: repeat the current block. Ordinary goto.
2699: Simple goto. No stack issues.
2707: exit procedure
2713: 'continue' the while loop
2756: Back up to a parent procedure and start from the beginning.
2813: Back up to a parent procedure and start from the begining.
2795: Back up to a parent procedure and go to the end of it (to exit it)
2984: possibly a problem. Back the stack all the way up to the main
section and then jump.
2991: Possibly a problem. Back the stack all the way up to the main and
then jump.
3008: return from parent procedure.
3062: return from parent procedure
3194: return to parent, start again.
3234: return to grandparent, start again.
3317: return to parent, start again.
3557: a 'continue' for the for statement
3563: exit the procedure

There are no areas that are totally unrelated.

At all times, it jumps up to some parent, or within it's own section (to
overcome limitations of Pascal.)

It's always a logical amount of stack unwinding (when needed at all.)

There is nothing in them that can't be handled.

Yes, a compiler has to know that certain possibilites exist. But they can
be dealt with. After all, that's the whole point of having the label number
at that spot. To tell the compiler that.

I'm not saying that ISO likes the code. It obviously doesn't. I'm saying
that there is nothing there that can't be done reliably, if you choose to do
so.

I'm not saying this is the best code.

A lot of those jumps are obviously due to not having a "macro" ability to do
simple things. And others are to continue a loop, and so on.

It could have been done a bit better, or at least differently.

But there is nothing in there that can't be handled.

The compilers and the standard just choose not to.

>> They screwed up with the CDC character set dependancy, and it was
>> careless
>> programming to do semicolons right after a "then", but it's an excellent
>> example of a chess program of the time. It's excellent programming.
>
> Why would the CDC character set dependency be any less valid Pascal than
> the
> goto or type equivalence dependencies ? By your logic, we should be
> emulating
> the CDC character set when we run Pascal, then that would be "true"
> Pascal.

I didn't mean it wasn't valid.

I was talking portability.

They made an effort to make the program portable and able to run on smaller
computers. But they missed the integer size stuff, and the obvious CDC
specific nature of the character set.

The CDC character set issue wasn't even mentioned in the docs.

Yes, I consider that a screw up.



>> They were excellent programmers. Their chess programs had a 10 year
>> history
>> behind it. They wrote Chess 0.5 based on the Pascal spec of the time and
>> what their compiler could do. They wouldn't have knowingly or willingly
>> used anything that was suspect.
>
> Nobody is debating that. The program ran on CDC. The ISO standard was
> meant
> to make Pascal run on all computers, not just the CDC. The chess program,

It could be argued that at the time the program was written, the compiler it
was written for *was* the definitive, standard Pascal.

It defined the language. Anything else was non-standard.


> which had a fair to more than just a little bit of dependence on the
> original
> CDC implementation was easily brought into compliance with the ISO
> standard,
> and thus made portable, otherwise we'd all be stuck with CDCs being gone
> and
> all. Whats the problem ?

Maybe I'm getting a bit defensive...

I do have a certain fondness for the program, so maybe I"m defending it a
little more than I have to.


> Ok, I get it. You don't like ISO Pascal. Thats your decision. Thanks again
> for the program.

It's not so much that, I guess, as I feel rather defensive.

True, I do feel the ISO standard is worthless, and that they did some very
poor choices. I'd rather code on a regular Pascal compiler. But that's not
the main reason...

It just seems that every time you start pointing out problems with the
program, I get the feeling that you are trying to dismiss the quality of the
programming that the original authors did.

That since the program doesn't compile cleanly with the newer ISO standard,
it has to be 'broken' or poorly or carelessly coded. That the authors made
a mistake or were incompetent, etc.

And since they aren't here to defend themselves, I feel somewhat obligated
to do so, since I am fond of the program.




----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 13, 2005 8:40:08 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I Forget wrote:

>
> It just seems that every time you start pointing out problems with the
> program, I get the feeling that you are trying to dismiss the quality of the
> programming that the original authors did.

Not implying that. I'm adapting it to ISO Pascal because ISO is what Pascal
installations run on now. A non-ISO implementation is certainly interesting
for historical reasons, and I left that on my web site. I am personally
more interested in history that runs, hence the ISO version. Its not meant
to slight the authors, its just what works.

Scott A. Moore
Anonymous
June 14, 2005 7:46:53 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I Forget wrote:
> "Scott Moore"
>
>>> The goto's in Chess 0.5 were always to an outer block. That's
>>> something every Pascal compiler should be able to handle, since
>>> all it requires is unwiding the stack and actually jumping.
>>
>> No, there were several gotos to labels inside nested statements.
>
> It is always to a section of code that is at a higher block level
> or within the same section.
>
> Sometimes at the end of a routine. Sometimes to the begining of
> one, and so on.

The problem in that source is that the labels are not declared.
The LABEL section preceded the CONST section in ISO7185, and should
declare each label in that function. That allows the compiler to
reserve space for linkages, etc. At least it knows, when the GOTO
is executed, howmany static levels it has to unwind.

PROCEDURE foo;
LABEL 10;
PROCEDURE bar;
LABEL 20;
BEGIN
IF baz goto 10;
IF fie goto 20;
fum;
20: foe;
END;
BEGIN (* foo *)
gevault();
10: geharget();
bar;
END;

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Anonymous
June 14, 2005 7:46:54 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

CBFalconer wrote:
> I Forget wrote:
>
>>"Scott Moore"
>>
>>
>>>>The goto's in Chess 0.5 were always to an outer block. That's
>>>>something every Pascal compiler should be able to handle, since
>>>>all it requires is unwiding the stack and actually jumping.
>>>
>>>No, there were several gotos to labels inside nested statements.
>>
>>It is always to a section of code that is at a higher block level
>>or within the same section.
>>
>>Sometimes at the end of a routine. Sometimes to the begining of
>>one, and so on.
>
>
> The problem in that source is that the labels are not declared.
> The LABEL section preceded the CONST section in ISO7185, and should
> declare each label in that function. That allows the compiler to
> reserve space for linkages, etc. At least it knows, when the GOTO
> is executed, howmany static levels it has to unwind.
>
> PROCEDURE foo;
> LABEL 10;
> PROCEDURE bar;
> LABEL 20;
> BEGIN
> IF baz goto 10;
> IF fie goto 20;
> fum;
> 20: foe;
> END;
> BEGIN (* foo *)
> gevault();
> 10: geharget();
> bar;
> END;
>

Where in the chess program was there an undeclared label ? I can't
find it.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Good does not always win. But good is more patient.
June 14, 2005 9:37:22 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

In <HOCdnZWej9D7gzDfRVn-iQ@comcast.com>,
Scott Moore <samiam@moorecad.com> wrote:

> >>> The follow list of errors are from a run of GPC20021128/gcc-3.2.1
> >>>
> >>> [1] c:\p\src\chess05>gpc chess0~1.pas
> >>> chess0~1.pas: In procedure `Inisyn':
> >>> chess0~1.pas:674: warning: ISO Pascal forbids this use of packed
> >>> record fields
> >>
> >> This refers to the idea that "with" establishes a variable reference
> >> to a component of a record, and that can't occur in the case of a
> >> packed record.
> >>
> >> That sure sounds sensible, but I'll be darned if I can find any
> >> reference to it in the ISO 7185 standard. Anyone ?

I think it's valid, and this warning was wrong.

In <d8kisu$b74$1@news1nwk.SFbay.Sun.COM>,
Scott Moore <samiamsansspam@Sun.COM> wrote:

> > "CBFalconer" <cbfalconer@yahoo.com> wrote in message
> > news:42ACB917.39442342@yahoo.com...
> >
> > Hmmm... I used the djgpp version:
> > D:\BChess>gpc -v
> > Reading specs from f:/djgpp/lib/gcc-lib/djgpp/3.23/specs
> > Configured with: /djgpp/b/gnu/gcc-3.23/configure
> > i586-pc-msdosdjgpp --prefix=/de
> > v/env/DJDIR --disable-nls --enable-languages=pascal --enable-checking
> > Thread model: single
> > gpc version 20041218, based on gcc-3.2.3
> >
> > About 2 years newer than yours.
>
> Humm, then perhaps the "with packed record" complaint from GCC was removed
> in later compilers.

At least in the invalid case (I hope ;-). I think it was fixed
together with some other incorrect errors about packed arrays and
records on 2004-02-10 (which falls between yours and Chuck's version
indeed).

>> chess0~1.pas: In procedure `Yrmove':
>> chess0~1.pas:3959: warning: `;' after `then'
>> chess0~1.pas:3960: warning: `;' after `then'
>> chess0~1.pas:3961: warning: `;' after `then'
>> chess0~1.pas:3968: warning: `;' after `then'
>> chess0~1.pas:3969: warning: `;' after `then'
>> chess0~1.pas:3970: warning: `;' after `then'
>
> Warnings. Gotta love em. Not going to fix those personally :-)

In this program, these semicolons are intentional. Fine. (Often,
they're mistaken and make hard to find bugs, so I prefer to let the
compiler tell me, but of course, only by a warning that can be
turned off or ignored.)

In <42adfe28$1_2@spool9-west.superfeed.net>,
I Forget <No@spam.please> wrote:

> "Scott Moore"
>
> >> The goto's in Chess 0.5 were always to an outer block. That's something
> >> every Pascal compiler should be able to handle, since all it requires is
> >> unwiding the stack and actually jumping.
> >
> > No, there were several gotos to labels inside nested statements.
>
> It is always to a section of code that is at a higher block level or within
> the same section.
>
> Sometimes at the end of a routine. Sometimes to the begining of one, and so
> on.
>
> Never to just some 'random' spot. There is always some logical connection
> (and code flow) between the point they are jumping from to the point they
> are jumping to.

Actually, my current version of GPC finds just one invalid goto:

> 2699: Simple goto. No stack issues.

(The first goto 13.)

It jumps into the else-part of an if-statement. Stack issues aren't
actually the main point; while- and repeat-loops normally have no
stack issues either, as Pascal doesn't allow variable declarations
within loops, and all temporaries that might need stack space can
occur either within a statement in the loop or during evaluation of
the loop condition, not between statements in the loop, where labels
can be placed. for-loops do need extra storage for the final bound,
but of fixed size, so depending on the allocation mechanism, they
could also be done without stack fixups.

A goto into a for-loop is clearly nonsensical. For other structured
statements, one could argue. ISO just doesn't allow such gotos into
structured statements -- you'll probably disagree. It would probably
be rather easy to get rid of this one goto (at least I suppose so --
the control flow in this area is rather confusing to me, I'd have to
study it more carefully, and since you won't care, I won't bother
to ;-).

In <42AE4C5A.E6814B95@yahoo.com>,
CBFalconer <cbfalconer@yahoo.com> wrote:

> > Sometimes at the end of a routine. Sometimes to the begining of
> > one, and so on.
>
> The problem in that source is that the labels are not declared.

All labels are declared. GPC doesn't accept undeclared labels (and
it does accept the modified program, and the modifications don't
include adding label declarations).

Frank

--
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Pascal code, BP CRT bugfix: http://fjf.gnu.de/programs.html
Free GNU Pascal Compiler: http://www.gnu-pascal.de/
Anonymous
June 14, 2005 3:52:23 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"Scott Moore"
>
>> It just seems that every time you start pointing out problems with the
>> program, I get the feeling that you are trying to dismiss the quality of
>> the
>> programming that the original authors did.
>
> Not implying that. I'm adapting it to ISO Pascal because ISO is what
> Pascal
> installations run on now. A non-ISO implementation is certainly
> interesting
> for historical reasons, and I left that on my web site. I am personally
> more interested in history that runs, hence the ISO version. Its not meant
> to slight the authors, its just what works.

That is indeed a reasonable position.

I guess I've been a bit too defensive about the program.

I'm sorry.




----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 14, 2005 5:25:07 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

Scott Moore wrote:
>
.... snip ...
>
> Where in the chess program was there an undeclared label ? I can't
> find it.

My mistake. PascalP doesn't allow goto out of procedures, so
ignores declarations in encompassing scopes. That made it look
like an undeclared error.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Anonymous
June 14, 2005 11:14:13 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"I Forget" <No@spam.please> skrev i meddelandet
news:42adfe28$1_2@spool9-west.superfeed.net...
> "Scott Moore"
>
>>> The goto's in Chess 0.5 were always to an outer block. That's
>>> something
>>> every Pascal compiler should be able to handle, since all it
>>> requires is
>>> unwiding the stack and actually jumping.
>>
>> No, there were several gotos to labels inside nested statements.
>
> It is always to a section of code that is at a higher block level or
> within the same section.
>
> Sometimes at the end of a routine. Sometimes to the begining of one,
> and so
> on.
>
> Never to just some 'random' spot. There is always some logical
> connection (and code flow) between the point they are jumping from to
> the point they are jumping to.
>

And it is also possible to reflect this code flow using boolean
variables, and remove the gotos. I did that once, 20 years ago. If I
could just find those 8 inch floppies again...


Bo Persson
Anonymous
June 14, 2005 11:14:14 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"Bo Persson"

> And it is also possible to reflect this code flow using boolean variables,
> and remove the gotos. I did that once, 20 years ago. If I

Yeah.

Most of the changes aren't hard. Just tedious. And cause bloating and loss
of readability.

> could just find those 8 inch floppies again...

You actually typed it in??!

Wow! Congratulations.

What system were you using? Compiler?




----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 15, 2005 12:27:32 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"I Forget" <No@spam.please> skrev i meddelandet
news:42af17be$1_1@spool9-west.superfeed.net...
> "Bo Persson"
>
>> And it is also possible to reflect this code flow using boolean
>> variables, and remove the gotos. I did that once, 20 years ago. If I
>
> Yeah.
>
> Most of the changes aren't hard. Just tedious. And cause bloating
> and loss of readability.
>
>> could just find those 8 inch floppies again...
>
> You actually typed it in??!
>
> Wow! Congratulations.
>
> What system were you using? Compiler?

It was a very state-of-the-art 4 MHz Z80, with a full 64k of RAM,
running CP/M 2.2. :-)

Some of the other guys had built it, so we could use it for software
development. On rainy sundays, I could use it for trying out this chess
program. A home computer was just a dream in the early 80's.

I tried the Pascal compilers we had available. Turbo Pascal didn't have
a chance. It compiled fast, but the resulting code wasn't. :-)

Either Pascal/Z or Pascal MT+ (whatever that meant) was able to overlay
the program, so it would fit in the 64k memory. Part 1 would initialize
the variables, part 2 would do the search, and part 3 would report the
result and redraw the board.


I also remember that the CDC specific code is in there for a reason.
Replacing the generic code with something machine specific, doubled the
speed of the program!


Bo Persson
Anonymous
June 15, 2005 12:27:33 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"Bo Persson"

> It was a very state-of-the-art 4 MHz Z80, with a full 64k of RAM, running
> CP/M 2.2. :-)

Not too shabby. Of course, my cpu was better than yours, and my daddy can
beat up your daddy, and all the traditional challenges and barbs that went
on at the time...[grin]

I got my first one in 82. 16k of memory.

I waited about a year before I got mine.

I didn't get a compiler until later. Pascal, of course. When I got a
floppy disk drive. Until that time, I made do with Basic and assembly
language, and a cassette tape for storage. (At least I missed the paper
tape days!)

> I tried the Pascal compilers we had available. Turbo Pascal didn't have a
> chance. It compiled fast, but the resulting code wasn't. :-)

What... no p-code based ucsd...[grin] Somehow I don't think it would have
played chess well. Still, that was one of the 'recommended' compilers that
the Byte editors suggested.

Actually though, for the time, TurboPascal was impressive. Not in the
quality of the code, but in the user friendly-ness.


Actually though, I *would* like to get the Chess 0.5 program up and running
on some compiler of the period. Like P4 or UCSD. Just for the nostalgia, I
guess.

> Either Pascal/Z or Pascal MT+ (whatever that meant) was able to overlay
> the program, so it would fit in the 64k memory. Part 1 would initialize
> the variables, part 2 would do the search, and part 3 would report the
> result and redraw the board.

Useful.

I don't know how much space the program really takes up, or how much data.

> I also remember that the CDC specific code is in there for a reason.
> Replacing the generic code with something machine specific, doubled the
> speed of the program!


Oh yeah. It would have been even faster if some stuff could have been done
differently, instead of as procedures.

Of course, the article didn't mention that the keyboard handling stuff was
cdc specific. They should have at least indicated what areas would need to
be changed.

Maybe they just missed that part when writing the docs.


Anyway, congratulations on being one of the very few people to actually type
it in back then!

If, by some chance, you could get your hands on the original program on your
8" disks, I would like to see it. Both for the changes you made, and just
for the fact that it was typed in and actually ran back then.





----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 17, 2005 6:15:47 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I just thought I'd let people know that I have found an actual bug in the
version of Chess 0.5 that I OCR'ed. The problem is the OCR, not the
original.

In function RDRNUM, the variable INTI should be type TI. The scanned
version has TL.

I thought the type checking in GPC, FreePascal, and TurboPascal had caught
most of them, but that one slipped through.

With the variable of just TL, numbers would be limited to 119. Assuming the
compiler generated code that even noticed. (I caught this with
TurboPascal's 'range check' option.)

The type TL is a subrange of 0..119, where as type TI is a regular INTEGER.

There may yet be more problems like this, but if so, the compilers aren't
going to tell you. I don't know of any 'LINT' style program to check a
Pascal program for nit-picking details.



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 18, 2005 12:50:15 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I Forget wrote:

> There may yet be more problems like this, but if so, the compilers aren't
> going to tell you. I don't know of any 'LINT' style program to check a
> Pascal program for nit-picking details.

I would be redundant. Pascal already checks programs to better than
"lint" standards. For instance, the range check as you described, which
is a capability that doesen't exist on C.

Will change the error you listed in the online copy.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Good does not always win. But good is more patient.
Anonymous
June 18, 2005 3:23:51 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"Scott Moore"
>I Forget wrote:
>
> I would be redundant. Pascal already checks programs to better than
> "lint" standards.

Not any of the Pascal compilers that I have access to.

GPC sure as expletive didn't. Neither did TurboPascal.

FPC 2 might, but I haven't tried it with the new 'TurboPascal' version since
I'm still debugging it. (And to be honest, I don't really want to use
FPC2.... My previous experience wasn't fun. And the new optional IDE has
colors so bad I can barely see it. And you can't change the colors...)

My experience with GPC has definetly convienced me that it's not a good
compiler. It's letting too many things slide past. Even if you tell it to
do all warnings and to do just iso. Maybe the DJGPP version I have has
problems... Dunno. (Considering GPC is free, then I guess the price is
right....)

I've been tempted to go dig out my old 8 bit p-code compiler. It's nearly
ISO. But it's on a 5.25" floppy.


Your compiler didn't catch it, either. I checked your ISO version.

Since you were doing ISO that should have been a fatal error and not just a
warning. Just like the other stuff.

You fixed a lot of other ISO stuff, but that one slipped through.


> "lint" standards. For instance, the range check as you described, which
> is a capability that doesen't exist on C.

Sure it does. Most compilers don't bother. But yes, it's possible.

What you really mean is that it would be of limited use, since C only has
enum and bitfields and doesn't have subrange types.

But there are lots of run time checks that can be done, if the compiler
writer wants to. Most don't.




----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 18, 2005 3:23:52 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

I Forget wrote:

> "Scott Moore"
>
>>I Forget wrote:
>>
>>I would be redundant. Pascal already checks programs to better than
>>"lint" standards.
>
>
> Not any of the Pascal compilers that I have access to.
>
> GPC sure as expletive didn't. Neither did TurboPascal.

Since Turbo Pascal does find it with rangecheck on, what where you
referring to, as in a problem that "lint" would find, that Pascal
compilers do not ?


> Your compiler didn't catch it, either. I checked your ISO version.
>
> Since you were doing ISO that should have been a fatal error and not just a
> warning. Just like the other stuff.
>
> You fixed a lot of other ISO stuff, but that one slipped through.

I never ran the program.

As previously mentioned, I compiled, but didn't get chess05 to run.
It died with runtime error, and my time to work on that ran out, I plan
to look at it again.

I checked, ISO Pascal has rangechecking (as well as most other errors)
on by default, so, yes, it would have found that (if the program had
run farther.

--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Good does not always win. But good is more patient.
June 18, 2005 10:46:29 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

In comp.lang.pascal.misc I Forget <No@spam.please> wrote:
> "Scott Moore"
>>
>> I would be redundant. Pascal already checks programs to better than
>> "lint" standards.
>
> Not any of the Pascal compilers that I have access to.
>
> GPC sure as expletive didn't. Neither did TurboPascal.
>
> My experience with GPC has definetly convienced me that it's not a good
> compiler. It's letting too many things slide past. Even if you tell it to
> do all warnings and to do just iso. Maybe the DJGPP version I have has
> problems... Dunno. (Considering GPC is free, then I guess the price is
> right....)

First you get defensive about "your" program very easily, and now
you're spreading insults, nice style, man!

I guess further discussion with you is pointless, but just for the
record, which "many" things let it slide past? According to the
logs others posted, it caught quite a few things, including some
that were too strict for this program, such as threatened for-loop
counters (according to ISO) or dangerous semicolons (independent of
ISO).

You mentioned this real division by zero, ok that's one (exotic)
problem. You can blame GPC for not catching it, and at the same time
blame the original authors for writing such broken code.

Assigning a subrange to a full integer? It's surely valid as Scott
pointed out. Just because not every equivalent typing of the
original program is valid ISO, doesn't mean that ISO doesn't have
certain assignment-compatibility rules. Obviously the original
compiler allows this as well, and so does probably every Pascal (or
similar) compiler. Are you making up a problem here because you
can't get over it that your beloved program's equivalent typing is
not supported by ISO?

> > "lint" standards. For instance, the range check as you described, which
> > is a capability that doesen't exist on C.
>
> Sure it does. Most compilers don't bother. But yes, it's possible.
>
> What you really mean is that it would be of limited use, since C only has
> enum and bitfields and doesn't have subrange types.

Nope. Arrays in C are treated as pointers, so e.g. a function
usually has no information about the size of an array used as an
actual parameter, so no automated checks are possible.

> But there are lots of run time checks that can be done, if the compiler
> writer wants to. Most don't.

Nope again. Many runtime checks would actually be illegal in C.
(If you want to know for sure, post your proposals to comp.lang.c
and count the number of flames you get. ;-)

Frank

--
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Pascal code, BP CRT bugfix: http://fjf.gnu.de/programs.html
Free GNU Pascal Compiler: http://www.gnu-pascal.de/
Anonymous
June 18, 2005 1:49:31 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

In comp.lang.pascal.misc I Forget <No@spam.please> wrote:
> "Scott Moore"
>>I Forget wrote:
>>
>> I would be redundant. Pascal already checks programs to better than
>> "lint" standards.
>
> Not any of the Pascal compilers that I have access to.
>
> GPC sure as expletive didn't. Neither did TurboPascal.
>

As others noted the construct you mention (assigning subrange to integer)
is legal Pascal (and is used quite a lot).

Finding out which constructs are errors and which are intentional
is a *hard* problem. AFAIK GPC is doing more checks that traditional
"lint" did. Of course, you may wish for better checking. But with
added checks the number of false positives grows much faster then
number of true errors (did I wrote it is hard :) .

> My experience with GPC has definetly convienced me that it's not a good
> compiler. It's letting too many things slide past. Even if you tell it to
> do all warnings and to do just iso. Maybe the DJGPP version I have has
> problems... Dunno. (Considering GPC is free, then I guess the price is
> right....)
>

FYI the newest GPC is doing range checking (but I did not run the program
enough to find problems). And it found jumps breaking ISO rules that your
version missed.

In may experience porting a few programs to GPC it found problems in
all programs (either breaking language rules or plain bugs). And that
were all "working" programs accepted by other compilers.

Until recently GPC did not implement run time checks, but that is changing:
range checking is fully implemented and other checks (including overflow
checks) are coming.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl
Anonymous
June 18, 2005 1:49:48 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

Since you indicated that you didn't recieve this, I reposted it.

Scott Moore wrote:

> I Forget wrote:
>
>> "Scott Moore"
>>
>>> I Forget wrote:
>>>
>>> I would be redundant. Pascal already checks programs to better than
>>> "lint" standards.
>>
>>
>>
>> Not any of the Pascal compilers that I have access to.
>>
>> GPC sure as expletive didn't. Neither did TurboPascal.
>
>
> Since Turbo Pascal does find it with rangecheck on, what where you
> referring to, as in a problem that "lint" would find, that Pascal
> compilers do not ?
>
>
>> Your compiler didn't catch it, either. I checked your ISO version.
>>
>> Since you were doing ISO that should have been a fatal error and not
>> just a warning. Just like the other stuff.
>>
>> You fixed a lot of other ISO stuff, but that one slipped through.
>
>
> I never ran the program.
>
> As previously mentioned, I compiled, but didn't get chess05 to run.
> It died with runtime error, and my time to work on that ran out, I plan
> to look at it again.
>
> I checked, ISO Pascal has rangechecking (as well as most other errors)
> on by default, so, yes, it would have found that (if the program had
> run farther.
>


--
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Good does not always win. But good is more patient.
Anonymous
June 18, 2005 2:46:23 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

"Waldek Hebisch"
>
> As others noted the construct you mention (assigning subrange to integer)
> is legal Pascal (and is used quite a lot).

Apparently I haven't gotten most of those messages on this news server.

> Finding out which constructs are errors and which are intentional
> is a *hard* problem. AFAIK GPC is doing more checks that traditional

That's why a LINT program goes beyond what is or is not legal.

> "lint" did. Of course, you may wish for better checking. But with
> added checks the number of false positives grows much faster then
> number of true errors (did I wrote it is hard :) .

I've used LINT's before.

Yes, they can indeed cause problems. But they can also catch quite a few,
too.

They are more difficult with large single file programs, but things are much
more managable while the program is divided into smaller units.

Normally, I wouldn't use LINT. But since this is an old program, written
for a compiler that allows no telling what, it would come in handy.

If GPC gave me that kind of stuff, then it might be good enough. But it's
not.


> FYI the newest GPC is doing range checking (but I did not run the program
> enough to find problems). And it found jumps breaking ISO rules that your
> version missed.

Well, I did clearly say that it might be the DJGPP version I was using.

But since that's all that is available to me, that's what I have to keep
using.


> Until recently GPC did not implement run time checks, but that is
> changing:
> range checking is fully implemented and other checks (including overflow
> checks) are coming.

I'm not normally a fan of range checks of stuff...

A good, well tested program doesn't need them and they are too slow.

But they sure can help with debugging. That's why I turned them on in
TurboPascal.



PS: if this is going to turn into mostly Pascal discussion, then we need to
remove rec.games.chess.computer from the newsgroup list...



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 18, 2005 2:50:26 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

<frank@g-n-u.de> wrote in message
news:42b3c345$0$27776$9b4e6d93@newsread2.arcor-online.net...

>> My experience with GPC has definetly convienced me that it's not a good
>> compiler. It's letting too many things slide past. Even if you tell it
>> to
>> do all warnings and to do just iso. Maybe the DJGPP version I have has
>> problems... Dunno. (Considering GPC is free, then I guess the price is
>> right....)
>
> First you get defensive about "your" program very easily, and now
> you're spreading insults, nice style, man!

> I guess further discussion with you is pointless, but just for the
> record, which "many" things let it slide past? According to the

According to Scott, there is a lot of loose type checking going on.

The program uses equivelence type checking, but ISO requires strict type
checking.

GPC does *not* catch *any* of those type checking issues, even with warnings
at highest and explicitly telling the program to do ISO.

That's why *he* did an ISO version.... GPC that I was using was letting all
those issues slide by.

Since he's the ISO expert in here, if you have a problem with that, I
suggest you go take it up with him. I'm just accepting what he has
repeatedly said as being true.


Again, maybe it's just the version of DJGPP GPC that I'm using. I don't
know. I have no way of knowing.

> logs others posted, it caught quite a few things, including some
> that were too strict for this program, such as threatened for-loop
> counters (according to ISO) or dangerous semicolons (independent of
> ISO).

When I compile the program, I get the following warnings. And *only* the
following warnings.

chess05.pas: In procedure `INICON':
chess05.pas:733: warning: `for' loop counter is threatened in a subroutine
chess05.pas: In procedure `LSTMOV':
chess05.pas:2084: warning: `;' after `then'
chess05.pas: In procedure `BOACMD':
chess05.pas:2853: warning: `for' loop counter is threatened in a subroutine
chess05.pas:2873: warning: `for' loop counter is threatened in a subroutine
chess05.pas: In procedure `YRMOVE':
chess05.pas:3877: warning: `;' after `then'
chess05.pas:3878: warning: `;' after `then'
chess05.pas:3879: warning: `;' after `then'
chess05.pas:3886: warning: `;' after `then'
chess05.pas:3887: warning: `;' after `then'
chess05.pas:3888: warning: `;' after `then'

Those are just minor warnings about possible programming errors.

It doesn't complain about the GOTOs, or the types or anything else.

According to others, there should be other warnings or even fatal errors.
But I'm not seeing them.

Maybe it's the DJGPP version I'm using. I don't know.


If there had been any other significant issues, I would have provided fixes
for them before I posted the notice about BYTE Chess 0.5 being available.

Since I'm not seeing those issues (like everybody else is, apparently), then
I can't fix them.

The chess program is important to me. Being able to tell people how to
compile and run it is important to me. I was willing to accept that only
GPC could compile it, but now it appears that only the DJGPP version of GPC
can compile it. Other versions of GPC apparently can't because they are
apparently seeing warnings and errors that my version isn't.


> You mentioned this real division by zero, ok that's one (exotic)
> problem. You can blame GPC for not catching it, and at the same time

I wouldn't call division by zero to be all that exotic.


> Assigning a subrange to a full integer? It's surely valid as Scott
> pointed out. Just because not every equivalent typing of the

I haven't seen that message from him, so I can't comment on that.

(Scott.... if you said anything significantly important, please repost it...
My news server didn't see it.)

However, as I did say in the message, it might indeed be valid. But that a
LINT style program goes beyond what is or is not legal. A LINT style
program looks what might be wrong, not what is wrong and will be caught by
the compiler.

> similar) compiler. Are you making up a problem here because you
> can't get over it that your beloved program's equivalent typing is
> not supported by ISO?

[snort] Grow up.

> Nope. Arrays in C are treated as pointers, so e.g. a function
> usually has no information about the size of an array used as an
> actual parameter, so no automated checks are possible.

There have been compilers (and c interpreters) that have done it!

When you've got an array defined as being from -83 to 115 and you later
access the array (as an array, not via pointer), then yes, the compiler (or
itnerpreter) most certainly can check it.

Technically, even many pointer operations can be checked, although that is
harder.

Yes, because of the flexibility of the language, a lot of things can't be
checked. But many can.

I've been using C for maybe 20 years. This may come as a shock to you, but
I do actually happen to know a few things.



PS: if this is going to turn into mostly Pascal discussion, then we need to
remove rec.games.chess.computer from the newsgroup list...



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Anonymous
June 18, 2005 6:29:11 PM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

Waldek Hebisch wrote:
>
.... snip ...
>
> As others noted the construct you mention (assigning subrange to
> integer) is legal Pascal (and is used quite a lot).

As is the reverse, where range checking is needed to catch errors.
For example:

TYPE limited = 1..10;
VAR a : limited; b : integer;

....
FOR b := 1 TO 11 DO a := b;

will cause a fault on the 11th iteration at run-time. Many systems
will miss it. The only place to catch this is at the actual
assignment.

>
.... snip ...
>
> Until recently GPC did not implement run time checks, but that is
> changing: range checking is fully implemented and other checks
> (including overflow checks) are coming.

Which will be a great relief. The other thing I am hoping for is
to mesh with gcc above 3.3 in DJGPP versions.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
June 19, 2005 12:38:08 AM

Archived from groups: comp.lang.pascal.misc,rec.games.chess.computer (More info?)

In <42b443d8$1_2@spool9-west.superfeed.net>,
I Forget <No@spam.please> wrote:

> > I guess further discussion with you is pointless, but just for the
> > record, which "many" things let it slide past? According to the
>
> According to Scott, there is a lot of loose type checking going on.
>
> The program uses equivelence type checking, but ISO requires strict type
> checking.
>
> GPC does *not* catch *any* of those type checking issues, even with warnings
> at highest and explicitly telling the program to do ISO.

I suppose you're mixing things up. (Understandable after such a long
process, but it's not ok to spread false accusations based on your
mistake.) You said you made only the changes necessary to compile it
with GPC, and you changed the equivalent types (points 3-9 in your
list), so apparently GPC did catch them. (I just rechecked with
20041218, and it does.) For reference, these were such errors:

Chess05.pas:3108: error: passing arg 1 of `PRINTB' from incompatible array

> Since he's the ISO expert in here, if you have a problem with that,

I don't have a problem with him or with ISO, I have a problem with
you.

> > logs others posted, it caught quite a few things, including some
> > that were too strict for this program, such as threatened for-loop
> > counters (according to ISO) or dangerous semicolons (independent of
> > ISO).
>
> When I compile the program, I get the following warnings. And *only* the
> following warnings.
>
> chess05.pas: In procedure `INICON':
> chess05.pas:733: warning: `for' loop counter is threatened in a subroutine
> chess05.pas: In procedure `LSTMOV':
> chess05.pas:2084: warning: `;' after `then'
> chess05.pas: In procedure `BOACMD':
> chess05.pas:2853: warning: `for' loop counter is threatened in a subroutine
> chess05.pas:2873: warning: `for' loop counter is threatened in a subroutine
> chess05.pas: In procedure `YRMOVE':
> chess05.pas:3877: warning: `;' after `then'
> chess05.pas:3878: warning: `;' after `then'
> chess05.pas:3879: warning: `;' after `then'
> chess05.pas:3886: warning: `;' after `then'
> chess05.pas:3887: warning: `;' after `then'
> chess05.pas:3888: warning: `;' after `then'

Which version? The original one? Apparently not, since the charset
problems would show in the messages. Your patched-for-GPC one, or
Scott's ISO version? Both have the equivalent-types fixed already,
see above.

> Maybe it's the DJGPP version I'm using. I don't know.
>
> The chess program is important to me. Being able to tell people how to
> compile and run it is important to me. I was willing to accept that only
> GPC could compile it, but now it appears that only the DJGPP version of GPC
> can compile it. Other versions of GPC apparently can't because they are
> apparently seeing warnings and errors that my version isn't.

It's nothing to do with DJGPP. It's true that newer versions catch a
few more things (such as the gotos). By default, they will be
warnings in the upcoming version, only in strict ISO mode they are
errors. Since you don't care about ISO, you won't want to use ISO
mode, i.e. compile with `--gnu-pascal' (as noted in your list), or
actually without any dialect option since this is the default. Then
you'll get a few more warnings which you will ignore, so it actually
won't make a difference.

> > similar) compiler. Are you making up a problem here because you
> > can't get over it that your beloved program's equivalent typing is
> > not supported by ISO?
>
> [snort] Grow up.

Sure.

> There have been compilers (and c interpreters) that have done it!
>
> When you've got an array defined as being from -83 to 115 and you later
> access the array (as an array, not via pointer), then yes, the compiler (or
> itnerpreter) most certainly can check it.
>
> I've been using C for maybe 20 years. This may come as a shock to you, but
> I do actually happen to know a few things.

With the emphasis on few, I suppose. FYI, all arrays in C are
0-based. Talking about an array from -83 to 115 in C doesn't really
look like you know what you're talking about.

And again, arrays are treated as pointers in C very often, in
particular whenever they're passed as parameters.

Frank

--
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Pascal code, BP CRT bugfix: http://fjf.gnu.de/programs.html
Free GNU Pascal Compiler: http://www.gnu-pascal.de/
!