On Saturday 29 January 2005 00:30, Uwe Thiem wrote:
> On Saturday 29 January 2005 07:09, William Kenworthy wrote:
> > On a local lug, a statement was made that not a lot of 64 bit software
> > is available for the amd chips yet. With gentoo at least, isnt this
> > largely untrue: if you have the arch set correctly, are you not building
> > 64 bit software, and only 32 bit where 32 bit specific instructions are
> > specified???
>
> You are right.
In general, open-source code is more likely to work in both 64-bit and 32-bit
environments. Of course, if you are downloading binaries, most providers are
still going to be shipping i586, or even i386, binaries. Those are, of
course, 64-bit. With gentoo, everything is compiled so you get 64-bit by
default. [I don't actually know what/how to compile 32-bit on amd64, since
I'm still running intel chips.]
More are more code is getting 64-bit clean. Unfortunately, compatability
(even writing to standards) are not given high priority when programming is
taught so you end up with some programms that don't even know the issues
below are issues.
> There is a small problem, though. Many developers (I am not talking about
> the gentoo developers but those of the original software) make assumptions
> which are true on 32-bit systems only. Like sizeof( int ) == sizeof( void *
> ) or such. Or they assume that long has a certain size while the C/C++
> standards only specify:
> 16 bit <= short <= int <= long <= long long
Actually, it also specifies 32-bit <= long <= long long, but the point is that
many many C programs are written with different assumptions.
[Also, it should be noted, that the C standard doesn't specify that actual
storage is in contiguous 2's complement binary digits -- it just specifies
the behavior of the operators (which will always seem to work on contigious
2's-complement binary digits) and the ranges covered by the data types.]
[For example, if there was some good reason for computing to switch to a
trinary system, or some other base for storage, C would work, it would just
be very slow (since all the operators would no longer closely correspond to
assembly code).]
> Such software will compile (probably with a bunch of warnings) but won't
> run properly. Fortunately, this becomes rarer nowadays.
Another problem that you may run into is compatibility. From what I
understand, 32-bit binaries can use on an amd system unmodified (at least in
theory). Unfortunately, a 32-bit program using a 64-bit library (or
vice-versa) might not work.
Specifically, if the library declares a type like:
typedef struct Vector_t {
void * data;
size_t length;
} Vector;
Then the offset of length is 8 in 64-bit code and 4 in 32-bit code. If both
32-bit code and 64-code attempt to manipulate the length member directly, all
heck will break lose (either the 32-bit code will be mucking the in pointer
or the 64-bit code will be writing off the end of the struct, depending on
who allocated it).
If the library is properly designed (so that all access to structure members
are through calls into the library code) *AND* the program is not designed
poorly (using pointer tricks to access library private data [sometimes this
is wanted as a work-around for some flaw in the library]), then all is good
and the 32-bit and 64-bit code will agree. Unfortunately, this isn't always
the case.
[Of course, if your structs/unions never hold pointers or nothing after (and
including) the first pointer is accesses outside the library, no problems
mate!]
It isn't entirely uncommon for C libraries to allow direct access to at least
some of their struct's members (since providing acessors and mutators is so
mind numbing and using them is so long-winded), so this bug will bite a lot
of programs.
So, if you have a single program that either won't compile in 64-bits or
crashes in 64-bit mode, so that you want to use it in 32-bit mode, make sure
all it's [DEEP] dependencies are 32-bit too, or you may cause more problems
than you solve.
It should be noted that the compatibility issue can arrise even when both
pieces of code are written exactly to the C standard. [Of course, if both
are written exactly to the standard, you should be able to make sure they are
both compiled with the same bit-ness.]
--
[email protected] mailing list
