This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Extension compatibility policy


> From: "E. Weddington" <ericw@evcohs.com>
>> Paul Schlie wrote:
>> More specifically, there seem to be two predominant motivating reasons
>> why it may be desired to attach a target specified attributes to compiler
>> generated static constant objects:
>> 
>> 1 - To enable their identification so that their compile/link time storage
>>    location/type may be influenced by the target.
>> 
>> 2 - To enable their identification so that their run-time access method may
>>    be influenced by the target. (Likely due to their storage location/type)
>> 
> I know that you are doing this for the AVR target.

- Not necessarily, but do have an interest in improving it for personal use.

> You are under the assumption that it is acceptable to attach attributes
> to static constant objects to put data in Program Space for the AVR target.

- Yes. (and in general yes.)

> As Joseph pointed out to you in bug #20258,
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258>
> implementing DTR 18037 is the best way to go about this.

- Yes, and by utilizing the existing mechanism to define and utilize
  target specific attributes, this prescribed method may be prototyped;
  allowing me to better understand the issues, methods, and potential
  complications than I do presently.
  
> You consistently do not check with the official AVR maintainers (Denis
> Chertykov and Marek Michalkiewicz), or on the avr-gcc-list
> <http://savannah.nongnu.org/mail/?group=avr> to see if any of this will
> fly with the rest of the AVR community.

- ??? For what purpose? My short term goal is to simply try to determine
  if these facilities may be utilized to achieve a close approximation of
  a general desire to be able to identify and affect the target specific
  method by which static constant objects (which tend to be allocated in
  ROM within an orthogonal address space on embedded targets with Harvard
  architectures like the AVR uC, and would be nice to avoid having to
  redundantly copy them into data space just to then enable their use).

  Where if successful, and with a better understanding; then discussions
  may be worth while if there's potential interest in adopting the approach,
  or some variant of it, for incorporation into the maintained avr port.

  (it seems to me)




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]