Author: Robert Hyatt
Date: 12:30:49 05/21/99
Go up one level in this thread
On May 21, 1999 at 12:33:49, James B. Shearer wrote: >On May 20, 1999 at 00:16:15, Robert Hyatt wrote: > >>On May 19, 1999 at 22:39:24, James B. Shearer wrote: > > <snip> > >>> There are potentially other endian issues. It is easy enough to write >>>a program which only runs correctly on big (or little) endian machines. Perhaps >>>the "stock" DB has no such dependencies but it is not a given. >>> >> >>endian is only an issue _between_ machines. It is transparent on a single >>machine. And if the PCI interface 'hides' this from the PC architecture, >>then no problem would be apparent. Hsu, campbell, etc are not inexperienced >>programmers... any more than folks like Eugene and myself are inexperienced. >>We've had no problems in doing things like making the tablebase stuff work >>across endianness issues... And Crafty is a perfect example where it works >>on either big or little-endian architectures with no problems at all... This >>would seem (to me) to be a minor point that might take a couple of hours to >>resolve, if that... not a budget-affecting issue IMHO. > > Suppose you have a structure which you address as 4*n bytes or as n >32 bit words. If you move to a machine of different endian type the bytes will >not have the expected relationship to the words and your program may fail. >Depending on how pervasive this sort of thing is it may take more than a couple >of hours to resolve particulary if the code was written by someone else. > James B. Shearer Sure... but why would one do this? IE I did it in crafty because of the missing 'firstone()/lastone()' instructions on most computers. But DB isn't a bitmap program and doesn't use those. But more importantly, when I wrote my code I planned on handling both cases when necessary. And since they have run on everything from an RS6000 to the SP, they at least were thinking 'different architectures' (even if both of those are big-endian). IE you'd almost certainly think about a digital Alpha as a potential platform, and that normally runs little-endian although this can be changed to big-endian with a simple status change to the processor. But in the case of DB, _all_ the good stuff is done by the chess chips. IE the chess chips maintain the board position, make/unmake moves, and so forth, even for the software part of the search. Which makes me suspect that they don't have any internal endian issues (most people have no idea what endian issues are, yet they have written hundreds of thousands of lines of code) that might be a problem. But in any case, Hsu said he can do it... so endian problems or not, I assume he can, since I did and I had far more extensive endian issues than they do... And handling 'endianness' on crafty took about 15 minutes to fix... if you look at "boolean.c" you see two versions of everything that is 'sensitive' to this problem... and the right version is selected by compile options. Bob
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.