From owner-freebsd-alpha Tue Mar 6 1:56:52 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from gw.one.com.au (gw.one.com.au [203.18.85.1]) by hub.freebsd.org (Postfix) with ESMTP id 8BE6937B718 for ; Tue, 6 Mar 2001 01:56:46 -0800 (PST) (envelope-from raymond@one.com.au) Received: from one.com.au (pmo.local [10.18.85.2]) by gw.one.com.au (8.9.2/8.9.2) with SMTP id UAA24786 for freebsd-alpha@FreeBSD.ORG; Tue, 6 Mar 2001 20:11:00 +1000 (EST) (envelope-from raymond@one.com.au) Date: Tue, 6 Mar 2001 20:11:00 +1000 (EST) From: User Raymond Message-Id: <200103061011.UAA24786@gw.one.com.au> Subject: Strange results from compiled alpha code To: freebsd-alpha@FreeBSD.ORG Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Subj: Strange results from compiled alpha code From: raymond@one.com.au To: freebsd-alpha@FreeBSD.ORG Tony Griffiths wrote: > Ray, > > My quess is that you are running into an alignment problem! > > 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 know that with DEC/Compaq cc there is a #pragma and also a compiler switch > to assume_unaligned pointers for cases like this. The code that is > generated is > awfull but the end result is the correct value loaded into the register. I > don't know that the [g]cc equivalent switch is but presume that there is 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 > > Tony Matthew Jacob wrote: > Oh, god.... not MUMPS? Aieee! Run! Run! Run!!! The Medical Database from > Hell...But if it is indeed mumps, it darn well is supposed to work on Alphas > 'coz I believe that Adac Labs switched from Alpha/Vaxen to Alpha/Alpha quite > a while back. > > Generally, this is not really the best forum for this issue as this is not > specifically a list for help in porting applications to Alpha. In your > specific case you need to really spend more time with the assembly output. In > particular if this in general also has problems with Linux/Alpha, it'll have > problems here, and we probably can't spend a lot of time helping you in this > case. > > You haven't given enough info, but you, or somebody, is assuming that a char > array is mapping sensibly to to the structure you're trying to pun it with. > You don't really know how the alpha compiler is possibly padding the short > below. I guess that as my mumps implementation uses structures to address byte strings as a major design factor, it will never be ported to alpha or any other risc architecture - tough about that as I have a few spare alphas and my customers have more of them. They are all going to have to upgrade to cisc machines. Ray Newman --- Original message from Ray Newman dated 6 Mar 2001 --- This refers to FreeBSD 4.2-RELEASE alpha running on an AS200. Sorry for the size of this post - I have attempted to create a small demonstration program but can't seem to. ...anyway, consider the following piece of c source code: typedef struct CSTRING // our string type { short len; // length of it u_char buf[32768]; // and the content } cstring; // end counted string extern u_char *mumpspc; // mumps prog pointer mumpspc = mumpspc + ((cstring *)mumpspc)->len + sizeof(short) + 1; // point past the string and the following gdb output: 975 mumpspc = mumpspc + (gdb) p mumpspc $1 = (u_char *) 0x120096c7f "\002" (gdb) p mumpspc + ((cstring *)mumpspc)->len + sizeof(short) + 1 $2 = (u_char *) 0x120096c84 "<\001" (gdb) set mumpspc = mumpspc + ((cstring *)mumpspc)->len + sizeof(short) + 1 (gdb) p mumpspc $3 = (u_char *) 0x120096c84 "<\001" (gdb) set mumpspc = 0x120096c7f (gdb) p mumpspc $4 = (u_char *) 0x120096c7f "\002" (gdb) s 978 break; (gdb) p mumpspc $5 = (u_char *) 0x12009a982 "" (gdb) set mumpspc = 0x120096c7f (gdb) p mumpspc[0] $6 = 2 '\002' (gdb) p mumpspc[1] $7 = 0 '\000' (gdb) p mumpspc[2] $8 = 52 '4' (gdb) p mumpspc[3] $9 = 50 '2' (gdb) p mumpspc[4] $10 = 0 '\000' (gdb) p mumpspc[5] $11 = 60 '<' It appears that the "set" is ok when interpreted by gdb but the compiled code gives the wrong answer - it seems to ignore the '\000' at mumpspc[1]. This code works OK on the x86 architecture (FreeBSD and linux); doesn't work with linux alpha either and (yes) I know it's horrible code. but - any ideas? Ray Newman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message