Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Porting apps - where to start?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on AMD64
View previous topic :: View next topic  
Author Message
phosphonium
n00b
n00b


Joined: 24 Feb 2004
Posts: 7

PostPosted: Mon Mar 01, 2004 11:06 pm    Post subject: Porting apps - where to start? Reply with quote

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
View user's profile Send private message
thumper
Guru
Guru


Joined: 06 Dec 2002
Posts: 550
Location: Venice FL

PostPosted: Tue Mar 02, 2004 12:09 am    Post subject: Reply with quote

This might be a place to start:
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html

George
Back to top
View user's profile Send private message
thither
n00b
n00b


Joined: 04 Feb 2004
Posts: 32

PostPosted: Tue Mar 02, 2004 8:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
phosphonium
n00b
n00b


Joined: 24 Feb 2004
Posts: 7

PostPosted: Tue Mar 02, 2004 10:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
thumper
Guru
Guru


Joined: 06 Dec 2002
Posts: 550
Location: Venice FL

PostPosted: Tue Mar 02, 2004 10:48 pm    Post subject: Reply with quote

Here is another document:
http://www.x86-64.org/documentation/abi.pdf

George
Back to top
View user's profile Send private message
thither
n00b
n00b


Joined: 04 Feb 2004
Posts: 32

PostPosted: Tue Mar 02, 2004 10:51 pm    Post subject: Reply with quote

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! :wink:) 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
View user's profile Send private message
thumper
Guru
Guru


Joined: 06 Dec 2002
Posts: 550
Location: Venice FL

PostPosted: Tue Mar 02, 2004 10:58 pm    Post subject: Reply with quote

Another document on 64bit stuff:

http://www.unix-systems.org/whitepapers/64bit.html

George
Back to top
View user's profile Send private message
thither
n00b
n00b


Joined: 04 Feb 2004
Posts: 32

PostPosted: Wed Mar 03, 2004 12:39 am    Post subject: Reply with quote

Here's an archived version of a now-gone AMD page on x86-64 assembly:

http://web.archive.org/web/20030210070350/http://www.x86-64.org/documentation_folder/assembly
Back to top
View user's profile Send private message
phosphonium
n00b
n00b


Joined: 24 Feb 2004
Posts: 7

PostPosted: Wed Mar 03, 2004 3:29 am    Post subject: Reply with quote

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 :oops:
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
View user's profile Send private message
thither
n00b
n00b


Joined: 04 Feb 2004
Posts: 32

PostPosted: Thu Mar 04, 2004 12:55 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on AMD64 All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum