Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-17 Thread Seongbae Park (박성배, 朴成培)
On 10/14/07, Darryl L. Miles [EMAIL PROTECTED] wrote: Hello, On SPARC there is an ABI that is V8+ which allows the linking (and mixing) of V8 ABI but makes uses of features of 64bit UltraSparc CPUs (that were not available in the older 32bit only CPUs). Admittedly looking at the way this

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-16 Thread Michael Meissner
On Tue, Oct 16, 2007 at 12:53:13AM +0200, Andi Kleen wrote: Actually no. In 32-bit mode, double is aligned on a 4 byte boundary, not an 8 byte boundary, unless you use -malign-double, which breaks the ABI. This has been a 'feature' of the original ATT 386 System V ABI that Linux uses

RE: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-16 Thread Dave Korn
On 15 October 2007 23:53, Andi Kleen wrote: int main(void) { double x; printf(%d\n, __alignof__(x)); return 0; } ~ gcc -m32 -o t t.c t.c: In function ‘main’: t.c:5: warning: incompatible implicit declaration of built-in function ‘printf’ I find a call to an

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Andrew Haley
Darryl L. Miles writes: On SPARC there is an ABI that is V8+ which allows the linking (and mixing) of V8 ABI but makes uses of features of 64bit UltraSparc CPUs (that were not available in the older 32bit only CPUs). Admittedly looking at the way this works it could be said that Sun

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Darryl Miles
Andrew Haley wrote: This doesn't sound very different from the small memory model. With the small model, the program and its symbols must be linked in the lower 2 GB of the address space, but pointers are still 64 bits. This is the default model for gcc on GNU/Linux. It would be possible in

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Andrew Haley
Darryl Miles writes: Andrew Haley wrote: This doesn't sound very different from the small memory model. With the small model, the program and its symbols must be linked in the lower 2 GB of the address space, but pointers are still 64 bits. This is the default model for gcc on

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Andi Kleen
Andrew Haley [EMAIL PROTECTED] writes: Reading the gcc documentation would help you here. Section 3.17.13, Intel 386 and AMD x86-64 Options. This is amazing! There is no way that going from the ia32 to (presumably) the x86_64 small model should more than double memory

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Darryl Miles
Andrew Haley wrote: Darryl Miles writes: Andrew Haley wrote: I'm not aware of a small memory model until now, let alone that I maybe actually using it already and that its already what I'm making an inquiry about. Reading the gcc documentation would help you here. Section 3.17.13,

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Richard Guenther
On 10/15/07, Darryl Miles [EMAIL PROTECTED] wrote: Andrew Haley wrote: Darryl Miles writes: Andrew Haley wrote: I'm not aware of a small memory model until now, let alone that I maybe actually using it already and that its already what I'm making an inquiry about. Reading

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Denys Vlasenko
On Monday 15 October 2007 13:18, Darryl Miles wrote: Yes maybe there is a restriction in the ELF format on the maximum executable size but linking has little to do with the issue of improving performance via better linkage ABI rules. Passing function arguments by registers [64bit] verses

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Richard Guenther
On 10/15/07, Denys Vlasenko [EMAIL PROTECTED] wrote: On Monday 15 October 2007 13:18, Darryl Miles wrote: Yes maybe there is a restriction in the ELF format on the maximum executable size but linking has little to do with the issue of improving performance via better linkage ABI rules.

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread tim prince
Richard Guenther wrote: The idea is not exactly new, the main complication is that it would need hacking both the gcc (and glibc) side and the kernel syscall interface. The 32bit compatibility entries cannot be used if you want to align long long and double naturally (which you certainly want,

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Andi Kleen
Richard Guenther [EMAIL PROTECTED] writes: The idea is not exactly new, the main complication is that it would need hacking both the gcc (and glibc) side and the kernel syscall interface. The 32bit compatibility entries cannot be used if you want to align long long and double naturally

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Michael Meissner
On Mon, Oct 15, 2007 at 08:00:53PM +0200, Andi Kleen wrote: Richard Guenther [EMAIL PROTECTED] writes: The idea is not exactly new, the main complication is that it would need hacking both the gcc (and glibc) side and the kernel syscall interface. The 32bit compatibility entries cannot

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Andi Kleen
Actually no. In 32-bit mode, double is aligned on a 4 byte boundary, not an 8 byte boundary, unless you use -malign-double, which breaks the ABI. This has been a 'feature' of the original ATT 386 System V ABI that Linux uses for 32-bit x86 processors. With the SCO mess, it may be hard to

Re: Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-15 Thread Andreas Schwab
Andi Kleen [EMAIL PROTECTED] writes: My gcc doesn't agree with you (I actually checked before posting) Your test is flawed. $ cat align.c #include stddef.h #include stdio.h struct x { unsigned char a[1]; double b; }; int main (void) { printf (%d\n, offsetof (struct x, b)); } $ ./align

Plans for Linux ELF i686+ ABI ? Like SPARC V8+ ?

2007-10-14 Thread Darryl L. Miles
Hello, On SPARC there is an ABI that is V8+ which allows the linking (and mixing) of V8 ABI but makes uses of features of 64bit UltraSparc CPUs (that were not available in the older 32bit only CPUs). Admittedly looking at the way this works it could be said that Sun had a certain about of