Date: Thu, 08 Mar 2001 08:43:11 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: User Raymond <raymond@one.com.au> Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Strange results from compiled alpha code Message-ID: <20010308084311.A17181@gsmx07.alcatel.com.au> In-Reply-To: <200103061011.UAA24786@gw.one.com.au>; from raymond@one.com.au on Tue, Mar 06, 2001 at 08:11:00PM %2B1000 References: <200103061011.UAA24786@gw.one.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Mar-06 20:11:00 +1000, User Raymond <raymond@one.com.au> wrote: >Tony Griffiths wrote: >> In the case you give below, the 'short len' is misaligned on an odd byte >> boundary. This might be the cause of the problem... I suspect that gcc is ignoring the low bit of the address when loading the short. The Compaq CC masks the address so as to create an alignment fault in this case. >> I know that with DEC/Compaq cc there is a #pragma and also a >> compiler switch to assume_unaligned pointers for cases like this. ... >> I don't know that the [g]cc equivalent switch is but presume that >> there is one! Actually, there doesn't appear to be one. >> Alternatively, change the code slightly to ensure that the 'mumpspc' pointer >> is always incremented by an even number of bytes. eg. >> >> mumpspc += ( ((cstring*)mumpspc)->len + sizeof(short) + 2 ) & ~1; /* bump pc If you can't guarantee alignment, then your other option is to totally avoid the use of CSTRING and use code like (assuming little-endian data): short len = mumpspc[0] | (mumpspc[1] << 8); mumpspc = mumpspc + len + sizeof(short) + 1; > I have a few spare alphas and my customers have more of them. Does this mean they're now surplus and about to be disposed of? :-) Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010308084311.A17181>