From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11340 invoked by alias); 25 Jun 2007 22:23:40 -0000 Received: (qmail 11332 invoked by uid 22791); 25 Jun 2007 22:23:40 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Jun 2007 22:23:38 +0000 Received: (qmail 9508 invoked from network); 25 Jun 2007 22:23:36 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jun 2007 22:23:36 -0000 To: Michael Eager Cc: gdb@sources.redhat.com Subject: Re: Non-uniform address spaces References: <467D4AE3.7020505@eagercon.com> <20070623212557.GB3448@caradoc.them.org> <467D9503.9060804@eagercon.com> <46800482.4020700@eagercon.com> <46801FDD.4020408@eagercon.com> From: Jim Blandy Date: Mon, 25 Jun 2007 22:23:00 -0000 In-Reply-To: <46801FDD.4020408@eagercon.com> (Michael Eager's message of "Mon, 25 Jun 2007 13:04:45 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: 2007-06/txt/msg00278.txt.bz2 Michael Eager writes: > For an example, the SPEs in a Cell processors could be configured > to distribute pieces of an array over different SPEs. > >> How do you declare such an array? How do you index it? What code is >> generated for an array access? How does it relate to C's rules for >> pointer arithmetic? > > In UPC (a parallel extension to C) there is a new attribute "shared" > which says that data is (potentially) distributed across multiple process= ors. > > In UPC, pointer arithmetic works exactly the same as in C: you can > compare pointers, subtract them to get a difference, and add integers. > The compiler generates code which does the correct computation. All right. Certainly pointer arithmetic and array indexing need to be fixed to handle such arrays. Support for such a system will entail having the compiler describe to GDB how to index these things, and having GDB understand those descriptions.=20=20 If those were fixed, how do the other CORE_ADDR uses look to you? Say, in the frame code? Or the symtab code? > The C standard doesn't require objects to be contiguous or to be > stored entirely in a single memory space. Actually, my mentioning the C standard there was a red herring; we're talking about how CORE_ADDR is used in GDB, and CORE_ADDR has no necessary relation to anything in the C standard. But just for the murky glory of language lawyering: it seems to me that the standard does require objects to be contiguous. 6.2.4 para. 20: Any number of derived types can be constructed from the object, function, and incomplete types, as follows: =E2=80=94 An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type. And 6.3.2.3, para. 7: A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. ... When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object. Now, the implementation could do all sorts of magic under the covers that takes these apparently contiguous objects and scatters them around memory in some useful way. And that lower level is exactly the level at which CORE_ADDR operates, so your point stands.