From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11712 invoked by alias); 7 May 2005 04:54:07 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11596 invoked from network); 7 May 2005 04:53:56 -0000 Received: from unknown (HELO sccrmhc14.comcast.net) (204.127.202.59) by sourceware.org with SMTP; 7 May 2005 04:53:56 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc14) with SMTP id <2005050704535001400g5bnoe>; Sat, 7 May 2005 04:53:55 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 07 May 2005 04:54:00 -0000 Subject: Re: Available registers as a target property From: Paul Schlie To: Daniel Jacobowitz CC: Message-ID: In-Reply-To: <20050507043029.GA29449@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00086.txt.bz2 > From: Daniel Jacobowitz > On Fri, May 06, 2005 at 11:49:00PM -0400, Paul Schlie wrote: >> Understood, but given that these semi-customizable synthesizable processors >> still need to have their configurations described to multiple tools, it >> still seems that adopting a more centralized specification scheme which >> enables their configuration descriptions to be more conveniently accessible >> by whatever tools may choose to leverage them seems like a good thing; as >> opposed to having creating discrete depositories/methods unique to each >> tool. >> >> Which is why potentially broadening the use of BFD's seemed potentially >> reasonable, but do recognize it would correspondingly require broader >> coordination which could complicate the effort beyond reason. So possibly >> as the parameters required to sufficiently describe the logically visible >> debug model of an arbitrarily configured processor subsystem becomes clear, >> these same parameters could be considered to form the basis of a more >> centralized target configuration description which may ultimately be >> utilized by other tools. > > Personally I don't think it's very useful. I'm not sure why you call > them "semi-customizable"; the point is that they are, in fact, fully > customizable. - actually arm "extensible architecture" is fairly rigid, and arguably far less "customizable" than those offered by ARC or Tensilica for example; and is likely best characterized as being extended via co-processor extensions not an innate extension/customization of the arm ISA or processor implementation core architecture itself. > ARM's approach to this problem was to encapsulate the description > in the module server, which is distributed with the target > configuration. Anything that wants the configuration can query the > target for it. That seems a lot more useful to me - rather than > centralizing the registry, distribute it locally to every target it > describes. - so you propose that GNU tools adopt a reliance on a proprietary vendor data base "module server" in order to configure tools to support that vendors proprietary licensed architecture?