On Saturday 29 January 2005 02:21 pm, Boyd Stephen Smith Jr. wrote:
> 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
I bow in your general direction... :')
--
******************************************************************************
Registered Linux User Number 185956
FSF Associate Member number 2340 since 05/20/2004
Join me in chat at #linux-users on irc.freenode.net
Buy an Xbox for $149.00, run linux on it and Microsoft loses $150.00!
2:33pm up 111 days, 22:19, 8 users, load average: 0.10, 0.13, 0.09
--
[email protected] mailing list
