linux-mips
[Top] [All Lists]

Re: [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix)

To: Dominique Quatravaux <dom@kilimandjaro.dyndns.org>
Subject: Re: [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix)
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 15 Apr 2005 11:14:22 +0100
Cc: Peter Horton <pdh@colonel-panic.org>, linux-mips@linux-mips.org
In-reply-to: <425F8776.6080703@kilimandjaro.dyndns.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050414185949.GA5578@skeleton-jack> <425F8776.6080703@kilimandjaro.dyndns.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
On Fri, Apr 15, 2005 at 11:20:54AM +0200, Dominique Quatravaux wrote:

> Just out of curiosity, is there any practical interest in going 64bit on 
> Cobalt besides the fun of it?

Second hand Cobalt MIPS hardware is available fairly cheaply so it's being
used by various Linux developers for doing development work, including
64-bit work.

> One cannot possibly squeeze more than 4 Gb of RAM into a Cobalt box right?

No, the limit is significantly less.  64-bit kernels are advantagous if

 - running N32 or N64 software is desired
 - anything that takes advantage of 64-bit registers or the 32/32 fpr model
 - software is using large amounts of virtual address space.  Process size
   is limited to 2GB which is tight for some of todays codes which do their
   I/O by memory mapping files.
 - and of the course there is the "more inches" factor ;-)

> And doesn't 64 bit mode have costs of its own (doubled i-fetch bandwidth
> for starters)?

Fortunately not double and caches will further blurr the picture - but on
a system with a 32-bit processor and memory bus there will be very
noticable impact.  We're using a bunch of tricks to keep the overhead under
control.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>