| To: | Dominic Sweetman <dom@mips.com> |
|---|---|
| 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:25:48 +0100 |
| Cc: | Dominique Quatravaux <dom@kilimandjaro.dyndns.org>, Peter Horton <pdh@colonel-panic.org>, linux-mips@linux-mips.org |
| In-reply-to: | <16991.38112.114688.697412@arsenal.mips.com> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <20050414185949.GA5578@skeleton-jack> <425F8776.6080703@kilimandjaro.dyndns.org> <20050415101422.GB5414@linux-mips.org> <16991.38112.114688.697412@arsenal.mips.com> |
| Sender: | linux-mips-bounce@linux-mips.org |
| User-agent: | Mutt/1.4.1i |
On Fri, Apr 15, 2005 at 11:18:08AM +0100, Dominic Sweetman wrote: > > > And doesn't 64 bit mode have costs of its own (doubled i-fetch bandwidth > > > for starters)? > > 64-bit MIPS CPUs still have 32-bit instructions... it's the registers > and addressing range which grow, not the instructions. True - but number of instructions will grow, thus the bandwidth needed to fetch them. > Program data segments tend to grow when you use 64-bit pointers (N64 > does, but N32 - paradoxically still a 64-bit ABI - doesn't) N32 is an ILP32 ABI so I'd count it as 32-bit. Ralf |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix), Dominic Sweetman |
|---|---|
| Next by Date: | Linux for RouterBoard532 - CPU MIPS32 4Kc - IDT 79RC32434., cordova |
| Previous by Thread: | Re: [OFF-TOPIC] Cobalt 64-bit, what for? (was: 64-bit fix), Dominic Sweetman |
| Next by Thread: | Re: initrd problem, colin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |