Update for Byte Chess 0.5
I Forget
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 =----
CBFalconer
>
> 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
Scott Moore
> 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
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 ?
===================================================================================
The standard says:
6.8.3.10 With-statements
with-statement = 'with' record-variable-list 'do' statement .
record-variable-list = record-variable f ',' record-variable g .
eld-designator-identi er = identi er .
A with-statement shall specify the execution of the statement of the with-statement. The occurrence
of a record-variable as the only record-variable in the record-variable-list of a with-statement shall
58
ISO/IEC 7185:1990(E)
constitute the de ning-point of each of the eld-identi ers associated with components of the
record-type possessed by the record-variable as a eld-designator-identi er for the region that is the
statement of the with-statement; each applied occurrence of a eld-designator-identi er shall denote
that component of the record-variable that is associated with the eld-identi er by the record-type.
The record-variable shall be accessed before the statement of the with-statement is executed, and
that access shall establish a reference to the variable during the entire execution of the statement of
the with-statement.
The statement
with v1,v2,...,vn do s
shall be equivalent to
with v1 do
with v2 do
...
with vn do s
Example:
with date do
if month = 12 then
begin month := 1; year := year + 1
end
else month := month+1
has the same e ect on the variable date as
if date.month = 12 then
begin date.month := 1; date.year := date.year+1
end
else date.month := date.month+1
===================================================================================
Tends to imply that it is ok, because it states "equvalence" in the form of valid
assignments that would work regardless of the packed status.
> 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
Yes, thats a CDC character set dependency :-(
You have to give it to GPC, it checks pretty well.
Couple of these:
> 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
Thats a problem. I think that also failed Stewards Irie Pascal,
if I recall. No clue why IP Pascal passed on it.
> 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 :-)
--
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.
Scott Moore
Scott Moore wrote:
> CBFalconer wrote:
>
>> 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
>
>
> 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 ?
>
> ===================================================================================
>
> The standard says:
>
> 6.8.3.10 With-statements
> with-statement = 'with' record-variable-list 'do' statement .
> record-variable-list = record-variable f ',' record-variable g .
> field-designator-identifier = identifier .
> A with-statement shall specify the execution of the statement of the
> with-statement. The occurrence
> of a record-variable as the only record-variable in the
> record-variable-list of a with-statement shall
> 58
> ISO/IEC 7185:1990(E)
> constitute the defining-point of each of the field-identi ers associated
> with components of the
> record-type possessed by the record-variable as a
> field-designator-identi er for the region that is the
> statement of the with-statement; each applied occurrence of a
> field-designator-identi er shall denote
> that component of the record-variable that is associated with the
> field-identi er by the record-type.
Scott Moore
puts a special character in when it means "cannot recognize", and apparently
they managed to pick one that drives newsreaders wild, so they must be removed.
Scott Moore wrote:
>> constitute the defining-point of each of the field-identifiers
>> associated with components of the
>> record-type possessed by the record-variable as a
>> field-designator-identifier for the region that is the
>> statement of the with-statement; each applied occurrence of a
>> field-designator-identifier shall denote
>> that component of the record-variable that is associated with the
>> field-identifier by the record-type.
>> The record-variable shall be accessed before the statement of the
>> with-statement is executed, and
>> that access shall establish a reference to the variable during the
>> entire execution of the statement of
>> the with-statement.
>> The statement
>> with v1,v2,...,vn do s
>> shall be equivalent to
>> with v1 do
>> with v2 do
>> ...
>> with vn do s
>> Example:
>> with date do
>> if month = 12 then
>> begin month := 1; year := year + 1
>> end
>> else month := month+1
>> has the same efiect on the variable date as
I Forget
news:42ACB917...@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.)
Scott Moore
> "CBFalconer" <cbfal...@yahoo.com> wrote in message
> news:42ACB917...@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.
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.
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.
I Forget
>> 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.
Scott Moore
>>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.
I Forget
>> 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.
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.
Scott A. Moore
Dr John Stockton
04:10:01, seen in news:comp.lang.pascal.misc, CBFalconer
<cbfal...@yahoo.com> posted :
>
>"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
It's been suggested that some views of Google give proper quoting with
"Reply"; it may depend on user's apparent location.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
CBFalconer
> "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;
Scott Moore
Where in the chess program was there an undeclared label ? I can't
find it.
fr...@g-n-u.de
Scott Moore <sam...@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 <samiams...@Sun.COM> wrote:
> > "CBFalconer" <cbfal...@yahoo.com> wrote in message
> > news:42ACB917...@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...@spool9-west.superfeed.net>,
I Forget <N...@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...@yahoo.com>,
CBFalconer <cbfal...@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, fr...@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/
CBFalconer
>
... 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.
I Forget
> I Forget <N...@spam.please> wrote:
>
> 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.
Well... I'm not going to argue the point because...
1) You and Scott do know more about ISO than I do.
2) As I have admitted to Scott, I have been a bit too defensive about Chess
0.5
Still, that's only one goto causing problems....
> 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 ;-).
That routine is doing a poor man's recursion. But instead of doing it based
on depth etc., they are keeping track of the number of nodes visited.
I don't know why they chose that particular style.
1) Stack issues on the cdc?
2) Stack issues with Pascal on the cdc?
3) Stack issues on potential new machines (ie: portability to 8 bit micros
with limited stack)
4) They are doing it specifically that way to use the number of nodes
searched as a time control mechanism, since they may not have had a 'clock'
function.
5) The original assembly program was done that way for some particular
reason (or was done so in an earlier version and was just left that way
because it was easier than rewriting it.)
I admit I have no use for ISO pascal.
But, I wouldn't be oposed to helping convert Chess 0.5 to run under some
other compiler of the period. Perhaps the P4 compiler? UCSD?
I don't know enough about either of them to know what limitations exist,
etc. Or even where to get a copy of UCSD...
I'm familiar enough with the program that most of the changes would be
rather easy.
I'm pretty sure the variant records could be removed.
I'm pretty sure the set stuff could be removed (if needed)
Most of the goto's could be removed. It would require some rearrangment or
a little code bloat. But they could be done.
There are a few goto's that could be a problem, though.... Like the
recursion stuff in the search routine.
I Forget
That is indeed a reasonable position.
I guess I've been a bit too defensive about the program.
I'm sorry.
Bo Persson
"I Forget" <N...@spam.please> skrev i meddelandet
news:42adfe28$1...@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
I Forget
> 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?
Bo Persson
"I Forget" <N...@spam.please> skrev i meddelandet
> "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
I Forget
> 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.
I Forget
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.
Scott Moore
> 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.
I Forget
>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.
Scott Moore
> "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.
I Forget
>>>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 ?
The code is accidently assigning a subrange type to an integer type.
Considering how you've been talking about ISO and how it's tighted up the
type checking, I would assume that it'd catch that. That since technically
it is a type change, that'd it give a warning or an error.
However, even if it didn't, a 'Lint' kind of program goes much further than
what the language does or does not allow.
It also warns about things that are legal but may not be what you intend,
unexpected type changes or precision loss, or tthings that are poor
practices, and so on.
> 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've already made quite a bit of progress in those areas.
Although I have no way to check for ISO stuff, since none of my compilers
are ISO.
But I'm going a little beyond the minimal changes needed to get it compile
with P4 or about any other compiler. I'm also cleaning up a few areas,
getting rid of a few goto's, and so on.
Scott Moore
> "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.
>>
>>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 ?
>
>
> The code is accidently assigning a subrange type to an integer type.
Are you talking about:
var a: 1..10;
b: integer;
b := a;
?
Thats valid Pascal (in both Wirth 1972, or ISO 7185). Or please quote
what code you are referring to ?
>
> Considering how you've been talking about ISO and how it's tighted up the
> type checking, I would assume that it'd catch that. That since technically
> it is a type change, that'd it give a warning or an error.
Show the example please.
I can't answer the question "Pascal does not seem to be as good as lint",
nobody can. I can, however, address each case you have a question on.
>
> However, even if it didn't, a 'Lint' kind of program goes much further than
> what the language does or does not allow.
>
> It also warns about things that are legal but may not be what you intend,
> unexpected type changes or precision loss, or tthings that are poor
> practices, and so on.
Pascal does not allow type changes except under very narrow curcumstances
(say, character to integer and back), and there is nowhere in Pascal
where precision loss is tolerated.
If you can show examples of your issues, I can address them. Where was
an unexpected type change ? A precision loss ?
fr...@g-n-u.de
> "Scott Moore"
>>
>> "lint" standards.
>
> Not any of the Pascal compilers that I have access to.
>
> GPC sure as expletive didn't. Neither did TurboPascal.
>
> 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. ;-)
Waldek Hebisch
>>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
heb...@math.uni.wroc.pl
CBFalconer
>
... 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.
I Forget
news:42b3c345$0$27776$9b4e...@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...
I Forget
>
> 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==----
I Forget
>
> 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.
What I'm using is definetly NOT finding any problems with the GOTO's. If it
had found a problem, I would have fixed it before I ever announced Byte
Chess 0.5 as being available.
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...
I Forget
news:42b3c345$0$27776$9b4e...@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.
> 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...
Scott Moore
Scott Moore
I Forget
>> Are you talking about:
>>
>> var a: 1..10;
>> b: integer;
>>
>> b := a;
Yes, that kind of thing.
>> Thats valid Pascal (in both Wirth 1972, or ISO 7185). Or please quote
>> what code you are referring to ?
It may indeed be valid.
You've been talking so much about how much more strict ISO is, that I just
assumed it would have tighted that up as well.
As I've said, I don't use ISO. I don't have an ISO compiler. All I hve is
GPC and it's obviously not behaving like ISO even when I tell it to.
>> Pascal does not allow type changes except under very narrow curcumstances
>> (say, character to integer and back), and there is nowhere in Pascal
>> where precision loss is tolerated.
>>
>> If you can show examples of your issues, I can address them. Where was
>> an unexpected type change ? A precision loss ?
That bug resulted in an unexpected type change, yes. And an artificial
restriction of the range.
That's the kind of things that LINT looks out for.
Things that may be correct code, but it may not be the intended code.
And since Chess 0.5 is a scanned program, it's entirely possible there are
other, similar unexpected type changes in the program.
As I mentioned to somebody else, I don't normally use LINT. They can indeed
generate way too many warnings and issues. (Normally the solution is to run
lint on individual small source files, instead of the whole program. But
that's not possible with Chess 0.5)
But since Chess 0.5 is an old program, using an old style of Pascal, and is
a scanned copy that may have non-obvious errors, I can't really depend on
the normal type checking. Certainly not GPC's, which isn't complaining
about a lot of things that other people are commenting on (such as the
goto's, and the strict types.)
Scott Moore
> "Scott Moore"
>
>>>Are you talking about:
>>>
>>>var a: 1..10;
>>> b: integer;
>>>
>>>b := a;
>
>
> Yes, that kind of thing.
>
>
>>>Thats valid Pascal (in both Wirth 1972, or ISO 7185). Or please quote
>>>what code you are referring to ?
>
>
> It may indeed be valid.
>
> You've been talking so much about how much more strict ISO is, that I just
> assumed it would have tighted that up as well.
I don't understand why it should be "tightened up". Why would it be invalid ?
Pascal is very regular in its assignment rules:
var a: 1..10;
b: 1..100;
a := 5;
b := a; { valid }
b := 50;
a := b; { invalid }
To remain on your point, what is it that lint does that you are expecting
Pascal to find ?
>
> As I've said, I don't use ISO. I don't have an ISO compiler. All I hve is
> GPC and it's obviously not behaving like ISO even when I tell it to.
>
I can't answer for GPC.
>
>>>Pascal does not allow type changes except under very narrow curcumstances
>>>(say, character to integer and back), and there is nowhere in Pascal
>>>where precision loss is tolerated.
>>>
>>>If you can show examples of your issues, I can address them. Where was
>>>an unexpected type change ? A precision loss ?
>
>
> That bug resulted in an unexpected type change, yes. And an artificial
> restriction of the range.
>
> That's the kind of things that LINT looks out for.
Again, are you referring to the above subrange assigns ? Its quite valid,
and the Pascal rules for it are quite regular.
I suspect that what may be confusing you is the Pascal promotion rules.
All integers in Pascal are compatible, including subranges, although
some assignments may be in error because they (as above) would assign
an out of range value. Now in C, you have:
unsigned char b;
int a;
a = 1000;
b = a;
Is a "loss of precision" because C specifies different sizes for
the integers. In C, this is not an error, but as you say, lint would
"warn" about it.
It does not work this way in Pascal. The equivalent would be:
var b: 0..255;
a: integer;
a := 1000;
b := a;
In Pascal this is an error, a runtime error.
The problem here is your comparision of C and Pascal. In Pascal, many things
that don't generate errors in C, are errors in Pascal and stop the run.
Thus, at the risk of being redundant, lint has no purpose for things
like this, because what needed a "could be bad ???" warning in
C is a completely non-ambiguous error in Pascal.
To put it another way, if everone in your country is lame, and in
need of a crutch to walk, you might assume that a man who has no
crutch has something wrong with him.
>
> Things that may be correct code, but it may not be the intended code.
>
>
> And since Chess 0.5 is a scanned program, it's entirely possible there are
> other, similar unexpected type changes in the program.
>
> As I mentioned to somebody else, I don't normally use LINT. They can indeed
> generate way too many warnings and issues. (Normally the solution is to run
> lint on individual small source files, instead of the whole program. But
> that's not possible with Chess 0.5)
>
> But since Chess 0.5 is an old program, using an old style of Pascal, and is
> a scanned copy that may have non-obvious errors, I can't really depend on
> the normal type checking. Certainly not GPC's, which isn't complaining
> about a lot of things that other people are commenting on (such as the
> goto's, and the strict types.)
>
>
>
>
> ----== 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 =----
Maurice.Lombardi
I Forget a écrit:
> <fr...@g-n-u.de> wrote in message
> 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.
It is indeed.
You use the djgpp version dated 20041218, the last posted onto djgpp servers,
because it is considered the last "stable" version.
But gpc is in continuous development.
Since then two alpha versions have been released, the last dated 20050331.
They have not been posted on djgpp sites, because they are considered as alphas.
Meanwhile
- ISO conformance of gotos have been enforced
- full range checks have been implemented
(among other improvements)
I have compiled your program, taken from Moore site, with all the changes you
suggest in the accompanying ByteChess.txt, with the two gpc versions.
with gpc 20041218 it compiles with no errors, only the warnings you indicate,
and some others (about unused variables) because I compiled with -W -Wall.
with gpc 20050331 I obtain errors for invalid gotos
The changes indicated by Moore for ISO conformance will certainly make gotos
work (looking what he does), but I have not yet tried.
Maurice
--
Maurice Lombardi
Laboratoire de Spectrometrie Physique,
Universite Joseph Fourier de Grenoble, BP87
38402 Saint Martin d'Heres Cedex FRANCE
Tel: 33 (0)4 76 51 47 51
Fax: 33 (0)4 76 63 54 95
mailto:Maurice....@ujf-grenoble.fr
I Forget
>> Maybe it's the DJGPP version I'm using. I don't know.
>
> It is indeed.
> You use the djgpp version dated 20041218, the last posted onto djgpp
> servers,
> because it is considered the last "stable" version.
Somebody said a *earlier* version also reported the errors. It did complain
about the code.
Then some time later (much later), the DJGPP version came along. It does
not complain.
Then apaprently the new alpha versions come along and does complain.
So I don't know whether GPC changed and DJGPP just happened to be compiled
during that period, or whether there was a problem compiling GPC.
Realistically, as an end user of a compiler, it doesn't make a lot of
difference how it happened.
All that really matters is that I can't depend on it.
I don't have the full DJGPP development environment, so I'm not going to
compile the latest CVS version myself.
>Since then two alpha versions have been released, the last dated 20050331.
Hopefully, the next alpha version will fix the internal compiler errors that
I reported...
> I have compiled your program, taken from Moore site, with all the changes
> you suggest in the accompanying ByteChess.txt, with the two gpc versions.
> with gpc 20041218 it compiles with no errors, only the warnings you
> indicate,
Hmmm... As I said above, somebody said a a version older than that did
complain.
> and some others (about unused variables) because I compiled with -W -Wall.
I did -Wall and a few others (although not -W -Wall) and didn't get any more
warnings. I also tried the -ISO-STANDARD (or whatever it's called) and a
few other options listed in the docs.
I never could get any additional warnings from the program.
> with gpc 20050331 I obtain errors for invalid gotos
> The changes indicated by Moore for ISO conformance will certainly make
> gotos work (looking what he does), but I have not yet tried.
I think he said his ISO version doesn't actually work right yet.
I'm working on getting rid of most of the goto's (to get it to work under
TurboPascal), but I can't do anything about ISO compliance.
I Forget
>>
>> It may indeed be valid.
>>
>> You've been talking so much about how much more strict ISO is, that I
>> just assumed it would have tighted that up as well.
>
> I don't understand why it should be "tightened up". Why would it be
> invalid ?
> Pascal is very regular in its assignment rules:
Well, conceptually, it is indeed a different type. A type where there are
limits.
[shrug]
> To remain on your point, what is it that lint does that you are expecting
> Pascal to find ?
A LINT style program looks for other things.
For Pascal, it might do cases where you assign a subrange to a full integer.
Since you are explicitly working with a subrange, assigning it to a full
integer could be considered a conceptual 'type change' (even if it's legal
pascal) and you might be doing it by accident. (Yes yes yes... I know. You
said it's legal. I'm not disagreeing with that.)
A LINT may check for unusual math ordering. Doing things like a:=b+c*d+e is
perfectly legal, of course. It's also possible you meant to write
(b+c)*(d+e) or b+c+d+e instead of b+(c*d)+e
Warnings about abmigous variables, such as var1 and varl, and INFO and INF0
and so on. If you have only one defined, then you'll get an error. But if
you have both, then it might be confusing at times.
It may notice that a variable (or function) is always being set to a
specific value, and never anything else. For example, accidently setting a
bool function to TRUE and accidently editing out (or commenting out) the
line that sets it to FALSE. It may be intended. Or it may not.
It may even complain about inconsistant indentation in the program, if it
thinks it might be confusing you about what level of nested statement you
are working at.
Things that may not be wrong or invalid Pascal, but may not be intended.
A LINT program doesn't look for things that are completely invalid. That's
basically the compiler's job. What it does is look for poor programming.
Remember those warnings that GPC spits out about the semicolong following
THEN, and the warning that the for loop counter being threatend?
Those are the kinds of things that a LINT does. Except much more so.
Basically, it nitpicks about your coding. Then you have to go through and
decide whether it is what you meant, or you made a mistake.
> Again, are you referring to the above subrange assigns ? Its quite valid,
> and the Pascal rules for it are quite regular.
And again, as I've said many times before, a LINT program goes *beyond* what
is legal or not.
It tries to look at what the programmer is doing and determine whether they
actually meant to do that, or was careless.
A scanned program with typos could be considered 'careless programming' by a
LINT.
Scott Moore
> "Scott Moore"
>
>>>It may indeed be valid.
>>>
>>>You've been talking so much about how much more strict ISO is, that I
>>>just assumed it would have tighted that up as well.
>>
>>I don't understand why it should be "tightened up". Why would it be
>>invalid ?
>>Pascal is very regular in its assignment rules:
>
>
> Well, conceptually, it is indeed a different type. A type where there are
> limits.
There are limits on type "integer" as well, in fact, they are documented
both in WIrth 1972 and ISO 7185 Pascal as -maxint..maxint. I have to suspect
you are thinking C here. C has lots of different precision variable types,
and its a problem to assign one to another. Pascal does not work this way.
Integer is integer, and if you assign one integer to another that cannot
take one of its valid values, its an error, not a warning. Pascal is
less ambiguous than C in this respect.
Sure. GPC has the warnings that you are interested in. I don't put warnings
in IP Pascal because I am a C programmer :-) I get really tired of seeing
C programs that spill out lots of warning messages, only to be told by
the authors that "this is normal". IP Pascal handles what you would call
warnings with a go/no go flag. For example, not using a variable that
was defined is not fatal to the program, but IP Pascal either treats it
as an error or ignores it by programmer option. If the programmer wants to
eliminate unreferenced variables, then he puts the option on, and its
an error. If not, no report is output. There is no message the compiler
outputs that is not important, so there is nothing to "get used to".
In fact, the compiler proper deletes the output file on error so that
it cannot be used.
To me, the "nanny program" belongs as a separate program. Clearly there
is some disagreement about this, and GPC clearly includes warnings.
I came from a big company that had a project to clean up its source code,
using new "advanced checkers" (sometimes called "superlint"). Because I
am known for avocating clean coding practices, it got assigned to me
to implement it in our group. In short, it was a nightmare, with programmers
running around and performing makework tasks like inventing useless variables
to hold the results of "printf", because the superlint noticed that, being
a function, printf returns a (gasp) value !
In the C world, lint is a lot more important because C lets so many errors
by, and the language itself cannot check many circumstances of error
(like array references). So printing lots of "could be wrong" warnings is
how you get programmers to look closely at their code.
In Pascal, types are checked and enforced unambiguously, so there is far
less need for such a tool.
I Forget
>> Well, conceptually, it is indeed a different type. A type where there
>> are limits.
>
> There are limits on type "integer" as well, in fact, they are documented
But I was refering to the sub-range. From a programmer's perspective.
Basically, yes, I guess it's a subrange of a subrange type.
> Sure. GPC has the warnings that you are interested in. I don't put
> warnings
GPC does *not* have the warnings I'm interested in. That's kind of the
problem.
None of the compilers I have give the kind of warnings that would help debug
the scanning.
> in IP Pascal because I am a C programmer :-) I get really tired of seeing
> C programs that spill out lots of warning messages, only to be told by
> the authors that "this is normal". IP Pascal handles what you would call
Generally, I use 'all warnings' at a minimum.
I don't claim my programs compile cleanly with every single warning enabled,
but I do usually make a point to clean up most of the obvious stuff.
In fact, when I was working in TurboPascal, I enabled all the warnings and
stuff mostly out of habit, rather than any real expectation it would tell me
something new.
> To me, the "nanny program" belongs as a separate program. Clearly there
Which is what LINT is...
> is some disagreement about this, and GPC clearly includes warnings.
The version I have doesn't seem to include many...
Personally, I think the compiler should optionally give some of the
reasonable ones. But not nearly anything like what a LINT program does.
> running around and performing makework tasks like inventing useless
> variables
> to hold the results of "printf", because the superlint noticed that, being
> a function, printf returns a (gasp) value !
In cases like those, you turn off stupid warnings. Most lints can be done
even for individual functions. So you end up with a line in the lint config
saying something like: e234- printf which might mean to ignore warnings
about return variables for printf.
Realistically, a lint or superlint should already come preconfigured with
more reasonable options about library functions such as printf.
But, sometimes management wants you to turn them all on....
> In Pascal, types are checked and enforced unambiguously, so there is far
> less need for such a tool.
Maybe less, but there is still a need.
A lot of stuff is still valid pascal that may or may not be good
programming.
CBFalconer
>
... snip ...
>
> But since Chess 0.5 is an old program, using an old style of
> Pascal, and is a scanned copy that may have non-obvious errors, I
> can't really depend on the normal type checking. Certainly not
> GPC's, which isn't complaining about a lot of things that other
> people are commenting on (such as the goto's, and the strict types.)
I suggest you start by using gpc with appropriate flags. I use:
gpc --standard-pascal --no-mixed-comments -gstabs+
and the only real failure in the past has been the lack of
*run-time* checks. That is being, or has been, fixed. I am
awaiting news that the problems with later gcc 3.4 up versions
under DJGPP have been handled.
I Forget
>
> I suggest you start by using gpc with appropriate flags. I use:
>
> gpc --standard-pascal --no-mixed-comments -gstabs+
I have tried standard-pascal. No extra errors or warnings.
I don't have any mixed comments to complain about.
And I don't know what -gstabs+ does, since it's not listed in the gpc docs.
I have tried a lot of the warnings and extra options.
I've only been able to get just a few more warnings. Nothing significant.
I Forget
>
> I suggest you start by using gpc with appropriate flags. I use:
>
> gpc --standard-pascal --no-mixed-comments -gstabs+
I have tried standard-pascal. No extra errors or warnings.
I don't have any mixed comments to complain about.
And I don't know what -gstabs+ does, since it's not listed in the gpc docs.
I have tried a lot of the warnings and extra options.
I've only been able to get just a few more warnings. Nothing significant.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
I Forget
>
> I suggest you start by using gpc with appropriate flags. I use:
>
> gpc --standard-pascal --no-mixed-comments -gstabs+
I have tried standard-pascal. No extra errors or warnings.
I don't have any mixed comments to complain about.
And I don't know what -gstabs+ does, since it's not listed in the gpc docs.
I have tried a lot of the warnings and extra options.
I've only been able to get just a few more warnings. Nothing significant.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
I Forget
>
> I suggest you start by using gpc with appropriate flags. I use:
>
> gpc --standard-pascal --no-mixed-comments -gstabs+
I have tried standard-pascal. No extra errors or warnings.
I don't have any mixed comments to complain about.
And I don't know what -gstabs+ does, since it's not listed in the gpc docs.
I have tried a lot of the warnings and extra options.
I've only been able to get just a few more warnings. Nothing significant.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
fr...@g-n-u.de
Scott Moore <sam...@moorecad.com> wrote:
> Sure. GPC has the warnings that you are interested in. I don't put warnings
> in IP Pascal because I am a C programmer :-) I get really tired of seeing
> C programs that spill out lots of warning messages, only to be told by
> the authors that "this is normal". IP Pascal handles what you would call
> warnings with a go/no go flag. For example, not using a variable that
> was defined is not fatal to the program, but IP Pascal either treats it
> as an error or ignores it by programmer option. If the programmer wants to
> eliminate unreferenced variables, then he puts the option on, and its
> an error. If not, no report is output. There is no message the compiler
> outputs that is not important, so there is nothing to "get used to".
> In fact, the compiler proper deletes the output file on error so that
> it cannot be used.
I mostly agree, though not everyone does. Therefore, GPC has an
option `-Werror' which makes all warnings fatal errors. I always use
it (on my own code), others don't. When I start working on foreign
code, I usually first turn it on and fix the warnings, to avoid
getting used to them. ;-)
> To me, the "nanny program" belongs as a separate program. Clearly there
> is some disagreement about this, and GPC clearly includes warnings.
I think sometimes it's easier as it avoids duplication of effort --
lint partly has to do the same work as the compiler, and in
particular in the complex situations of several dialects that GPC
handles, that could be significant. But that's not stopping anyone
from writing a Pascal lint if they want.
> In short, it was a nightmare, with programmers
> running around and performing makework tasks like inventing useless variables
> to hold the results of "printf", because the superlint noticed that, being
> a function, printf returns a (gasp) value !
Shudder! If it accepted type-casting to void, it wouldn't be quite
as ugly (but still ugly enough ;-).
fr...@g-n-u.de
I Forget <N...@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.
fr...@g-n-u.de
I Forget <N...@spam.please> wrote:
> > Sure. GPC has the warnings that you are interested in. I don't put
> > warnings
>
> GPC does *not* have the warnings I'm interested in. That's kind of the
> problem.
We're always interested in adding useful warnings. But which ones do
you actually want? Assigning a subrange to a full integer? You keep
saying this, but you haven't really explained why you think it's a
problem. The other way around I could partly see a reason, though
it's usually caught by runtime checks, as many have pointed out, but
assigning a subrange to a full integer is simply safe and
umambiguous and doesn't restrict anything.
> None of the compilers I have give the kind of warnings that would help debug
> the scanning.
Debugging scanning is kind of specific, so I'm not sure I'll spend
much work here. Of course, as GPC is free software, you can add the
checks you want yourself instead of complaining.
> In fact, when I was working in TurboPascal, I enabled all the warnings and
> stuff mostly out of habit, rather than any real expectation it would tell me
> something new.
Uhm, Turbo Pascal doesn't have warnings. (I suppose you mean you
enabled some stricter checking, but these were always errors.)
> Hopefully, the next alpha version will fix the internal compiler errors that
> I reported...
Yes, Waldek spent some effort to fix them. It's always nice to see
thankfulness for work done for free.
I Forget
>> 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
Right.
> 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
It doesn't catch any of the other ISO type problems.
And that's even with the ISO option enabled.
Scott has commented quite a few times that Chess 0.5 (including my changes)
are not enough for it to compile under ISO pascal.
Since I don't have a working ISO compiler, I can't see what else needs to be
fixed.
> 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.
The version I did.
GPC doesn't catch the ISO type problems that Scott has repeatedly been
complaining about. Even when I tried to turn on strict ISO in GPC.
That's why he tried to do an ISO version. Because I wasn't even seeing the
problems he was.
Again, Scott has repeatedly commented that the program wasn't compiling
right and he was getting all sorts of ISO errors / warnings.
If my version of GPC had complained about those things being a problem (and
especially an error), then they would have been fixed.
> 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
Apparently an old versions catch a few things that my DJGPP version doesn't.
Somebody in here tried it with an older version (from 2002?) and it caught
things the DJGPP version didn't.
> 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
Surprise, but I *did* try the ISO mode. And other switches.
There is nothing I can do in my DJGPP GPC to get the kinds of errors and
warnings that he talks about.
> mode, i.e. compile with `--gnu-pascal' (as noted in your list), or
The -gnu mode was only suggested to the user if you didn't want to change
the quote characters.
>> 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
Oh, that's clever....
It only takes a few examples to prove the point that it *can* be done. Just
that most don't bother.
> 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.
[sigh]
Yes, I knew right after I sent the message that you would comment on that.
I was just trying to give an example of arbitrary array bounds where you
could check both upper and lower.
However, technically, the ANSI & ISO C standards *do* allow for negative
subscript indexing. So you can actually do things like VAR[-83] array
indexing. Provided you manually point VAR pointer far enough so it will
stay within allocated memory.
> And again, arrays are treated as pointers in C very often, in
> particular whenever they're passed as parameters.
Yes.
*BUT* if the compiler writer wants to (or the interpreter writer wants to),
they can pass along extra hidden debugging information, to allow extra
checking.
No, it wouldn't standard, official C. (Well, actually it might. Depends on
how clever the writer is.) But it would work in a development / debugging
enviornment.
There is nothing in the C standard that says a pointer can't contain extra
information, such as boundary info, that the environment can use for its own
purpose. Heck, it can even have bits right in the middle of it that are set
arbitrarily (as far as C is concerned) that play no part in the normal
pointer opration.
(Yes, that's right, I said a pointer or integer could be
......xxx....xxx.... where the x's are "don't care" values that play no part
in the C language itself. As long as the hardware itself understands it,
that's all that matters. Why did they do that...? Because from what I
gather, there were a few odd systems in the world that actually did those
sorts of things. So the C standard explicitly allows it. I guess in a way,
it's not really all that much different from having memory pairty bits in
your memory. Technically, each and every byte and word and pointer has
extra hardware bits in it, but C doesn't see any of that.)
So, for example, a C implementation could make all pointers be 96 bits. One
word for the regular pointer, and two words for boundary information. So,
as far the C program itself is concerned, the pointer is just simply
"pointer size" and it behaves normally. It has no way of even knowing the
extra baggage is included and being used by the environment.
If I remember right, and I'm sure I do, during the development of the C
standard, they explicitly made it illegal to load a pointer with an illegal
value or touch a pointer that pointed to memory that had been freed. The
reason was in case the environment was doing any sort of pointer validation
or bounds checking. It wasn't because that'd be buggy programming, but
because the environment might cause the program to abort.
Also, they did a few other areas (sorry, can't remember the exact details)
about memory bounds, so that if there was any sort of boundary checking
being done, it wouldn't abort. (For example, hardware memory pages, etc.)
I could give you a few more examples, but to be honest, it's been a while
since I've looked at the C standard or browsed over all the notes about the
standardization.
There are lots of checks that can be done. Most C compilers just don't
bother.
But this is really getting off the subjct.
I Forget
>> 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
Right.
> 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
It doesn't catch any of the other ISO type problems.
And that's even with the ISO option enabled.
Scott has commented quite a few times that Chess 0.5 (including my changes)
are not enough for it to compile under ISO pascal.
Since I don't have a working ISO compiler, I can't see what else needs to be
fixed.
> 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.
The version I did.
GPC doesn't catch the ISO type problems that Scott has repeatedly been
complaining about. Even when I tried to turn on strict ISO in GPC.
That's why he tried to do an ISO version. Because I wasn't even seeing the
problems he was.
Again, Scott has repeatedly commented that the program wasn't compiling
right and he was getting all sorts of ISO errors / warnings.
If my version of GPC had complained about those things being a problem (and
especially an error), then they would have been fixed.
> 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
Apparently an old versions catch a few things that my DJGPP version doesn't.
Somebody in here tried it with an older version (from 2002?) and it caught
things the DJGPP version didn't.
> 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
Surprise, but I *did* try the ISO mode. And other switches.
There is nothing I can do in my DJGPP GPC to get the kinds of errors and
warnings that he talks about.
> mode, i.e. compile with `--gnu-pascal' (as noted in your list), or
The -gnu mode was only suggested to the user if you didn't want to change
the quote characters.
>> 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
Oh, that's clever....
It only takes a few examples to prove the point that it *can* be done. Just
that most don't bother.
> 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.
[sigh]
Yes, I knew right after I sent the message that you would comment on that.
I was just trying to give an example of arbitrary array bounds where you
could check both upper and lower.
However, technically, the ANSI & ISO C standards *do* allow for negative
subscript indexing. So you can actually do things like VAR[-83] array
indexing. Provided you manually point VAR pointer far enough so it will
stay within allocated memory.
> And again, arrays are treated as pointers in C very often, in
> particular whenever they're passed as parameters.
Yes.
Scott Moore
> Scott has commented quite a few times that Chess 0.5 (including my changes)
> are not enough for it to compile under ISO pascal.
Well, I said it compiles but does not run. I just checked, it runs into your
(in)famous "sign" (divide by zero) issue, then after that was fixed,
faults with range errors. Thats all I have time for right now. How far did
you get ?
Scott Moore
I Forget
>By the way, your newsreader seems to be double posting everything now.
Yeah, I've been having problems the past couple days. Both receiving and
espeically posting.
The reader just sits there waiting for the notice from the server that says
the message was posted. It rarely gets here, so my news reader finally
times out.
I'll wait a minute or so and check the newsgroup, and sometimes it's been
posted and sometimes it hasn't. If it hasn't, I'll try it again. Then
sometimes it shows up as a double or even tripple post. Other times the
message really doesn't show up, and I have to do it again later.
Nothing on my side has changed, so I don't know what the problem is. I
guess the server is having problems.
>> Scott has commented quite a few times that Chess 0.5 (including my
>> changes) are not enough for it to compile under ISO pascal.
>
> Well, I said it compiles but does not run. I just checked, it runs into
> your
You were sending me the ISO changes via email for a reason....
And you've been talking about ISO changes to the types. Othe than the few I
mention in my docs.
I assumed that those 8 type changes and new type names and so on were done
for more than just fun.
I'm not getting warnings or errors about all that stuff.
Obviously you are, otherwise you wouldn't be changing them.
> (in)famous "sign" (divide by zero) issue, then after that was fixed,
> faults with range errors. Thats all I have time for right now. How far did
> you get ?
I have it working properly under TurboPascal. At least it's giving
identical search tree's for the GPC version. I assume the GPC version is
working okay.... It may fail at some deeper part, where it's doing
something that I haven't tested.
I gave up on correctly and completely handling the RDRError routine.
Instead, I just do a few important areas. This means that it's possible you
might get more than one error for a line of input, but I'll live with that.
I rewrote the Search routine, to get rid of most of the goto's. Including
the one that others have pointed out doesn't work in actual ISO Pascal.
There are still a few goto's in the program, but they are either exiting a
loop early, or exiting a routine early. Plus a few other minor areas, such
as the Search routine where it jumps up to the top to simulate recursion.
I haven't yet taken care of the routine that reads numbers. At the moment,
that's tied to +-32767 because of the constants. Changing the constant
would effect a few other areas. (This means you can't set the number of
nodes to search at more than 32767. Meaning just a few seconds worth of
thinking on modern systems.)
Considering the speed of modern systems, I may need to use REAL in a few
places, so the program will still work right and well in a 16 bit
environment.
I really need to figure out a way to do the mbeval routine. The math in
there needs at least 32 bits (and actually possibly 37 or more.) That
doesn't work right under 16 bit math. It can fail under 32 bit (for those
few, rare, user entered test cases.) Right now I've got a kludge that just
uses REAL (full 8 byte version), but I need to come up with a better
solution. I could adjust the expression to use slightly different values
etc. and it would give somewhat similar results. But I don't know how well
'tuned' the expression is for evalauting board positions.
I may do some more work in other areas. (If so, it'll probably have to be
monday. I'll probably be busy tonight and tomorrow.)
I also took care of a few non-critical areas. I got rid of all the variant
records. I fixed a problem where the program couldn't run on a 32 bit
system if you had the program set for 16 (and the other way around.) (I
think the RS variant record (which holds the bit board) was done to deal
with them using the CDC specific routine. That way they could be sure of
storing zero into the entire word, and not just the part that held the set.)
I could even get rid of the set's if I had too. The only complicated area
would be the user input.
Not much I can really do about the performance of the low level bit / set
manipulation routines. About all I can think of is to break it all down in
4 bit chunks and then use a bunch of tables to perform and, or, not, count,
shift, and so on.
Waldek Hebisch
> I really need to figure out a way to do the mbeval routine. The math in
> there needs at least 32 bits (and actually possibly 37 or more.) That
> doesn't work right under 16 bit math. It can fail under 32 bit (for those
> few, rare, user entered test cases.) Right now I've got a kludge that just
> uses REAL (full 8 byte version), but I need to come up with a better
> solution. I could adjust the expression to use slightly different values
> etc. and it would give somewhat similar results. But I don't know how well
> 'tuned' the expression is for evalauting board positions.
GPC allows you to use 64 bit integers. You may declare them as `longint',
or if you prefer to stay with ISO Pascal then you may use subranges
(GPC allows bounds to be bigger then maxint, up to 64 bits).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
I Forget
> GPC allows you to use 64 bit integers. You may declare them as `longint',
Not portable.
> or if you prefer to stay with ISO Pascal then you may use subranges
> (GPC allows bounds to be bigger then maxint, up to 64 bits).
Not quite sure what you mean here...
Are you saying that under normal pascal (whether it's P4, TurboPascal, ISO,
etc.) that you can somehow trick the compiler into doing math larger than
integer?
If so, how?
fr...@g-n-u.de
I Forget <N...@spam.please> wrote:
> It doesn't catch any of the other ISO type problems.
>
> And that's even with the ISO option enabled.
>
> Scott has commented quite a few times that Chess 0.5 (including my changes)
> are not enough for it to compile under ISO pascal.
Sure, GPC doesn't catch all possible ISO violations yet. We're
working on it, but it's a hard job, and I'm not sure any compiler
really catches all. (As can be seen in previous messages, GPC caught
some that others didn't.) I noticed that Scott found and fixed
another one that wasn't mentioned yet AFAIR, in the declaration of
RS. (Whereas his versions still contains some problems GPC does
find.) If we put all our findings together, we might be able to get
an ISO compilant version in the end ...
> GPC doesn't catch the ISO type problems that Scott has repeatedly been
> complaining about. Even when I tried to turn on strict ISO in GPC.
Perhaps another misunderstanding. I'm not sure what you mean
actually:
- The "errors" about packed stuff? These were actually bogus (i.e.,
the constructs are valid ISO), and more recent GPC versions,
including yours, are correct not to give them. Scott hit an
unwarranted error with an older GPC version, but actually there's
no problem with newer GPCs or with the chess program here.
- The incompatible arrays. Scott changed them in his ISO version,
but AFAICS, his changes should be basically equivalent to the ones
you describe for GPC. As I understand it, he did them in parallel
while you did the changes for GPC.
... Well, on closer look, I actually see a problem (which GPC also
finds, BTW). Scott, are you sure this is correct ISO? Pieces cut
together from Scott's ISO version:
RX = ARRAY [TS] OF RS; (* ATTACK MAPS *)
arraytsofrs = array [ts] of rs;
ATKFR : arraytsofrs; (* ATTACKS FROM A SQUARE *)
ATKTO : arraytsofrs; (* ATTACKS TO A SQUARE *)
PROCEDURE PRINAM(A:RX); (* PRINT ATTACK MAP *)
PRINAM(ATKTO)
PRINAM(ATKFR)
> If my version of GPC had complained about those things being a problem (and
> especially an error), then they would have been fixed.
AFAICS, the threatened for-loop counters (which are forbidden by
ISO) are an error by GPC (including your version 20041218) if you
use an ISO option (e.g., `--classic-pascal'), so then, why didn't
you fix them?
(Whereas the one invalid goto is indeed only detected by the latest
alpha versions of GPC.)
> > mode, i.e. compile with `--gnu-pascal' (as noted in your list), or
>
> The -gnu mode was only suggested to the user if you didn't want to change
> the quote characters.
I was just pointing out that the same option (or lack of ISO option)
will also prevent the invalid goto from being an error in the
upcoming GPC version, and the threatened `for' loop counters from
being errors in your version as well as the upcoming one. Whether or
not you mention this in your doc, the effect is the same: All three
things are ISO violations; GPC will accept them without an ISO
option. If you want minimal changes to get it compiled with GPC,
that's fine, just don't use an ISO option. If you want it to be ISO
compliant, you'll have to fix all of them, as well as the other ones
that have been found.
[ Skipped OT part about C range checking ]
Scott Moore
> In <42b49757$1...@spool9-west.superfeed.net>,
> I Forget <N...@spam.please> wrote:
>
>
>>It doesn't catch any of the other ISO type problems.
>>
>>And that's even with the ISO option enabled.
>>
>>Scott has commented quite a few times that Chess 0.5 (including my changes)
>>are not enough for it to compile under ISO pascal.
>
>
> Sure, GPC doesn't catch all possible ISO violations yet. We're
> working on it, but it's a hard job, and I'm not sure any compiler
> really catches all. (As can be seen in previous messages, GPC caught
> some that others didn't.) I noticed that Scott found and fixed
> another one that wasn't mentioned yet AFAIR, in the declaration of
> RS. (Whereas his versions still contains some problems GPC does
> find.) If we put all our findings together, we might be able to get
> an ISO compilant version in the end ...
I just put the most recent copy of chess05iso.pas online at the web
site. Stewart, at Irie Pascal pointed out to me last week that I was
in fact missing a few compliancy errors, and I have been fixing them
since. Hopefully, the copy is better now. I'd still like to hear if
there are remaining ISO volations in it.
I changed the "sign" routine, there's just no telling what the original
author was getting at there, but my version of that seems reasonable.
I'm guessing that, looking at Mr. Forgets estimation of the lack of
CDC 6400 zero divide trap is correct, and the original author
was somehow exploiting that. Fun. (the CDC appers to return a NAN,
in pre-IEEE floating point terms, for the program to check).
As it is, the program compiles, then runs into range check errors
on two Pascal implementations, IP Pascal and Irie Pascal. On GPC
its hard to tell what its doing, but it dosen't look correct.
I suspect that (considering the former conversation about range
checking), that IP Pascal and Irie are finding range errors that
GPC is not, and in any case the program is not quite running
yet.
I have to table this for later, I am trying to finish up a bug
scrub of several dozen outstanding issues, so it will be a while
before I have time to revisit this.
>
>
>>GPC doesn't catch the ISO type problems that Scott has repeatedly been
>>complaining about. Even when I tried to turn on strict ISO in GPC.
>
>
> Perhaps another misunderstanding. I'm not sure what you mean
> actually:
>
> - The "errors" about packed stuff? These were actually bogus (i.e.,
> the constructs are valid ISO), and more recent GPC versions,
> including yours, are correct not to give them. Scott hit an
> unwarranted error with an older GPC version, but actually there's
> no problem with newer GPCs or with the chess program here.
To give GPC its due, a with reference to an element of a packed record
seems like something that should be illegal. I just can't find anything
in the standard that addresses that.
>
> - The incompatible arrays. Scott changed them in his ISO version,
> but AFAICS, his changes should be basically equivalent to the ones
> you describe for GPC. As I understand it, he did them in parallel
> while you did the changes for GPC.
>
> ... Well, on closer look, I actually see a problem (which GPC also
> finds, BTW). Scott, are you sure this is correct ISO? Pieces cut
> together from Scott's ISO version:
>
> RX = ARRAY [TS] OF RS; (* ATTACK MAPS *)
>
> arraytsofrs = array [ts] of rs;
>
> ATKFR : arraytsofrs; (* ATTACKS FROM A SQUARE *)
> ATKTO : arraytsofrs; (* ATTACKS TO A SQUARE *)
>
> PROCEDURE PRINAM(A:RX); (* PRINT ATTACK MAP *)
>
> PRINAM(ATKTO)
>
> PRINAM(ATKFR)
Yes, known and found. You'll find that fixed in the current online
version.
>
>
>>If my version of GPC had complained about those things being a problem (and
>>especially an error), then they would have been fixed.
>
>
> AFAICS, the threatened for-loop counters (which are forbidden by
> ISO) are an error by GPC (including your version 20041218) if you
> use an ISO option (e.g., `--classic-pascal'), so then, why didn't
> you fix them?
>
> (Whereas the one invalid goto is indeed only detected by the latest
> alpha versions of GPC.)
Known and found. Compare with the current online vs. GPC beat me on
these ISO voilations. Have a beer on me :-)
>
>
>>>mode, i.e. compile with `--gnu-pascal' (as noted in your list), or
>>
>>The -gnu mode was only suggested to the user if you didn't want to change
>>the quote characters.
>
>
> I was just pointing out that the same option (or lack of ISO option)
> will also prevent the invalid goto from being an error in the
> upcoming GPC version, and the threatened `for' loop counters from
> being errors in your version as well as the upcoming one. Whether or
> not you mention this in your doc, the effect is the same: All three
> things are ISO violations; GPC will accept them without an ISO
> option. If you want minimal changes to get it compiled with GPC,
> that's fine, just don't use an ISO option. If you want it to be ISO
> compliant, you'll have to fix all of them, as well as the other ones
> that have been found.
>
> [ Skipped OT part about C range checking ]
>
> Frank
>
--
Waldek Hebisch
> "Waldek Hebisch"
>
>> GPC allows you to use 64 bit integers. You may declare them as `longint',
>
> Not portable.
>
>> or if you prefer to stay with ISO Pascal then you may use subranges
>> (GPC allows bounds to be bigger then maxint, up to 64 bits).
>
> Not quite sure what you mean here...
>
> Are you saying that under normal pascal (whether it's P4, TurboPascal, ISO,
> etc.) that you can somehow trick the compiler into doing math larger than
> integer?
>
What I mean is:
-- if you declare types as subranges then the program should work
on all ISO compilers which support integers of size you need
(if the compiler do not support the size you should get compile
time error)
-- GPC support 64 bit integers.
So you can write a program that can ran on 32-bit PC and on CDC-6400
using 48-bit integers. Of course, Turbo Pascal is limited to 32bits,
so you can not magically coerce to handle larger numbers. But FPC
can handle 64-bit integers, and I would expect all compilers for
64-bit machines also to support 64-bit integers. To handle 64-bit numbers
with P4 you would have to adjust its constant definitions and then compile
it using for example GPC.
So, compilers are allowed to have limits and if the compiler have too
small limit then bad luck. But you have portable way to ask for bigger
values and there is a bunch of compilers that will give you such
values.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> I just put the most recent copy of chess05iso.pas online at the web
> site. Stewart, at Irie Pascal pointed out to me last week that I was
> in fact missing a few compliancy errors, and I have been fixing them
> since. Hopefully, the copy is better now. I'd still like to hear if
> there are remaining ISO volations in it.
>
I just fetched the new version. It has still CDC dependency:
chess05ISO.pas: In function `RDRGNT':
chess05ISO.pas:2800: error: set constructor range is empty
chess05ISO.pas:2807: error: set constructor range is empty
chess05ISO.pas: In procedure `BOACMD':
chess05ISO.pas:2984: error: set constructor range is empty
all those lines contain ['A'..'9']. Which, depneding on the
charset is (or is not) ISO volation.
> As it is, the program compiles, then runs into range check errors
> on two Pascal implementations, IP Pascal and Irie Pascal. On GPC
> its hard to tell what its doing, but it dosen't look correct.
>
Hmm. Do "As it is" refer to your latest ISO version? It does not compile
with GPC.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> all those lines contain ['A'..'9']. Which, depneding on the
> charset is (or is not) ISO volation.
>
I just checked and ['A'..'9'] is not an error in ISO Pascal. So
GPC should just warn.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
CBFalconer
> I wrote:
>>
>> all those lines contain ['A'..'9']. Which, depneding on the
>> charset is (or is not) ISO volation.
>
> I just checked and ['A'..'9'] is not an error in ISO Pascal. So
> GPC should just warn.
I would expect it to yield the empty set. A clumsy, but often
sufficient, initialization would be:
alphas = ['A'..'Z'];
digits = ['0'..'9'];
anums = alphas + digits;
depending on what is really wanted in that set. At any rate the
set digits is portable. Alphas can be made portable, and what is
wanted tends to be obvious.
--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
Scott Moore
That was, IMHO, a pretty good explanation of how portability works in
Pascal.
Scott Moore
> I wrote:
>
>>all those lines contain ['A'..'9']. Which, depneding on the
>>charset is (or is not) ISO volation.
>>
>
>
> I just checked and ['A'..'9'] is not an error in ISO Pascal. So
> GPC should just warn.
>
>
Correct.
Scott Moore
> Scott Moore <sam...@moorecad.com> wrote:
>
>>I just put the most recent copy of chess05iso.pas online at the web
>>site. Stewart, at Irie Pascal pointed out to me last week that I was
>>in fact missing a few compliancy errors, and I have been fixing them
>>since. Hopefully, the copy is better now. I'd still like to hear if
>>there are remaining ISO volations in it.
>>
>
>
> I just fetched the new version. It has still CDC dependency:
>
> chess05ISO.pas: In function `RDRGNT':
> chess05ISO.pas:2800: error: set constructor range is empty
> chess05ISO.pas:2807: error: set constructor range is empty
> chess05ISO.pas: In procedure `BOACMD':
> chess05ISO.pas:2984: error: set constructor range is empty
>
>
> all those lines contain ['A'..'9']. Which, depneding on the
> charset is (or is not) ISO volation.
Perhaps Mr. Forget has the right translation of this, I seem to remember
Forget mentioning that. [mild pun intended]
>
>
>>As it is, the program compiles, then runs into range check errors
>>on two Pascal implementations, IP Pascal and Irie Pascal. On GPC
>>its hard to tell what its doing, but it dosen't look correct.
>>
>
>
> Hmm. Do "As it is" refer to your latest ISO version? It does not compile
> with GPC.
>
It compiles for me, with warnings. Note that my gpc is fairly (more than
a year) old.
fr...@g-n-u.de
CBFalconer <cbfal...@yahoo.com> wrote:
> Waldek Hebisch wrote:
> > I wrote:
> >>
> >> all those lines contain ['A'..'9']. Which, depneding on the
> >> charset is (or is not) ISO volation.
> >
> > I just checked and ['A'..'9'] is not an error in ISO Pascal. So
> > GPC should just warn.
Oh, you're right. I'll turn it into a warning in the next GPC
release. (A warning is certainly useful indeed as the chess program
shows -- while not an ISO violation, an empty set is not what was
intended.)
> I would expect it to yield the empty set. A clumsy, but often
> sufficient, initialization would be:
>
> alphas = ['A'..'Z'];
> digits = ['0'..'9'];
> anums = alphas + digits;
>
> depending on what is really wanted in that set. At any rate the
> set digits is portable. Alphas can be made portable, and what is
> wanted tends to be obvious.
Yep, for the chess program it may indeed be best to list all letters
for most portability ...
In <NOWdnbfZ9tC...@comcast.com>,
Scott Moore <sam...@moorecad.com> wrote:
> Perhaps Mr. Forget has the right translation of this, I seem to remember
> Forget mentioning that. [mild pun intended]
He wrote:
: 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
> > Hmm. Do "As it is" refer to your latest ISO version? It does not compile
> > with GPC.
>
> It compiles for me, with warnings. Note that my gpc is fairly (more than
> a year) old.
Quite possible. Many checks have been added since then.
fr...@g-n-u.de
Scott Moore <sam...@moorecad.com> wrote:
> I just put the most recent copy of chess05iso.pas online at the web
> site.
Here's a missing `}'. (Found it because GPC in non-ISO mode doesn't
allow "mixed" comments by default, so it comments out more than the
next statement, leading to unrelated errors.)
jumpin := false; { set no jumpin [sam]
BSTMV[AK] := AW; (* INITIALIZE MOVE *)
> As it is, the program compiles, then runs into range check errors
> on two Pascal implementations, IP Pascal and Irie Pascal. On GPC
> its hard to tell what its doing, but it dosen't look correct.
I'm not familiar with the old chess notation, so I can't really
tell, I'm afraid.
> I suspect that (considering the former conversation about range
> checking), that IP Pascal and Irie are finding range errors that
> GPC is not, and in any case the program is not quite running
> yet.
GPC does range checking only recently, your version doesn't, sorry.
> Yes, known and found. You'll find that fixed in the current online
> version.
Yep.
Scott Moore
> Here's a missing `}'. (Found it because GPC in non-ISO mode doesn't
> allow "mixed" comments by default, so it comments out more than the
> next statement, leading to unrelated errors.)
>
> jumpin := false; { set no jumpin [sam]
>
> BSTMV[AK] := AW; (* INITIALIZE MOVE *)
Fixed in online vs., thank you.
Jochen
I Forget typed:
> ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet
3x?
something wrong with your OE? or is it the server?
i use: http://news.dotsrc.org/ as my news service. i used individual.net
b4 but they decided to make it pay 4 it.
i don't ask ppl to pay 4 the things i offer to them - and i don't like
if
others do - i like it free :)
greets
jo
--
http://radio789.net.ms - Radio 789 - We play it ALL
Marco van de Voort
> "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....
Just make it as clean as possible, with lots of comments, and document
testcases, and I/we'll take care of the FPC/Borland conversion. Just out
of curiosity.
If it depends on integer math >31-bit, you'll need FPC2 anyway. (FPC1 doesn't
understand integer literals > 31-bit)
Note that some compilers need extra switches to enable rangechecking.
Marco van de Voort
>
> perfectly legal, of course. It's also possible you meant to write
> (b+c)*(d+e) or b+c+d+e instead of b+(c*d)+e
Source code inspection tools like this afaik exist for all major languages,
however most good ones are commercial only.
Marco van de Voort
>
>>By the way, your newsreader seems to be double posting everything now.
>
> Yeah, I've been having problems the past couple days. Both receiving and
> espeically posting.
> Nothing on my side has changed, so I don't know what the problem is. I
> guess the server is having problems.
IIRC it is something with certain newsservers in combination with OE. Something
with OE increasing msgid when it thinks a post failed, but actually succeeded.
A repeated failed -> succeeded part is a newsserver problem, but other newsreaders
don't have problems with it.
You might want to change newsreadesr.
Marco van de Voort
(chess ng trimmed)
> Waldek Hebisch wrote:
>> 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.
-bash-2.05b$ fpc forrange.pp
Free Pascal Compiler version 2.1.1 [2005/05/22] for i386
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: FreeBSD/ELF for i386
Compiling forrange.pp
forrange.pp(8,30) Warning: Type size mismatch, possible loss of data / range check error
forrange.pp(5,7) Note: Local variable "a" is assigned but never used
Linking forrange
8 Lines compiled, 0.2 sec
-bash-2.05b$ ./forrange
Runtime error 201 at $08048141
$08048141
IOW FPC both gives a runtime error as a compiletime warning.
I Forget
>
> What I mean is:
> -- if you declare types as subranges then the program should work
> on all ISO compilers which support integers of size you need
> (if the compiler do not support the size you should get compile
> time error)
> -- GPC support 64 bit integers.
>
> So you can write a program that can ran on 32-bit PC and on CDC-6400
> using 48-bit integers. Of course, Turbo Pascal is limited to 32bits,
> so you can not magically coerce to handle larger numbers.
That's kind of the problem I'm having...
Regular integers aren't enough because they may be 16 or 32 bit.
In the begining, I was satisfied to just use GPC.
It compiles okay under mine. And it did so with the minimal number of
changes.
However, somebody has pointed out that it doesn't compile with older
versions. And somebody has pointed out that it doesn't compile with newer
versions.
Just basically sheer luck that I happen to have a version it compiles okay
under.
Then, of course, Scott has stressed that the program has a few other ISO
issues.
So I'm having to make changes. Far more changes than what I'd like.
I had originally wished the program would run okay under P4, UCSD or some
other compiler of the period. Just for the nostalgia.
So basically, that's what I'm working on now. Not just to get it to run
under TurboPascal (where I'm doing the changes, so I can use the debugger),
but to make it work on almost all of those old compilers.
Make 'everybody' happy by making more than the minimal changes.
That means dealing with all the goto's that may or may not cause a problem
on various versions of Pascal. Most of those were rather easy to get rid
of. Even the problem one (which newer gpc's don't like) was easy to get rid
of, since I know the program so well. The few that are remaining should be
okay.
It means dealing with the variant records. There was even a hidden 16/32
bit issue there, probably due to the original author's need to clear the
entire 60 bit cdc word and not just the part that held the set.
That also means dealing with the very real chance that integers are going to
be 16 bit (15 bit unsigned). (I don't even want to consider the chance that
somebody will run this on a 12 bit PDP!)
I was going to use REAL, because I figured that'd be enough. But I was a
bit surprised to learn that Pascal (even ISO pascal) doesn't even make a
minimum requirment for the sizes.
I truely was surprised by that. Sure, I did know that in the old days,
things were done like that. But I thought ISO and extended ISO were new
enough they would have known better.
So my options are a bit limited here.
I could just stay with 16/15 bit integers. Except that the program will be
run on modern hardware which is fast enough that the 16/15 bit nature will
quickly become a problem. (For example, the FNODEL variable, which controls
how deep to search. Limiting it to 16 bit means only a few seconds of
search.)
So, I have to either chose to leave some stuff at 15 bit unsigned integer
and just tell people not to expect too much from the program.
Or I can make some extra changes to let it run more reasonably.
And regardless, I'm going to have to deal with the board evaluation. I can
create a legal (but unlikely) position that will require 33 bits of unsigned
integer. So a regular signed int of at least 34 bits.
We've been using 32 bit integers for so long that it's easy to forget that
some systems had odd sizes. Such as the CDC's 48 bit integers. (And they
didn't document that as a problem, either....)
I can either do a couple of 16 bit ints and a few tricks to get it to fit.
Or I can use a REAL and hope for the best.
***Update...
It took me about 3 hours total, but I finally came up with a 16 bit integer
version of the MBEVAL routine that I was satisfied with. That was a pretty
critical change. It's now possible to run the program on a version of
Pascal which doesn't even have a REAL, or only a very small one. It depends
only on 16 bit integers. I had to do some DIV and MOD's, but they are by
64, so those can be done efficiently if the compiler chooses to. (Unless
somebody tries to run this thing on a decimal machine...[grin])
So the user now has a choice of which version to run.
> So, compilers are allowed to have limits and if the compiler have too
> small limit then bad luck. But you have portable way to ask for bigger
And most are going to be 'out of luck'.... The reality is that this program
is NOT designed for modern computers and modern compilers. It was designed
for older systems and slower systems. (The CDC 6400 only did about 10 mips.
That's about what a 25mhz 386 system did 20 years ago. And only half what
the 486/25 could do.)
There's no reason to run this program on full modern systems at full speed.
Let's be blunt... there are better chess programs available! John
Stanback's famous one from the mid 80's is in the public domain. Heck, even
I've written programs that could probably beat this one (due to reduced
performance of Chess 0.5 due to the clumsy nature of the bit boards.)
But it will be run on modern systems. Even under emulators, it'll still be
faster than it would have back in 1978.
So the program is really designed for smaller and/or older systems. And
that means dealing with a few more issues.