[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: how far is SMP from being 64-bit clean?



Nick,

We do realize that some of the SMP code currently makes assumptions
about the size of certain types that will break when compiled using a 64
bit compiler.  We are eventually planning a 64-bit port of the SMP
libraries; however, the time frame has not yet been determined.  We will
keep the list informed as we decide upon a time frame.  If prior to our
decision anyone has contributions we will gladly accept them and try to
incorporate them into the baseline if possible.

Thanks,
Tom Horvath
BAE Systems IT
Tom.Horvath@xxxxxxxxxxxxxx


-----Original Message-----
From: owner-imc-sfl@xxxxxxxxxxxx [mailto:owner-imc-sfl@xxxxxxxxxxxx] On
Behalf Of Nick Hudson
Sent: Friday, December 16, 2005 11:37 AM
To: imc-sfl@xxxxxxxx
Subject: how far is SMP from being 64-bit clean?


Has any qualification been done on the SMP libraries for 64-bit
environments?

I'm trying to build on SMP 2.5 on Fedora Core 3 x86_64, and although the
build
reports no obvious problems, I get errors at run-time which on
inspection seem to
be caused by the fact that there are some pieces of the code which are
not 64-bit
clean.

For example:

SRL_db.c has:
    SRLi_FlipLongs(le_data, numbytes >> 2);

while the function definition in SRL_util.c is:
    void SRLi_FlipLongs(void *data, long numlongs)

i.e. SRL_db.c is assuming that a "long" contains 4 bytes.  Furthermore,
inside
SRLi_FlipLongs(), there is various manipulation going on which also
seems
based on the assumption that a "long" is made up of 32 bits.

A cursory look through the code suggests that there is quite a lot of
usage of
"long"s, many of which appear to have similar problems.  So I wondered
whether
there's anything going on with 64-bit ports, or whether anyone has a
feel
for how pervasive these problems might be?

thanks

nick