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

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


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.

Tom Horvath
BAE Systems IT

-----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

I'm trying to build on SMP 2.5 on Fedora Core 3 x86_64, and although the
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

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,
SRLi_FlipLongs(), there is various manipulation going on which also
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
there's anything going on with 64-bit ports, or whether anyone has a
for how pervasive these problems might be?