Re: Available registers as a target property

[Paul Schlie <schlie@comcast.net>]

> From: Daniel Jacobowitz <drow@false.org>
> 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?