| View previous topic :: View next topic |
| Author |
Message |
phosphonium
n00b
Joined: 24 Feb 2004
Posts: 7
|
 Posted: Mon Mar 01, 2004 11:06 pm Post subject: Porting apps - where to start? |
 |
|
Hey all,
I recently upgraded my system to amd64, and installed gentoo stage2 over the weekend. I've got a functional X workstation running now, and I'd like to work on porting software from x86 to amd64. My intent is to use this machine as a scientific workstation, for quantum chemical calculation. I understand that I will probably have to modify source for this to happen, and although this is reasonable I don't really know where to start. Can any of you recommend documents, forums, or people that I might find helpful in trying to bring packages in the x86/~x86 trees into amd64?
Many thanks,
phos |
|
| Back to top |
|
 |
thumper
Guru
Joined: 06 Dec 2002
Posts: 554
Location: Venice FL
|
|
| Back to top |
|
|
thither
n00b
Joined: 04 Feb 2004
Posts: 32
|
| Posted: Tue Mar 02, 2004 8:03 pm Post subject: |
|
|
I've been trying to figure out some details for this too; as far as C programming goes, the AMD64 docs, while interesting, are pretty thin gruel. It seems to me that the main thing to watch out for is assumptions about word sizes (and, obviously, inline assembly). To wit:
| Code: |
sizeof... 64-bit mode 32-bit mode
--------- ----------- -----------
void * 8 4
long 8 4
long double 16 12
|
Edit:oops - as phosphonium noted, I got the long double values backwards - corrected them just now.
There's some good background on this at this excerpt from the O'Reilly linux device driver book. One thing I'm still not terribly clear on is what exactly 32-bit emulation mode does on the AMD64 (ie, how to trigger it, and most importantly, how to interface between 64 and 32-bit modes).
Last edited by thither on Tue Mar 02, 2004 11:06 pm; edited 1 time in total |
|
| Back to top |
|
|
phosphonium
n00b
Joined: 24 Feb 2004
Posts: 7
|
| Posted: Tue Mar 02, 2004 10:07 pm Post subject: |
|
|
Interesting. I wonder why they chose a 12-bit long double in 64-bit mode, and a 16-bit long double in 32 bit mode? This seems like it's just asking for trouble.
As far as C porting goes, though (and I agree that the AMD docs seem more geared towards assembly programming), how much is there to do? Should issues only arise out of problems such as architure specific assumptions (ie data types) and inline assembly? How about working with FORTRAN?
[/i] |
|
| Back to top |
|
|
thumper
Guru
Joined: 06 Dec 2002
Posts: 554
Location: Venice FL
|
|
| Back to top |
|
|
thither
n00b
Joined: 04 Feb 2004
Posts: 32
|
| Posted: Tue Mar 02, 2004 10:51 pm Post subject: |
|
|
| phosphonium wrote: | | a 12-bit long double in 64-bit mode, and a 16-bit long double in 32 bit mode |
These are, as I'm sure you know, byte values. (12-bit long doubles really would be asking for trouble!  ) But you're right, I actually printed those values in reverse - long doubles are 12 bytes in 32-bit mode and 16 bytes in 64-bit mode, which makes rather more sense to me.
In my (limited) experience so far, a lot of the problems I've seen stem from casting ints to pointers and vice-versa. (I'm not sure why people seem so inclined to do this.)
The other obvious problems tend to involve projects that make assumptions about word size - the example that springs immediately to mind is ndiswrapper, which uses "int" when they really mean "32-bit word". Projects which genericize their basic types to things like u_int_32 tend to be easier to work with (since they usually have already been ported to other 64-bit architectures).
For a project like ndiswrapper, which proably never expected to run on a non-Wintel architecture, it's easy to see why they would make the 32-bit assumptions that they did. No doubt as more people start running 64-bit wintel linux boxes these types of programs will become more portable in general.
There is a (newish) standard header "stdint.h" which defines some generic types for this purpose, see this lkml post for more info.
I've had no experience at all with Fortran. |
|
| Back to top |
|
|
thumper
Guru
Joined: 06 Dec 2002
Posts: 554
Location: Venice FL
|
|
| Back to top |
|
|
thither
n00b
Joined: 04 Feb 2004
Posts: 32
|
|
| Back to top |
|
|
phosphonium
n00b
Joined: 24 Feb 2004
Posts: 7
|
| Posted: Wed Mar 03, 2004 3:29 am Post subject: |
|
|
| Quote: |
These are, as I'm sure you know, byte values. (12-bit long doubles really would be asking for trouble! ) But you're right, I actually printed those values in reverse - long doubles are 12 bytes in 32-bit mode and 16 bytes in 64-bit mode, which makes rather more sense to me.
|
Ah yes... bit, byte, what's the difference between friends 
But yes, 16 bytes in 64 / 12 bytes in 32 does make a bit more sense
| Quote: | | The other obvious problems tend to involve projects that make assumptions about word size - the example that springs immediately to mind is ndiswrapper, which uses "int" when they really mean "32-bit word". Projects which genericize their basic types to things like u_int_32 tend to be easier to work with (since they usually have already been ported to other 64-bit architectures). |
So is this something that will be helped at all (if nothing else with builds failing rather than making corrupted binaries) by using -Wall and -Wstrict-prototypes in my CFLAGS? It should be noted that I'm not a programmer; I just learn what I need to do neat chemistry. I am in a community with a lot of CS, though, so I figure there's no better time and place to start learning.
FWIW, I've now successfully gotten BLAS, LAPACK, and MPQC-2.2.0 compile cleanly by simply adding amd64 to the keywords It's like magic  (LAPACK and BLAS are linear algebra libraries, MPQC is a quantum-chemistry suite). I'm still working through the included validation routines for MPQC, but all of the ones I've tried thus far look good. This makes me very happy. [/quote] |
|
| Back to top |
|
|
thither
n00b
Joined: 04 Feb 2004
Posts: 32
|
| Posted: Thu Mar 04, 2004 12:55 am Post subject: |
|
|
| phosphonium wrote: | | is this something that will be helped at all (if nothing else with builds failing rather than making corrupted binaries) by using -Wall and -Wstrict-prototypes in my CFLAGS? |
I'd say that's not a bad idea. You could even go with -pedantic. Of course if you just go by warnings then you might end up spending more time fixing somebody else's sloppy coding style than fixing 32/64 bit problems.
If you're concerned with the compiled programs being absolutely correct, you can always compile with -m32 and just get the 32-bit version of the code instead, and then run it emulated... |
|
| Back to top |
|
|
|
Gentoo on AMD64
