On 05/09/2011 07:32 AM, Andrew Haley wrote:
On 05/09/2011 03:28 PM, Ralf Baechle wrote:
On Mon, Feb 21, 2011 at 07:45:41PM +, Richard Sandiford wrote:
David Daney writes:
Background:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is
On 05/09/2011 07:28 AM, Ralf Baechle wrote:
On Mon, Feb 21, 2011 at 07:45:41PM +, Richard Sandiford wrote:
David Daney writes:
Background:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented
On 05/09/2011 03:28 PM, Ralf Baechle wrote:
> On Mon, Feb 21, 2011 at 07:45:41PM +, Richard Sandiford wrote:
>
>> David Daney writes:
>>> Background:
>>>
>>> Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
>>> user virtual memory space. This is due the way MIPS32 memory
On Mon, Feb 21, 2011 at 07:45:41PM +, Richard Sandiford wrote:
> David Daney writes:
> > Background:
> >
> > Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
> > user virtual memory space. This is due the way MIPS32 memory space is
> > segmented. Only the range from 0..2
On 05/06/2011 01:29 AM, Alexandre Oliva wrote:
On Feb 15, 2011, David Daney wrote:
On 02/15/2011 09:56 AM, Alexandre Oliva wrote:
On Feb 14, 2011, David Daney wrote:
So, sorry if this is a dumb question, but wouldn't it be much easier to
keep on using sign-extended addresses, and just ma
On Feb 15, 2011, David Daney wrote:
> On 02/15/2011 09:56 AM, Alexandre Oliva wrote:
>> On Feb 14, 2011, David Daney wrote:
>> So, sorry if this is a dumb question, but wouldn't it be much easier to
>> keep on using sign-extended addresses, and just make sure the kernel
>> never allocates a vir
David Daney writes:
> Background:
>
> Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
> user virtual memory space. This is due the way MIPS32 memory space is
> segmented. Only the range from 0..2^31-1 is available. Pointer
> values are always sign extended.
>
> Because ther
On 02/14/2011 12:29 PM, David Daney wrote:
Background:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented. Only the range from 0..2^31-1 is available. Pointer
values are always sign extended.
Becau
On 02/15/2011 09:32 AM, Joseph S. Myers wrote:
On Mon, 14 Feb 2011, Joe Buck wrote:
On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote:
It seems that this proposal would benefit programs that need more than 2 GB but
less than 4 GB, and for some reason really don't want 64 bit pointer
On 02/15/2011 09:56 AM, Alexandre Oliva wrote:
On Feb 14, 2011, David Daney wrote:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented. Only the range from 0..2^31-1 is available. Pointer
values
On Feb 14, 2011, David Daney wrote:
> Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
> user virtual memory space. This is due the way MIPS32 memory space is
> segmented. Only the range from 0..2^31-1 is available. Pointer
> values are always sign extended.
> The proposed
On Feb 15, 2011, at 12:41 PM, David Daney wrote:
> ...
>>
>>> The main work would be in the compiler toolchain and runtime libraries.
>>
>> You'd also need to update gas for la and dla expansion.
>>
>
> I am counting gas, ld and libc as part of the 'compiler toolchain'
Don't forget GDB.
On 02/14/2011 07:00 PM, Matt Thomas wrote:
On Feb 14, 2011, at 6:50 PM, David Daney wrote:
On 02/14/2011 06:33 PM, Matt Thomas wrote:
On Feb 14, 2011, at 6:22 PM, David Daney wrote:
On 02/14/2011 04:15 PM, Matt Thomas wrote:
I have to wonder if it's worth the effort. The primary problem
On Mon, 14 Feb 2011, Joe Buck wrote:
> On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote:
> > It seems that this proposal would benefit programs that need more than 2 GB
> > but less than 4 GB, and for some reason really don't want 64 bit pointers.
> >
> > This seems like a microscopic
On Feb 14, 2011, at 6:50 PM, David Daney wrote:
> On 02/14/2011 06:33 PM, Matt Thomas wrote:
>>
>> On Feb 14, 2011, at 6:22 PM, David Daney wrote:
>>
>>> On 02/14/2011 04:15 PM, Matt Thomas wrote:
I have to wonder if it's worth the effort. The primary problem I see
is that this
On 02/14/2011 06:33 PM, Matt Thomas wrote:
On Feb 14, 2011, at 6:22 PM, David Daney wrote:
On 02/14/2011 04:15 PM, Matt Thomas wrote:
I have to wonder if it's worth the effort. The primary problem I see
is that this new ABI requires a 64bit kernel since faults through the
upper 2G will go t
On 02/14/2011 06:34 PM, Matt Thomas wrote:
On Feb 14, 2011, at 6:26 PM, David Daney wrote:
On 02/14/2011 06:14 PM, Joe Buck wrote:
On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote:
It seems that this proposal would benefit programs that need more than 2 GB but
less than 4 GB, and
On Feb 14, 2011, at 6:26 PM, David Daney wrote:
> On 02/14/2011 06:14 PM, Joe Buck wrote:
>> On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote:
>>> It seems that this proposal would benefit programs that need more than 2 GB
>>> but less than 4 GB, and for some reason really don't want
On Feb 14, 2011, at 6:22 PM, David Daney wrote:
> On 02/14/2011 04:15 PM, Matt Thomas wrote:
>>
>> I have to wonder if it's worth the effort. The primary problem I see
>> is that this new ABI requires a 64bit kernel since faults through the
>> upper 2G will go through the XTLB miss exception ve
On 02/14/2011 06:14 PM, Joe Buck wrote:
On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote:
It seems that this proposal would benefit programs that need more than 2 GB but
less than 4 GB, and for some reason really don't want 64 bit pointers.
This seems like a microscopically small ma
On 02/14/2011 04:15 PM, Matt Thomas wrote:
On Feb 14, 2011, at 12:29 PM, David Daney wrote:
Background:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented. Only the range from 0..2^31-1 is avai
On Feb 14, 2011, at 9:14 PM, Joe Buck wrote:
> On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote:
>> It seems that this proposal would benefit programs that need more than 2 GB
>> but less than 4 GB, and for some reason really don't want 64 bit pointers.
>>
>> This seems like a micros
On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote:
> It seems that this proposal would benefit programs that need more than 2 GB
> but less than 4 GB, and for some reason really don't want 64 bit pointers.
>
> This seems like a microscopically small market segment. I can't see any
> s
On Feb 14, 2011, at 7:15 PM, Matt Thomas wrote:
>
> On Feb 14, 2011, at 12:29 PM, David Daney wrote:
>
>> Background:
>>
>> Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
>> user virtual memory space. This is due the way MIPS32 memory space is
>> segmented. Only the ran
On Feb 14, 2011, at 12:29 PM, David Daney wrote:
> Background:
>
> Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
> user virtual memory space. This is due the way MIPS32 memory space is
> segmented. Only the range from 0..2^31-1 is available. Pointer
> values are always
Background:
Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
user virtual memory space. This is due the way MIPS32 memory space is
segmented. Only the range from 0..2^31-1 is available. Pointer
values are always sign extended.
Because there are not already enough MIPS ABIs
26 matches
Mail list logo
