From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31087 invoked by alias); 25 Jul 2008 03:29:57 -0000 Received: (qmail 31079 invoked by uid 22791); 25 Jul 2008 03:29:56 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jul 2008 03:29:39 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id B57493C27E; Thu, 24 Jul 2008 20:29:37 -0700 (PDT) Subject: Re: Address spaces From: Michael Snyder To: Ulrich Weigand Cc: Stan Shebs , Doug Evans , gdb@sourceware.org In-Reply-To: <200807240926.m6O9QLHh026249@d12av02.megacenter.de.ibm.com> References: <200807240926.m6O9QLHh026249@d12av02.megacenter.de.ibm.com> Content-Type: text/plain Date: Fri, 25 Jul 2008 03:31:00 -0000 Message-Id: <1216956577.3549.538.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00263.txt.bz2 On Thu, 2008-07-24 at 11:26 +0200, Ulrich Weigand wrote: > Stan Shebs wrote: > > Doug Evans wrote: > > > It would be useful to have proper address spaces for non-multi-process > > > situations too. At the moment all one can do is hack in bits to > > > unused parts of the address (assuming such bits are available ...). > > > [I'm sure this isn't news. Just saying there are multiple reasons for > > > addresses being more than just the CORE_ADDR of today, and if we solve > > > one, let's at least consider the others too.] > > > > > Do you have some specific ideas in mind? Because I was assuming (and > > this is good to be aware of) that there would not be more than one > > address space associated with a process. (Instantly split I/D targets a > > la D10V come to mind, although that was handled by distinguishing > > pointers from addresses.) > > Cell/B.E. applications have multiple address spaces per process -- the > main PowerPC address space (that is also accessible from the SPEs via > DMA operations) plus a separate local store address space for each SPE > context that is active in the process. > > I'm currently using bit hacks to map all these address spaces into a > single CORE_ADDR space -- this is working OK for now, but it would > seem nicer to integrate this into a general notion of address spaces ... Oh yeah, and how about multi-core arches, like with a DSP copro or something?