Date: Tue, 6 Mar 2001 20:11:00 +1000 (EST) From: User Raymond <raymond@one.com.au> To: freebsd-alpha@FreeBSD.ORG Subject: Strange results from compiled alpha code Message-ID: <200103061011.UAA24786@gw.one.com.au>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103061011.UAA24786>