Re: 2GB userspace limitation in ABI N32

[David Daney <ddaney.cavm@gmail.com>]

On 10/10/2012 10:49 AM, Ronny Meeus wrote:
> This is exactly the platform we are targeting:
> - a Cavium processor
> - running 64bit Linux
> - 4Gb of ram of which almost 3Gb will be used by 1 process (consisting
> of multiple threads)
>
> It would be really great that we could get help from you guys here.
As far as I know, we are not actively working on this.  So, as I see it, 
your options are:
A) Use n64.

B) Do all the work yourself.

C) Pay someone to do the work for you.

David Daney


> Many thanks for the effort you are putting into this.
>
> On Wed, Oct 10, 2012 at 7:34 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> > On 10/10/2012 10:10 AM, Maciej W. Rozycki wrote:
> > > On Wed, 10 Oct 2012, David Daney wrote:
> > >
> > > > The only disadvantage of doing this is that the code will be slightly
> > > > larger/slower as it takes three instructions to load a zero extended
> > > > 32-bit
> > > > pointer verses two for n32-2GB.
> > >
> > >    And of course such code will only run on 64-bit processors that not only
> > > support 64-bit data, but 64-bit addressing as well.
> >
> > That's right.  All of this assumes a fully 64-bit operating system kernel
> > (Linux).
> >
> > It is not really very interesting on 'small' systems that have less than
> > about 1GB of RAM.  And obviously impossible if 64-bit addressing is not
> > supported.
> >
> > So the interesting use cases are 'modern' systems with 4GB or more of ram
> > installed.  And only then for the subset of applications that need more than
> > 2GB of virtual address space but will never need to consider more than 4GB.
> >
> >
> >
> >
> > >   That is implement the
> > > CP0.Status.UX bit rather than CP0.Status.PX only -- the latters are still
> > > compatible with the true n32 ABI.  See also CP0.Config.AT.
> > >
> > >     Maciej