Author: Robert Hyatt
Date: 20:23:11 05/09/03
Go up one level in this thread
On May 09, 2003 at 12:47:07, Russell Reagan wrote:
>On May 09, 2003 at 10:28:53, Robert Hyatt wrote:
>
>>That's a different issue, called "endianness". However fields within a
>>structure
>>_must_ be ordered exactly as specified by the programmer, and I have _never_
>>found a case where this was not done...
>>
>>With the sole exception of bit-fields...
>
>So was it because I was compiling with gcc instead of MSVC, or because I was on
>an Ultra Sparc instead of a PC?
endian-ness is a different issue. Successive fields of an array are supposed
to be stored in successively increasing memory addresses. Which won't cause
a problem unless you start (on a PC for example) loading a double-word (32 bit
register) from a memory address. Then bytes get scrambled as you mention. This
is why my opening book is not compatible across little-endian to big-endian
architectures in binary form, for example.
But order _within_ a structure is specifically dictated...
> I changed the "endianness" of the move structure
>and all was fine. Actually, there was only a problem with promotions I think.
>Can't remember why. I had a move struct something like:
>
>tyedef struct {
> unsigned char from;
> unsigned char to;
> unsigned char flags;
> unsigned char dummy;
>} MoveStruct;
>
>typedef union {
> MoveStruct move;
> unsigned int bits;
>} Move;
>
>Then I stuffed the promotion piece into 0xf of the flag field, and I had some
>constants that I used:
That highlights the endian issue. You are referencing the 32 bits in two
different ways, and endian issues become noticable...
>
>#define PROMOTION 0xf
>#define CAPTURE 0x10
>#define CASTLE 0x20
>// etc...
>
>I only had to change the endianness of these constants and all worked well
>again.
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.