64-bit and N32 kernel interfaces

64-bit and N32 kernel interfaces

[Ralf Baechle]

(I bcc'ed this to a few people; please followup to linux-mips@linux-mips.org.
I'd like this to be discussed widely before it's cast into stone as everybody
will have to live with this for the years to come.)

Right now the 64-bit kernel interfaces are still pretty much an ad-hoc
approach and can't be considered frozen.  There is now some pressure to
come up with a stable 64-bit API asap.

As first think I want to get rid of all the historic crap we have in
our syscall tables for the 64-bit syscalls.  Let's start here:

#define __NR_syscall                    (__NR_Linux +   0)

Deprecated because can be implemented in userspace.

#define __NR_ioperm                     (__NR_Linux + 101)
#define __NR_iopl                       (__NR_Linux + 110)
#define __NR_vm86                       (__NR_Linux + 113)

i386 braindamage we're never going to support.  So why have it in our
syscall table?

#define __NR_unused59                   (__NR_Linux +  59)
#define __NR_reserved82                 (__NR_Linux +  82)
#define __NR_unused109                  (__NR_Linux + 109)
#define __NR_unused150                  (__NR_Linux + 150)

Unused entries.  Why keep them ...

#define __NR_break                      (__NR_Linux +  17)
#define __NR_stty                       (__NR_Linux +  31)
#define __NR_gtty                       (__NR_Linux +  32)
#define __NR_ftime                      (__NR_Linux +  35)
#define __NR_prof                       (__NR_Linux +  44)
#define __NR_signal                     (__NR_Linux +  48)
#define __NR_mpx                        (__NR_Linux +  56)
#define __NR_ulimit                     (__NR_Linux +  58)
#define __NR_readdir                    (__NR_Linux +  89)
#define __NR_profil                     (__NR_Linux +  98)
#define __NR_modify_ldt                 (__NR_Linux + 123)

Slots that data back to day one of UNIX way before Linux was born.

#define __NR_socketcall                 (__NR_Linux + 102)

Wrapper syscall, obsoleted since quite a while in the 32-bit kernel.

#define __NR_idle                       (__NR_Linux + 112)

Internal syscall, no longer used.

#define __NR_ipc                        (__NR_Linux + 117)

Yet another multiplexor syscall and imho another candidate for getting
rid of.

#define __NR_oldstat                    (__NR_Linux +  18)
#define __NR_umount                     (__NR_Linux +  22)
#define __NR_oldfstat                   (__NR_Linux +  28)
#define __NR_oldlstat                   (__NR_Linux +  84)

Superseeded by newer versions.

#define __NR_uselib                     (__NR_Linux +  86)

a.out support.  Do we really want that.

I probably missed a few.  The primary purpose of this posting is to get a
discussion about the 64-bit syscall interface started.  It's still not
cast into stone so we can modify it as we see fit.  The entire syscall
interface is still open for changes, this includes all structures etc.
Along with a 64-bit ABI we'll also have to deciede about a N32 ABI.

Suggestions, comments etc?

  Ralf

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Ralf Baechle wrote:

> Right now the 64-bit kernel interfaces are still pretty much an ad-hoc
> approach and can't be considered frozen.  There is now some pressure to
> come up with a stable 64-bit API asap.

 Well, they are not really used by anything, yet so they are far from
being frozen.

> As first think I want to get rid of all the historic crap we have in
> our syscall tables for the 64-bit syscalls.  Let's start here:
[...]

 Definitely.

> I probably missed a few.  The primary purpose of this posting is to get a
> discussion about the 64-bit syscall interface started.  It's still not
> cast into stone so we can modify it as we see fit.  The entire syscall
> interface is still open for changes, this includes all structures etc.
> Along with a 64-bit ABI we'll also have to deciede about a N32 ABI.

 It would be nice if we could keep a single set of syscalls for both (n)64
and n32.  The address crop for n32 may be handled the Alpha way.  I will
investigate the topic soon.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Ralf Baechle]

On Wed, Sep 04, 2002 at 04:14:13PM +0200, Maciej W. Rozycki wrote:

> > I probably missed a few.  The primary purpose of this posting is to get a
> > discussion about the 64-bit syscall interface started.  It's still not
> > cast into stone so we can modify it as we see fit.  The entire syscall
> > interface is still open for changes, this includes all structures etc.
> > Along with a 64-bit ABI we'll also have to deciede about a N32 ABI.
> 
>  It would be nice if we could keep a single set of syscalls for both (n)64
> and n32.  The address crop for n32 may be handled the Alpha way.  I will
> investigate the topic soon.

Can you describe how this is handled on the  Alpha?

The primary problem is the differnet calling sequence for o32 and N64.
As it looks we'll be able to use either the o32 function or the native
syscall to implement all of the necessary N32 syscalls.

The question is if we want to reserve another 1000 entries in our already
huge syscall table for N32 or if we got a better solution ...

  Ralf

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Ralf Baechle wrote:

> >  It would be nice if we could keep a single set of syscalls for both (n)64
> > and n32.  The address crop for n32 may be handled the Alpha way.  I will
> > investigate the topic soon.
> 
> Can you describe how this is handled on the  Alpha?

 I'm referring mostly to OSF/1 here as it was first to implement it. 
Linux followed it in the sense it is able to execute OSF/1 binaries marked
as "32-bit", but native ELF binaries used to be fully 64-bit always.  I
think by a popular demand GNU binutils are now able to create "cropped"
Alpha/Linux ELF binaries as well, but this is unverified for sure.  The
implementation is two-fold. 

 First, the static linker (if given the "-taso" option) maps an executable
into the low 31-bit address space (coincidentally, this will probably be
suitable for MIPS as well) and sets a special flag in the executable (it
does it in a weird place, but this is ECOFF and we have suitable flags in
the ELF header already).

 Second, seeing the "31-bit" flag set, the kernel returns any maps
requested within the low 31-bit address space.  This way both shared
libraries (which thus need not be special, i.e. may be regular 64-bit
ones) and areas allocated by mmap() are addressable by the executable.

 To summarize, nothing much complicated.

> The primary problem is the differnet calling sequence for o32 and N64.

 But we handle that already.

> As it looks we'll be able to use either the o32 function or the native
> syscall to implement all of the necessary N32 syscalls.

 The (n)64 versions seem suitable and the o32 ones do not as n32 only
crops addresses to 32-bit -- data may still be 64-bit (e.g. file position
pointers).

> The question is if we want to reserve another 1000 entries in our already
> huge syscall table for N32 or if we got a better solution ...

 Aaarrgh, no more entries, please...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Ralf Baechle]

On Wed, Sep 04, 2002 at 05:19:51PM +0200, Maciej W. Rozycki wrote:

> > The primary problem is the differnet calling sequence for o32 and N64.
> 
>  But we handle that already.

Well, N32 is yet another case.  Have to look into details again but some
MIPS guy recently pointed out to me that there are a few syscalls which
for N32 cannot be handled by the o32 or N64 syscall entry as they are right
now.

> > The question is if we want to reserve another 1000 entries in our already
> > huge syscall table for N32 or if we got a better solution ...
> 
>  Aaarrgh, no more entries, please...

Understandable reflex :)

Btw, I did just chat with a Redhat guy.  They say they're basically finished
and are just waiting for us.  Which means we need to deciede fast ...

I'll be on the Linux Kongress for the next few days so I'll not be able to
answer as quickly as I'd like to but I'll try to read me email as often
as I can.

  Ralf

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Ralf Baechle wrote:

> Well, N32 is yet another case.  Have to look into details again but some
> MIPS guy recently pointed out to me that there are a few syscalls which
> for N32 cannot be handled by the o32 or N64 syscall entry as they are right
> now.

 Which ones?  Maybe we might just add some padding to structures.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Carsten Langgaard]

"Maciej W. Rozycki" wrote:

> On Wed, 4 Sep 2002, Ralf Baechle wrote:
>
> > >  It would be nice if we could keep a single set of syscalls for both (n)64
> > > and n32.  The address crop for n32 may be handled the Alpha way.  I will
> > > investigate the topic soon.
> >
> > Can you describe how this is handled on the  Alpha?
>
>  I'm referring mostly to OSF/1 here as it was first to implement it.
> Linux followed it in the sense it is able to execute OSF/1 binaries marked
> as "32-bit", but native ELF binaries used to be fully 64-bit always.  I
> think by a popular demand GNU binutils are now able to create "cropped"
> Alpha/Linux ELF binaries as well, but this is unverified for sure.  The
> implementation is two-fold.
>
>  First, the static linker (if given the "-taso" option) maps an executable
> into the low 31-bit address space (coincidentally, this will probably be
> suitable for MIPS as well) and sets a special flag in the executable (it
> does it in a weird place, but this is ECOFF and we have suitable flags in
> the ELF header already).
>
>  Second, seeing the "31-bit" flag set, the kernel returns any maps
> requested within the low 31-bit address space.  This way both shared
> libraries (which thus need not be special, i.e. may be regular 64-bit
> ones) and areas allocated by mmap() are addressable by the executable.
>
>  To summarize, nothing much complicated.
>
> > The primary problem is the differnet calling sequence for o32 and N64.
>
>  But we handle that already.
>
> > As it looks we'll be able to use either the o32 function or the native
> > syscall to implement all of the necessary N32 syscalls.
>
>  The (n)64 versions seem suitable and the o32 ones do not as n32 only
> crops addresses to 32-bit -- data may still be 64-bit (e.g. file position
> pointers).
>

Please notice, that a 'long' is 32-bit for n32, so we need to do the same
conversion for a lot of syscalls, as we already do for o32.


>
> > The question is if we want to reserve another 1000 entries in our already
> > huge syscall table for N32 or if we got a better solution ...
>
>  Aaarrgh, no more entries, please...
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Carsten Langgaard wrote:

> >  The (n)64 versions seem suitable and the o32 ones do not as n32 only
> > crops addresses to 32-bit -- data may still be 64-bit (e.g. file position
> > pointers).
> 
> Please notice, that a 'long' is 32-bit for n32, so we need to do the same
> conversion for a lot of syscalls, as we already do for o32.

 Any reference?  AFAIK, long is 64-bit for n32 and only void * is 32-bit. 
It doesn't make sense otherwise. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Daniel Jacobowitz]

On Thu, Sep 05, 2002 at 11:23:33AM +0200, Maciej W. Rozycki wrote:
> On Thu, 5 Sep 2002, Carsten Langgaard wrote:
> 
> > >  The (n)64 versions seem suitable and the o32 ones do not as n32 only
> > > crops addresses to 32-bit -- data may still be 64-bit (e.g. file position
> > > pointers).
> > 
> > Please notice, that a 'long' is 32-bit for n32, so we need to do the same
> > conversion for a lot of syscalls, as we already do for o32.
> 
>  Any reference?  AFAIK, long is 64-bit for n32 and only void * is 32-bit. 
> It doesn't make sense otherwise. 

Nope, it looks like long is 32-bit according to GCC.  It means that
64-bit quantities (long long, structures) can go in integer registers.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 64-bit and N32 kernel interfaces

[Jun Sun]

Ralf Baechle wrote:
> On Wed, Sep 04, 2002 at 04:14:13PM +0200, Maciej W. Rozycki wrote:
> 
> The primary problem is the differnet calling sequence for o32 and N64.
> As it looks we'll be able to use either the o32 function or the native
> syscall to implement all of the necessary N32 syscalls.

For 64bit kernel, do we intend to have one syscall table that support o32, n32 
and n64 altogether?  Or we will have multiple tables for them?

> 
> The question is if we want to reserve another 1000 entries in our already
> huge syscall table for N32 or if we got a better solution ...
>

It seems n32 can be naturally implemented through n64 syscalls, although I am 
sure there are some nasty details to work out.

Where can I find n32/n64 spec?

Jun

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Wed, 4 Sep 2002, Jun Sun wrote:

> For 64bit kernel, do we intend to have one syscall table that support o32, n32 
> and n64 altogether?  Or we will have multiple tables for them?

 There are two tables now, one for o32, currently used when executing o32
userland and the other one ready for native userland.  They can't be
unified as their semantics differ. 

> Where can I find n32/n64 spec?

 Search 'http://techpubs.sgi.com/' and see
'ftp://oss.sgi.com/pub/linux/mips/doc/ABI/'. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Ralf Baechle]

On Wed, Sep 04, 2002 at 10:32:42AM -0700, Jun Sun wrote:

> > The primary problem is the differnet calling sequence for o32 and N64.
> > As it looks we'll be able to use either the o32 function or the native
> > syscall to implement all of the necessary N32 syscalls.
> 
> For 64bit kernel, do we intend to have one syscall table that support o32,
> n32 and n64 altogether?  Or we will have multiple tables for them?

Several approach to solve that problem.  Adding another 1000 entries - which
will cost 8000 bytes of memory that will be mostly zeros.  Having wrappers
for each function that do the appropriate argument and result convertion
is another.  etc.

> > The question is if we want to reserve another 1000 entries in our already
> > huge syscall table for N32 or if we got a better solution ...
> 
> It seems n32 can be naturally implemented through n64 syscalls, although I am 
> sure there are some nasty details to work out.

Unfortunately there are ...

> Where can I find n32/n64 spec?

mipsabi.org which is no longer online.  Anyway, I don't think there is a
formal published N32 spec.  And this whole thread is about the syscall
interface.  That isn't part of any ABI spec.

  Ralf

Re: 64-bit and N32 kernel interfaces

[Kjeld Borch Egevang]

On Wed, 4 Sep 2002, Ralf Baechle wrote:

...
> Several approach to solve that problem.  Adding another 1000 entries - which
> will cost 8000 bytes of memory that will be mostly zeros.  Having wrappers
> for each function that do the appropriate argument and result convertion
> is another.  etc.

Ralf, that's not true. In our current 64-bit kernel we have 234 entries 
for N64 which uses 8*234 = 1872 bytes. N32 has 241 entries using 1928 
bytes. Even in an embedded environment that's not a lot of memory.


/Kjeld

-- 
_    _ ____  ___                       Mailto:kjelde@mips.com
|\  /|||___)(___    MIPS Denmark       Direct: +45 44 86 55 85
| \/ |||    ____)   Lautrupvang 4 B    Switch: +45 44 86 55 55
  TECHNOLOGIES      DK-2750 Ballerup   Fax...: +45 44 86 55 56
                    Denmark            http://www.mips.com/

Re: 64-bit and N32 kernel interfaces

[Kjeld Borch Egevang]

On Wed, 4 Sep 2002, Ralf Baechle wrote:

...
> Several approach to solve that problem.  Adding another 1000 entries - which
> will cost 8000 bytes of memory that will be mostly zeros.  Having wrappers
> for each function that do the appropriate argument and result convertion
> is another.  etc.

Ralf, that's not true. In our current 64-bit kernel we have 234 entries 
for N64 which uses 8*234 = 1872 bytes. N32 has 241 entries using 1928 
bytes. Even in an embedded environment that's not a lot of memory.


/Kjeld

-- 
_    _ ____  ___                       Mailto:kjelde@mips.com
|\  /|||___)(___    MIPS Denmark       Direct: +45 44 86 55 85
| \/ |||    ____)   Lautrupvang 4 B    Switch: +45 44 86 55 55
  TECHNOLOGIES      DK-2750 Ballerup   Fax...: +45 44 86 55 56
                    Denmark            http://www.mips.com/

Re: 64-bit and N32 kernel interfaces

[Jay Carlson]

On Wed, 4 Sep 2002, Ralf Baechle wrote:

> #define __NR_uselib                     (__NR_Linux +  86)
>
> a.out support.  Do we really want that.

Well, it's support for Linux-a.out-style shared libraries, which are
actually binary-format independent.  Quick summary of how they work in
ELF:

The file argument to uselib must have 1 or 2 program headers.  Exactly
one of them must be PT_LOAD.  That segment is loaded at the fixed
virtual address specified in in the header.  It's marked readable,
writable, executable, and any BSS region is zeroed.

I contemplated using uselib(2) in snow and decided that I wanted
multiple segments to support text and rodata being read-only.  I
figured that attempting to communicate the read-only nature of the
maps to the VM could elicit more efficient behavior.

Anyway, now that we have ELF interpreters you can get one library
loaded into core for you by the kernel.  That library can define a
more reasonable version of uselib in userspace...

I guess my point is that even the tiny set of people doing statically
linked shared libraries will probably avoid this syscall.

Jay

Re: 64-bit and N32 kernel interfaces

[Ralf Baechle]

On Wed, Sep 04, 2002 at 03:56:45PM +0200, Ralf Baechle wrote:

Additional changes I've done to my working version:

> As first think I want to get rid of all the historic crap we have in
> our syscall tables for the 64-bit syscalls.  Let's start here:
> 
> #define __NR_syscall                    (__NR_Linux +   0)
> 
> Deprecated because can be implemented in userspace.
> 
> #define __NR_ioperm                     (__NR_Linux + 101)
> #define __NR_iopl                       (__NR_Linux + 110)
> #define __NR_vm86                       (__NR_Linux + 113)
> 
> i386 braindamage we're never going to support.  So why have it in our
> syscall table?
> 
> #define __NR_unused59                   (__NR_Linux +  59)
> #define __NR_reserved82                 (__NR_Linux +  82)
> #define __NR_unused109                  (__NR_Linux + 109)
> #define __NR_unused150                  (__NR_Linux + 150)
> 
> Unused entries.  Why keep them ...
> 
> #define __NR_break                      (__NR_Linux +  17)
> #define __NR_stty                       (__NR_Linux +  31)
> #define __NR_gtty                       (__NR_Linux +  32)
> #define __NR_ftime                      (__NR_Linux +  35)
> #define __NR_prof                       (__NR_Linux +  44)
> #define __NR_signal                     (__NR_Linux +  48)
> #define __NR_mpx                        (__NR_Linux +  56)
> #define __NR_ulimit                     (__NR_Linux +  58)
> #define __NR_readdir                    (__NR_Linux +  89)
> #define __NR_profil                     (__NR_Linux +  98)
> #define __NR_modify_ldt                 (__NR_Linux + 123)

One more for the same cathegory:

#define __NR_lock                       (__NR_Linux +  53)

> Slots that data back to day one of UNIX way before Linux was born.
> 
> #define __NR_socketcall                 (__NR_Linux + 102)
> 
> Wrapper syscall, obsoleted since quite a while in the 32-bit kernel.
> 
> #define __NR_idle                       (__NR_Linux + 112)
> 
> Internal syscall, no longer used.
> 
> #define __NR_ipc                        (__NR_Linux + 117)

This implies eleven new entries for:

__NR_semget
__NR_semop
__NR_semctl
__NR_msgget
__NR_msgsnd
__NR_msgrcv
__NR_msgctl
__NR_shmget
__NR_shmat
__NR_shmdt
__NR_shmctl

> Yet another multiplexor syscall and imho another candidate for getting
> rid of.
> 
> #define __NR_oldstat                    (__NR_Linux +  18)
> #define __NR_umount                     (__NR_Linux +  22)
> #define __NR_oldfstat                   (__NR_Linux +  28)
> #define __NR_oldlstat                   (__NR_Linux +  84)
> 
> Superseeded by newer versions.
> 
> #define __NR_uselib                     (__NR_Linux +  86)
> 
> a.out support.  Do we really want that.
> 
> I probably missed a few.  The primary purpose of this posting is to get a
> discussion about the 64-bit syscall interface started.  It's still not
> cast into stone so we can modify it as we see fit.  The entire syscall
> interface is still open for changes, this includes all structures etc.
> Along with a 64-bit ABI we'll also have to deciede about a N32 ABI.
> 
> Suggestions, comments etc?

  Ralf

Re: 64-bit and N32 kernel interfaces

[Ralf Baechle]

On Mon, Sep 16, 2002 at 03:01:52PM +0200, Ralf Baechle wrote:

More chainswing ...

> > As first think I want to get rid of all the historic crap we have in
> > our syscall tables for the 64-bit syscalls.  Let's start here:
> > 
> > #define __NR_syscall                    (__NR_Linux +   0)
> > 
> > Deprecated because can be implemented in userspace.
> > 
> > #define __NR_ioperm                     (__NR_Linux + 101)
> > #define __NR_iopl                       (__NR_Linux + 110)
> > #define __NR_vm86                       (__NR_Linux + 113)
> > 
> > i386 braindamage we're never going to support.  So why have it in our
> > syscall table?
> > 
> > #define __NR_unused59                   (__NR_Linux +  59)
> > #define __NR_reserved82                 (__NR_Linux +  82)
> > #define __NR_unused109                  (__NR_Linux + 109)
> > #define __NR_unused150                  (__NR_Linux + 150)
> > 
> > Unused entries.  Why keep them ...
> > 
> > #define __NR_break                      (__NR_Linux +  17)
> > #define __NR_stty                       (__NR_Linux +  31)
> > #define __NR_gtty                       (__NR_Linux +  32)
> > #define __NR_ftime                      (__NR_Linux +  35)
> > #define __NR_prof                       (__NR_Linux +  44)
> > #define __NR_signal                     (__NR_Linux +  48)
> > #define __NR_mpx                        (__NR_Linux +  56)
> > #define __NR_ulimit                     (__NR_Linux +  58)
> > #define __NR_readdir                    (__NR_Linux +  89)
> > #define __NR_profil                     (__NR_Linux +  98)
> > #define __NR_modify_ldt                 (__NR_Linux + 123)
> 
> One more for the same cathegory:
> 
> #define __NR_lock                       (__NR_Linux +  53)
> 
> > Slots that data back to day one of UNIX way before Linux was born.
> > 
> > #define __NR_socketcall                 (__NR_Linux + 102)
> > 
> > Wrapper syscall, obsoleted since quite a while in the 32-bit kernel.
> > 
> > #define __NR_idle                       (__NR_Linux + 112)
> > 
> > Internal syscall, no longer used.
> > 
> > #define __NR_ipc                        (__NR_Linux + 117)
> 
> This implies eleven new entries for:
> 
> __NR_semget
> __NR_semop
> __NR_semctl
> __NR_msgget
> __NR_msgsnd
> __NR_msgrcv
> __NR_msgctl
> __NR_shmget
> __NR_shmat
> __NR_shmdt
> __NR_shmctl
> 
> > Yet another multiplexor syscall and imho another candidate for getting
> > rid of.
> > 
> > #define __NR_oldstat                    (__NR_Linux +  18)
> > #define __NR_umount                     (__NR_Linux +  22)
> > #define __NR_oldfstat                   (__NR_Linux +  28)
> > #define __NR_oldlstat                   (__NR_Linux +  84)
> > 
> > Superseeded by newer versions.
> > 
> > #define __NR_uselib                     (__NR_Linux +  86)
> > 
> > a.out support.  Do we really want that.
> > 
> > I probably missed a few.  The primary purpose of this posting is to get a
> > discussion about the 64-bit syscall interface started.  It's still not
> > cast into stone so we can modify it as we see fit.  The entire syscall
> > interface is still open for changes, this includes all structures etc.
> > Along with a 64-bit ABI we'll also have to deciede about a N32 ABI.

llseek, pread64/pwrite64, getdent64 are no longer needed as their standard
counterparts are already 64 bit.

Modern libc doesn't use the old style signal calls __NR_sigaction,
__NR_sigsuspend, __NR_sigpending, __NR_sigprocmask.  That means
__NR_sigreturn can also go.

__NR_sgetmask and __NR_ssetmask are only capable of dealing with signal masks
of at most bitsof(long) and thus have become useless and replaced by
sigprocmask(2).

__NR_waitpid can be implemented on top of wait(2).

__NR_stime can be implemented on top of settimeofday(2).

__NR_nice can be implemented on top of getpriority / setpriority and was
a stupid interface anyway.

__NR_recv can be implemented on recvfrom(2) and __NR_send using sendfrom(2).

  Ralf

Re: 64-bit and N32 kernel interfaces

[Tor Arntsen]

On Sep 5, 10:23, "Maciej W. Rozycki" wrote:
>On Thu, 5 Sep 2002, Carsten Langgaard wrote:
[...]
>> Please notice, that a 'long' is 32-bit for n32, so we need to do the same
>> conversion for a lot of syscalls, as we already do for o32.
>
> Any reference?  AFAIK, long is 64-bit for n32 and only void * is 32-bit. 
>It doesn't make sense otherwise. 

On SGI/Irix n32 long and void* are 32-bit, only long long is 64-bit.
On SGI/Irix n64 long and void* are 64-bit too.

-Tor

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Tor Arntsen wrote:

> > Any reference?  AFAIK, long is 64-bit for n32 and only void * is 32-bit. 
> >It doesn't make sense otherwise. 
> 
> On SGI/Irix n32 long and void* are 32-bit, only long long is 64-bit.
> On SGI/Irix n64 long and void* are 64-bit too.

 Hmm, it looks pretty much broken if that's true (especially given long
long was non-standard untile very recently).  I'll check the docs, yet.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Kevin D. Kissell]

From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
>

> On Thu, 5 Sep 2002, Tor Arntsen wrote:
> 
> > > Any reference?  AFAIK, long is 64-bit for n32 and only void * is 32-bit. 
> > >It doesn't make sense otherwise. 
> > 
> > On SGI/Irix n32 long and void* are 32-bit, only long long is 64-bit.
> > On SGI/Irix n64 long and void* are 64-bit too.
> 
>  Hmm, it looks pretty much broken if that's true (especially given long
> long was non-standard untile very recently).  I'll check the docs, yet.

n32 has the same data types as o32, an "ILP32" C integer 
model.  n64 is a pretty normal "LP64" C integer model.

What do you consider to be broken, and how would you
have preferred it to have been done?

            Regards,

            Kevin K.

Re: 64-bit and N32 kernel interfaces

[Kevin D. Kissell]

From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
>

> On Thu, 5 Sep 2002, Tor Arntsen wrote:
> 
> > > Any reference?  AFAIK, long is 64-bit for n32 and only void * is 32-bit. 
> > >It doesn't make sense otherwise. 
> > 
> > On SGI/Irix n32 long and void* are 32-bit, only long long is 64-bit.
> > On SGI/Irix n64 long and void* are 64-bit too.
> 
>  Hmm, it looks pretty much broken if that's true (especially given long
> long was non-standard untile very recently).  I'll check the docs, yet.

n32 has the same data types as o32, an "ILP32" C integer 
model.  n64 is a pretty normal "LP64" C integer model.

What do you consider to be broken, and how would you
have preferred it to have been done?

            Regards,

            Kevin K.

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Kevin D. Kissell wrote:

> n32 has the same data types as o32, an "ILP32" C integer 
> model.  n64 is a pretty normal "LP64" C integer model.
> 
> What do you consider to be broken, and how would you
> have preferred it to have been done?

 For n32 it would be natural to have:

- sizeof(int) = 32

- sizeof(long) = 64

- sizeof(void *) = 32

as the underlying hardware directly supports 64-bit operations (n32
requires at least MIPS III).  Thus there is no penalty for 64-bit
arithmetics and if one uses longs one normally wants the largest native
integer type -- using long long typically (i.e. on most platforms) implies
double-precision arithmetics with all the drawbacks, especially for the
division and multiplication operations. 

 With 32-bit long on 64-bit hardware software has no easy way to figure
using 64-bit operations is still optimal performance-wise.  I can't see
any technical benefit from such a setup -- is there any?  I doubt it. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Hartvig Ekner]

I don't know the ultimate reasons why SGI choose ILP32 for n32, but one
could certainly be portability.

As defined, n32 provides all the benefits of 64-bit data (yes, you have
to use long long to get to it), and 100% backward compatability with 
o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data
file compatability with o32 as all structures are exactly identical between
o32 and n32.

/Hartvig


Maciej W. Rozycki writes:
> 
> On Thu, 5 Sep 2002, Kevin D. Kissell wrote:
> 
> > n32 has the same data types as o32, an "ILP32" C integer 
> > model.  n64 is a pretty normal "LP64" C integer model.
> > 
> > What do you consider to be broken, and how would you
> > have preferred it to have been done?
> 
>  For n32 it would be natural to have:
> 
> - sizeof(int) = 32
> 
> - sizeof(long) = 64
> 
> - sizeof(void *) = 32
> 
> as the underlying hardware directly supports 64-bit operations (n32
> requires at least MIPS III).  Thus there is no penalty for 64-bit
> arithmetics and if one uses longs one normally wants the largest native
> integer type -- using long long typically (i.e. on most platforms) implies
> double-precision arithmetics with all the drawbacks, especially for the
> division and multiplication operations. 
> 
>  With 32-bit long on 64-bit hardware software has no easy way to figure
> using 64-bit operations is still optimal performance-wise.  I can't see
> any technical benefit from such a setup -- is there any?  I doubt it. 
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 
> 
> 


-- 
 _    _   _____  ____     Hartvig Ekner        Mailto:hartvige@mips.com
 |\  /| | |____)(____                          Direct: +45 4486 5503
 | \/ | | |     _____)    MIPS Denmark         Switch: +45 4486 5555
T E C H N O L O G I E S   http://www.mips.com  Fax...: +45 4486 5556

Re: 64-bit and N32 kernel interfaces

[Hartvig Ekner]

I don't know the ultimate reasons why SGI choose ILP32 for n32, but one
could certainly be portability.

As defined, n32 provides all the benefits of 64-bit data (yes, you have
to use long long to get to it), and 100% backward compatability with 
o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data
file compatability with o32 as all structures are exactly identical between
o32 and n32.

/Hartvig


Maciej W. Rozycki writes:
> 
> On Thu, 5 Sep 2002, Kevin D. Kissell wrote:
> 
> > n32 has the same data types as o32, an "ILP32" C integer 
> > model.  n64 is a pretty normal "LP64" C integer model.
> > 
> > What do you consider to be broken, and how would you
> > have preferred it to have been done?
> 
>  For n32 it would be natural to have:
> 
> - sizeof(int) = 32
> 
> - sizeof(long) = 64
> 
> - sizeof(void *) = 32
> 
> as the underlying hardware directly supports 64-bit operations (n32
> requires at least MIPS III).  Thus there is no penalty for 64-bit
> arithmetics and if one uses longs one normally wants the largest native
> integer type -- using long long typically (i.e. on most platforms) implies
> double-precision arithmetics with all the drawbacks, especially for the
> division and multiplication operations. 
> 
>  With 32-bit long on 64-bit hardware software has no easy way to figure
> using 64-bit operations is still optimal performance-wise.  I can't see
> any technical benefit from such a setup -- is there any?  I doubt it. 
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 
> 
> 


-- 
 _    _   _____  ____     Hartvig Ekner        Mailto:hartvige@mips.com
 |\  /| | |____)(____                          Direct: +45 4486 5503
 | \/ | | |     _____)    MIPS Denmark         Switch: +45 4486 5555
T E C H N O L O G I E S   http://www.mips.com  Fax...: +45 4486 5556

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Hartvig Ekner wrote:

> I don't know the ultimate reasons why SGI choose ILP32 for n32, but one
> could certainly be portability.

 It depends on how you define "portability".  While it might help some
broken software, it will hurt good one.

> As defined, n32 provides all the benefits of 64-bit data (yes, you have
> to use long long to get to it), and 100% backward compatability with 

 So you can't use long to keep a file position pointer (off_t is quite a
new invention) and have to go for long long, for example?  Weird and
definitely doesn't help portability. 

> o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data

 Thay should be fixed, instead.  Using "void *" as a data container
doesn't work in general and one who does so should be banished.  And the
other way round, there is no problem -- if one keeps 32-bit pointers in
64-bit longs, there is no bit loss. 

> file compatability with o32 as all structures are exactly identical between
> o32 and n32.

 Why don't use o32 as is then, instead of creating a slightly different
ABI?  If some software needs binary data to be identical, then it has to
select fixed-size types, e.g. int32_t, explicitly.  While int32_t and
friends are quite a new standard, other ways were used for years to set up
such aspects, e.g. autoconf, imake, hand-written system-specific
preprocessor macros, etc., etc.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Daniel Jacobowitz]

On Thu, Sep 05, 2002 at 04:54:09PM +0200, Maciej W. Rozycki wrote:
> On Thu, 5 Sep 2002, Hartvig Ekner wrote:
> 
> > I don't know the ultimate reasons why SGI choose ILP32 for n32, but one
> > could certainly be portability.
> 
>  It depends on how you define "portability".  While it might help some
> broken software, it will hurt good one.
> 
> > As defined, n32 provides all the benefits of 64-bit data (yes, you have
> > to use long long to get to it), and 100% backward compatability with 
> 
>  So you can't use long to keep a file position pointer (off_t is quite a
> new invention) and have to go for long long, for example?  Weird and
> definitely doesn't help portability. 
> 
> > o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data
> 
>  Thay should be fixed, instead.  Using "void *" as a data container
> doesn't work in general and one who does so should be banished.  And the
> other way round, there is no problem -- if one keeps 32-bit pointers in
> 64-bit longs, there is no bit loss. 
> 
> > file compatability with o32 as all structures are exactly identical between
> > o32 and n32.
> 
>  Why don't use o32 as is then, instead of creating a slightly different
> ABI?  If some software needs binary data to be identical, then it has to
> select fixed-size types, e.g. int32_t, explicitly.  While int32_t and
> friends are quite a new standard, other ways were used for years to set up
> such aspects, e.g. autoconf, imake, hand-written system-specific
> preprocessor macros, etc., etc.

No - the point is that all data types have the same size in N32.  It
was created explicitly as a transitional sop for people who didn't want
to fix their code, but wanted a performance increase from their 64-bit
hardware.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:

> No - the point is that all data types have the same size in N32.  It
> was created explicitly as a transitional sop for people who didn't want
> to fix their code, but wanted a performance increase from their 64-bit
> hardware.

 Well, what's the performance increase of n32 over o32?  The increased
number of argument registers?  I doubt it's noticeable in most cases.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Daniel Jacobowitz]

On Thu, Sep 05, 2002 at 05:10:51PM +0200, Maciej W. Rozycki wrote:
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
> 
> > No - the point is that all data types have the same size in N32.  It
> > was created explicitly as a transitional sop for people who didn't want
> > to fix their code, but wanted a performance increase from their 64-bit
> > hardware.
> 
>  Well, what's the performance increase of n32 over o32?  The increased
> number of argument registers?  I doubt it's noticeable in most cases.

N32 supports saving and restoring 64-bit registers, which O32 doesn't -
according to some comments in GCC, O32 is in fact incompatible with
using 64-bit operations.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:

> N32 supports saving and restoring 64-bit registers, which O32 doesn't -
> according to some comments in GCC, O32 is in fact incompatible with
> using 64-bit operations.

 But that old software wouldn't benefit as it didn't perform 64-bit
operations unless manually coded in software using narrower data types. 
There is no 64-bit C data type for o32 and long long is quite a recent
invention -- it didn't exist in the 80s or even early 90s. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Daniel Jacobowitz]

On Thu, Sep 05, 2002 at 06:16:49PM +0200, Maciej W. Rozycki wrote:
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
> 
> > N32 supports saving and restoring 64-bit registers, which O32 doesn't -
> > according to some comments in GCC, O32 is in fact incompatible with
> > using 64-bit operations.
> 
>  But that old software wouldn't benefit as it didn't perform 64-bit
> operations unless manually coded in software using narrower data types. 
> There is no 64-bit C data type for o32 and long long is quite a recent
> invention -- it didn't exist in the 80s or even early 90s. 

Right.  You don't recompile and get a magic bullet speed improvement
(well, you do, but not a drastic one I think); but you don't recompile
and get a magic bullet binary incompatibility either.  Then you add
64-bit pieces by hand as necessary.

That's my understanding anyway.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:

> Right.  You don't recompile and get a magic bullet speed improvement
> (well, you do, but not a drastic one I think); but you don't recompile
> and get a magic bullet binary incompatibility either.  Then you add
> 64-bit pieces by hand as necessary.

 Huh?  I can somewhat understand the "rebuild and forget" approach,
especially in cases suitably experienced stuff was lost meanwhile.  But if
you start to fiddle with some old crap, you may equally well run
's/long/int/' within it, what's a deal. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Daniel Jacobowitz]

On Thu, Sep 05, 2002 at 06:33:53PM +0200, Maciej W. Rozycki wrote:
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
> 
> > Right.  You don't recompile and get a magic bullet speed improvement
> > (well, you do, but not a drastic one I think); but you don't recompile
> > and get a magic bullet binary incompatibility either.  Then you add
> > 64-bit pieces by hand as necessary.
> 
>  Huh?  I can somewhat understand the "rebuild and forget" approach,
> especially in cases suitably experienced stuff was lost meanwhile.  But if
> you start to fiddle with some old crap, you may equally well run
> 's/long/int/' within it, what's a deal. 

Eh?  That's not even sort-of practical on an application of significant
size.  It would be a nightmare.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:

> >  Huh?  I can somewhat understand the "rebuild and forget" approach,
> > especially in cases suitably experienced stuff was lost meanwhile.  But if
> > you start to fiddle with some old crap, you may equally well run
> > 's/long/int/' within it, what's a deal. 
> 
> Eh?  That's not even sort-of practical on an application of significant
> size.  It would be a nightmare.

 Oh yes, I tend to forget there are people who do not write clean software
-- if the size of an object is critical e.g. for a system-independent
binary data interface, there should be a data type for it defined in a
single place somewhere.  But who cares?  "It's not me who'll have to fix
it later, so why should I bother putting more effort into it."

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Kevin D. Kissell]

From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
> 
> > N32 supports saving and restoring 64-bit registers, which O32 doesn't -
> > according to some comments in GCC, O32 is in fact incompatible with
> > using 64-bit operations.
> 
>  But that old software wouldn't benefit as it didn't perform 64-bit
> operations unless manually coded in software using narrower data types. 
> There is no 64-bit C data type for o32 and long long is quite a recent
> invention -- it didn't exist in the 80s or even early 90s.

Well, actually,. as I recall from those days, "long long" *did*
exist in the very late 1980's, though it wasn't part of any standard,
and there were variant names proposed for it.  Certainly it had 
been  invented by the time the first 64-bit MIPS chips came out 
in 1991/1992.  Maybe not in GCC, but in other complers of 
the period.  The concensus was that "long" should be the largest
element that could be loaded/stored/used in an integer register,
which meant 32-bits for most of us in those days, yet there was
a need to represent 64-bit integers for the clearest expression
of some algorithms.  MIPS was rather unique in having made 
a "binary compatible" transition from 32 to 64-bits.  Does anyone 
know what's being done with C integer binding on the AMD
"Hammer" architecture?  They're looking at the same problem,
10 years further on.

            Kevin K.

Re: 64-bit and N32 kernel interfaces

[Kevin D. Kissell]

From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
> 
> > N32 supports saving and restoring 64-bit registers, which O32 doesn't -
> > according to some comments in GCC, O32 is in fact incompatible with
> > using 64-bit operations.
> 
>  But that old software wouldn't benefit as it didn't perform 64-bit
> operations unless manually coded in software using narrower data types. 
> There is no 64-bit C data type for o32 and long long is quite a recent
> invention -- it didn't exist in the 80s or even early 90s.

Well, actually,. as I recall from those days, "long long" *did*
exist in the very late 1980's, though it wasn't part of any standard,
and there were variant names proposed for it.  Certainly it had 
been  invented by the time the first 64-bit MIPS chips came out 
in 1991/1992.  Maybe not in GCC, but in other complers of 
the period.  The concensus was that "long" should be the largest
element that could be loaded/stored/used in an integer register,
which meant 32-bits for most of us in those days, yet there was
a need to represent 64-bit integers for the clearest expression
of some algorithms.  MIPS was rather unique in having made 
a "binary compatible" transition from 32 to 64-bits.  Does anyone 
know what's being done with C integer binding on the AMD
"Hammer" architecture?  They're looking at the same problem,
10 years further on.

            Kevin K.

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Kevin D. Kissell wrote:

> of some algorithms.  MIPS was rather unique in having made 
> a "binary compatible" transition from 32 to 64-bits.  Does anyone 
> know what's being done with C integer binding on the AMD
> "Hammer" architecture?  They're looking at the same problem,
> 10 years further on.

 Well, SPARC is another mature example that works this way.  And the
PA-RISC, PPC, and S390 ports may have similar experiences, but I don't
know the details.  MIPS is quite unique with the n32 ABI as the ABI is
64-bit but with 32-bit addressing.  I'll see if and how they handle such a
case, but it's likely they have plain 32-bit and plain 64-bit ABIs only.

 BTW, I've found an interesting type size analyzis in the SUSv2 at: 
'http://www.usenix.org/publications/login/standards/10.data.html' and they
simply opt for LP64 for 64-bit systems. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Ralf Baechle]

On Thu, Sep 05, 2002 at 06:16:49PM +0200, Maciej W. Rozycki wrote:

> > N32 supports saving and restoring 64-bit registers, which O32 doesn't -
> > according to some comments in GCC, O32 is in fact incompatible with
> > using 64-bit operations.
> 
>  But that old software wouldn't benefit as it didn't perform 64-bit
> operations unless manually coded in software using narrower data types. 
> There is no 64-bit C data type for o32 and long long is quite a recent
> invention -- it didn't exist in the 80s or even early 90s. 

Not in any standard but de facto in existence since a long time.  Anyway,
the changes in floating point in the N32 are so substancial that there
are projects that say without N32 or N64 they don't even need to start
working on their projects.

  Ralf

Re: 64-bit and N32 kernel interfaces

[Hartvig Ekner]

Maciej W. Rozycki writes:
> 
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
> 
> > No - the point is that all data types have the same size in N32.  It
> > was created explicitly as a transitional sop for people who didn't want
> > to fix their code, but wanted a performance increase from their 64-bit
> > hardware.
> 
>  Well, what's the performance increase of n32 over o32?  The increased
> number of argument registers?  I doubt it's noticeable in most cases.

The technical benefits of n32 over o32 are:

* More argument registers => less memory traffic, less D-cache use,
	=> faster code

* 64-bit datapath of CPU can be utilized with big impact on certain
  applications

* 32 floating point registers instead of 16 (and more efficient
  parameter passing as well)

/Hartvig

Re: 64-bit and N32 kernel interfaces

[Hartvig Ekner]

Maciej W. Rozycki writes:
> 
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
> 
> > No - the point is that all data types have the same size in N32.  It
> > was created explicitly as a transitional sop for people who didn't want
> > to fix their code, but wanted a performance increase from their 64-bit
> > hardware.
> 
>  Well, what's the performance increase of n32 over o32?  The increased
> number of argument registers?  I doubt it's noticeable in most cases.

The technical benefits of n32 over o32 are:

* More argument registers => less memory traffic, less D-cache use,
	=> faster code

* 64-bit datapath of CPU can be utilized with big impact on certain
  applications

* 32 floating point registers instead of 16 (and more efficient
  parameter passing as well)

/Hartvig

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Hartvig Ekner wrote:

> The technical benefits of n32 over o32 are:
> 
> * More argument registers => less memory traffic, less D-cache use,
> 	=> faster code

 Generally, since the stack is usually frequently accessed it tends to
stick in the primary cache so the extra cost is null.  But a set
associative cache with an LFU or at least an LRU replacement algorithm is
needed for this to be effective.  Too bad such caches are rare for MIPS
processors...  So the win might actually be bigger than it should be.

> * 64-bit datapath of CPU can be utilized with big impact on certain
>   applications

 But an old program doesn't make use of them, so it won't normally
benefit.  For new development it's true, but you don't absolutely need to
cut long to 32 bits for new stuff. 

> * 32 floating point registers instead of 16 (and more efficient
>   parameter passing as well)

 Yes, that's true -- I missed it previously.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Thu, 5 Sep 2002, Hartvig Ekner wrote:
> 
> > The technical benefits of n32 over o32 are:
[snip]
> > * 64-bit datapath of CPU can be utilized with big impact on certain
> >   applications
> 
>  But an old program doesn't make use of them, so it won't normally
> benefit.

An o32 program using compiler synthesized 64 bit integers will
do so when recompiled for n32.


Thiemo

Re: 64-bit and N32 kernel interfaces

[Ralf Baechle]

On Thu, Sep 05, 2002 at 05:10:51PM +0200, Maciej W. Rozycki wrote:

> > No - the point is that all data types have the same size in N32.  It
> > was created explicitly as a transitional sop for people who didn't want
> > to fix their code, but wanted a performance increase from their 64-bit
> > hardware.
> 
>  Well, what's the performance increase of n32 over o32?  The increased
> number of argument registers?  I doubt it's noticeable in most cases.

That's a minor optimization.  More important is the availability of
MIPS III/IV and MIPS64 instruction sets which means 64-bit integer registers
and 32 64-bit double precission fp registers.

  Ralf

Re: 64-bit and N32 kernel interfaces

[Daniel Jacobowitz]

On Thu, Sep 05, 2002 at 04:09:11PM +0200, Maciej W. Rozycki wrote:
> On Thu, 5 Sep 2002, Kevin D. Kissell wrote:
> 
> > n32 has the same data types as o32, an "ILP32" C integer 
> > model.  n64 is a pretty normal "LP64" C integer model.
> > 
> > What do you consider to be broken, and how would you
> > have preferred it to have been done?
> 
>  For n32 it would be natural to have:
> 
> - sizeof(int) = 32
> 
> - sizeof(long) = 64
> 
> - sizeof(void *) = 32
> 
> as the underlying hardware directly supports 64-bit operations (n32
> requires at least MIPS III).  Thus there is no penalty for 64-bit
> arithmetics and if one uses longs one normally wants the largest native
> integer type -- using long long typically (i.e. on most platforms) implies
> double-precision arithmetics with all the drawbacks, especially for the
> division and multiplication operations. 
> 
>  With 32-bit long on 64-bit hardware software has no easy way to figure
> using 64-bit operations is still optimal performance-wise.  I can't see
> any technical benefit from such a setup -- is there any?  I doubt it. 

Well, here's one - while we all know that C code which assumes a
pointer and int are the same size is buggy, it makes everything
substantially simpler if long and void* are the same size.  That's true
for both normal LP64 and ILP32 models.  Since n32 was mostly a
transitional tool (SGI was primarily interested in n64 as I understand
it), I imagine they wanted path of least damage...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:

> Well, here's one - while we all know that C code which assumes a
> pointer and int are the same size is buggy, it makes everything
> substantially simpler if long and void* are the same size.  That's true
> for both normal LP64 and ILP32 models.  Since n32 was mostly a
> transitional tool (SGI was primarily interested in n64 as I understand
> it), I imagine they wanted path of least damage...

 I see.  But do we need the SGI's traditional n32 in Linux then?  Having
most experiences in the server world I'd vote for a pure 64-bit setup
(with an optional ability to execute o32 stuff), but I understand there
are people who consider it a waste of resources.

 Therefore, I believe we may choose another way and use an IP32 (if I
encode it right) data model, where we have 32-bit ints and pointers for
these who are short on memory, 64-bit longs for the maximum native
precision (you don't choose long for the type for your favourite "i" loop
counter unless you really need it) and an ability to have double-precision
128-bit long longs in the distant future (if needed). 

 Any opinions?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Daniel Jacobowitz]

On Thu, Sep 05, 2002 at 05:08:06PM +0200, Maciej W. Rozycki wrote:
> On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:
> 
> > Well, here's one - while we all know that C code which assumes a
> > pointer and int are the same size is buggy, it makes everything
> > substantially simpler if long and void* are the same size.  That's true
> > for both normal LP64 and ILP32 models.  Since n32 was mostly a
> > transitional tool (SGI was primarily interested in n64 as I understand
> > it), I imagine they wanted path of least damage...
> 
>  I see.  But do we need the SGI's traditional n32 in Linux then?  Having
> most experiences in the server world I'd vote for a pure 64-bit setup
> (with an optional ability to execute o32 stuff), but I understand there
> are people who consider it a waste of resources.
> 
>  Therefore, I believe we may choose another way and use an IP32 (if I
> encode it right) data model, where we have 32-bit ints and pointers for
> these who are short on memory, 64-bit longs for the maximum native
> precision (you don't choose long for the type for your favourite "i" loop
> counter unless you really need it) and an ability to have double-precision
> 128-bit long longs in the distant future (if needed). 
> 
>  Any opinions?

My opinion is that N32 is good enough for people who are short on
space.  We have too many MIPS ABIs already!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Daniel Jacobowitz wrote:

> My opinion is that N32 is good enough for people who are short on
> space.  We have too many MIPS ABIs already!

 You meant "there are", I suppose, as we (i.e. Linux) only really have a
single one right now -- o32.  And my opinion is we should carefully choose
additional ABIs for the 64-bit port based on technical superiority and
flexibility and do not blindly follow what others do.  To achieve this, we
do not even need to fiddle with the toolchain -- ELF file formats are
sufficient, binutils don't care and gcc may be set up as needed in a
configuration header.  All that matters is the kernel and libc. 

 That said, I do not assert my address/data model propsal is optimal --
this is subject to a discussion, but please keep non-technical arguments
away. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Thiemo Seufer]

Maciej W. Rozycki wrote:
[snip]
>  I see.  But do we need the SGI's traditional n32 in Linux then?  Having
> most experiences in the server world I'd vote for a pure 64-bit setup
> (with an optional ability to execute o32 stuff), but I understand there
> are people who consider it a waste of resources.
> 
>  Therefore, I believe we may choose another way and use an IP32 (if I
> encode it right) data model, where we have 32-bit ints and pointers for
> these who are short on memory, 64-bit longs for the maximum native
> precision (you don't choose long for the type for your favourite "i" loop
> counter unless you really need it)

Following this line of argumentation, there isn't much software which
could benefit from 64 bit longs. :-) And 64 bit long long is available
for such software anyway.

> and an ability to have double-precision
> 128-bit long longs in the distant future (if needed). 

So the linux n64 would be incompatible to SGI's, too? (It would be
weird if the n64 long long was smaller than the n32 one).

>  Any opinions?

It would mean to create two new ABIs, gaining little benefit but
being incompatible from a (C-)programmers POV. And we already have
too many MIPS ABIs.


Thiemo

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Thiemo Seufer wrote:

> >  Therefore, I believe we may choose another way and use an IP32 (if I
> > encode it right) data model, where we have 32-bit ints and pointers for
> > these who are short on memory, 64-bit longs for the maximum native
> > precision (you don't choose long for the type for your favourite "i" loop
> > counter unless you really need it)
> 
> Following this line of argumentation, there isn't much software which
> could benefit from 64 bit longs. :-) And 64 bit long long is available
> for such software anyway.

 It's up to a programmer to judge what kind of processing he needs.  For
computing, 64-bit integer arithmetics is indeed useful from time to time
only and 32-bit one often suffices.

> So the linux n64 would be incompatible to SGI's, too? (It would be
> weird if the n64 long long was smaller than the n32 one).

 Why would anyone care?  Do you want to run IRIX binaries on Linux?  And
at the source level, you have autoconf or <stdint.h> as you can't
arbitrarily assume any type sizes for any portable code. 

> It would mean to create two new ABIs, gaining little benefit but
> being incompatible from a (C-)programmers POV. And we already have
> too many MIPS ABIs.

 What programmer's POV?  Does a programmer write a program for MIPS?  No,
unless he writes a kernel or a libc.  A normal programmer just codes a
program in C for a *nix-type system and if he wants any portability, he
needs to follow universal guidelines.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Thiemo Seufer]

Maciej W. Rozycki wrote:
[snip]
> > So the linux n64 would be incompatible to SGI's, too? (It would be
> > weird if the n64 long long was smaller than the n32 one).
> 
>  Why would anyone care?  Do you want to run IRIX binaries on Linux?  And
> at the source level, you have autoconf or <stdint.h> as you can't
> arbitrarily assume any type sizes for any portable code. 

Not everyone uses autoconf, and if you call "long long" a recent
addition then the use of <stdint.h> isn't safe, too.

Using the same data types allows at least to choose the appropriate
typedefs without caring about the underlying OS.

> > It would mean to create two new ABIs, gaining little benefit but
> > being incompatible from a (C-)programmers POV. And we already have
> > too many MIPS ABIs.
> 
>  What programmer's POV?  Does a programmer write a program for MIPS?  No,
> unless he writes a kernel or a libc.  A normal programmer just codes a
> program in C for a *nix-type system and if he wants any portability, he
> needs to follow universal guidelines.

World isn't as perfect as you claim. And for non-broken code it's
nearly irrelevant if the 64 bit integer type is called "long" or
"long long".

About 128 bit integers: Most OS'es use "long long" already for
64 bit integers, which means there will be something like
"quad long" for 128 bit integers (if these are needed).


Thiemo

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Thu, 5 Sep 2002, Thiemo Seufer wrote:

> > at the source level, you have autoconf or <stdint.h> as you can't
> > arbitrarily assume any type sizes for any portable code. 
> 
> Not everyone uses autoconf, and if you call "long long" a recent
> addition then the use of <stdint.h> isn't safe, too.

 That is not an excuse, sorry.  You need not to use autoconf or <stdint.h>
if you don't want to -- you may use a different tool or simply group all
tweakable settings in config.h and ask a user to edit it manually like
autors of old programs did.

> Using the same data types allows at least to choose the appropriate
> typedefs without caring about the underlying OS.

 It doesn't.  It is unsafe to assume it in general and it's even more
unsafe for MIPS where we have at least three C models and you do not know
in advance which one will a person doing a build choose. 

> >  What programmer's POV?  Does a programmer write a program for MIPS?  No,
> > unless he writes a kernel or a libc.  A normal programmer just codes a
> > program in C for a *nix-type system and if he wants any portability, he
> > needs to follow universal guidelines.
> 
> World isn't as perfect as you claim. And for non-broken code it's
> nearly irrelevant if the 64 bit integer type is called "long" or
> "long long".

 World isn't perfect, but it would be beneficial if at least we tried to
keep it as good as we can.

> About 128 bit integers: Most OS'es use "long long" already for
> 64 bit integers, which means there will be something like
> "quad long" for 128 bit integers (if these are needed).

 We'll see, but I wouldn't bet on it.  Personally, I'd rather see "long
long" to be a double-precision (not necessarily 128-bit) type universally. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Thiemo Seufer]

Maciej W. Rozycki wrote:
[snip]
> > Using the same data types allows at least to choose the appropriate
> > typedefs without caring about the underlying OS.
> 
>  It doesn't.  It is unsafe to assume it in general and it's even more
> unsafe for MIPS where we have at least three C models and you do not know
> in advance which one will a person doing a build choose. 

It's knowing the ABI vs. ABI + OS (or OS-specific ABI-variant, if you
want to call it different).

> > >  What programmer's POV?  Does a programmer write a program for MIPS?  No,
> > > unless he writes a kernel or a libc.  A normal programmer just codes a
> > > program in C for a *nix-type system and if he wants any portability, he
> > > needs to follow universal guidelines.
> > 
> > World isn't as perfect as you claim. And for non-broken code it's
> > nearly irrelevant if the 64 bit integer type is called "long" or
> > "long long".
> 
>  World isn't perfect, but it would be beneficial if at least we tried to
> keep it as good as we can.

I agree. And I believe in the "least surprise" principle, which means
we shouldn't deviate from widely known conventions without good reason.
I still don't see the advantage of a 64 bit long in n32.


Thiemo

Re: 64-bit and N32 kernel interfaces

[Maciej W. Rozycki]

On Fri, 6 Sep 2002, Thiemo Seufer wrote:

> I agree. And I believe in the "least surprise" principle, which means
> we shouldn't deviate from widely known conventions without good reason.
> I still don't see the advantage of a 64 bit long in n32.

 Well, for me it's more surprising to see long not sufficient to contain
data of the register width than to see the width of long being different
from the width of a pointer.  The latter I've already seen (both ways). 
The former is new to me.  Others may have different experiences, though. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: 64-bit and N32 kernel interfaces

[Ralf Baechle]

On Thu, Sep 05, 2002 at 05:08:06PM +0200, Maciej W. Rozycki wrote:

>  I see.  But do we need the SGI's traditional n32 in Linux then?  Having
> most experiences in the server world I'd vote for a pure 64-bit setup
> (with an optional ability to execute o32 stuff), but I understand there
> are people who consider it a waste of resources.

In the SGI world o32 basically has been killed - there no more 32-bit
processors shipped since many years.  So most SGI MIPS systems are
running N32 code by standard and N64 is available as an option which only
is used for the small number of applications that actually are going to
gain from it.  O32 is deprecated; at this time it's just historical garbage.

  Ralf

Re: 64-bit and N32 kernel interfaces

[Dominic Sweetman]

Ralf Baechle (ralf@linux-mips.org) writes:

> In the SGI world o32 basically has been killed - there no more 32-bit
> processors shipped since many years.  So most SGI MIPS systems are
> running N32 code by standard and N64 is available as an option which only
> is used for the small number of applications that actually are going to
> gain from it.  O32 is deprecated; at this time it's just historical garbage.

True: but just to emphasise that's SGI.

There are still lots of 32-bit MIPS CPUs about (which can't run
n32/n64, of course) which may want to run Linux, and for now o32 is
all that is available to them.

Dominic