avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] RFC: Database for device properties.?


From: Björn Haase
Subject: Re: [avr-libc-dev] RFC: Database for device properties.?
Date: Sun, 23 Apr 2006 01:46:43 +0200
User-agent: KMail/1.7.1

Joerg Wunsch wrote on Samstag, 22. April 2006 21:46 :
> As Eric Weddington wrote:
> > Atmel distributes a lot of this information in AVR Studio as XML
> > files.
> > >database ---HEADER_FILE_GENERATOR1---> header file for gcc
> > >database ---HEADER_FILE_GENERATOR2---> header file for binutils
>
> It would be way cool if GCC and binutils used some kind of external
> file for that information, so we don't have to patch their binaries in
> order to add each new MCU type.  However, I've got no idea whether a
> feature like that one would get accepted by the binutils and GCC
> maintainers.
I agree, that a run-time approach would be best.

Maybe one solution would be just to add a target specific command line option 
to gcc, gas and ld where one could specify where to find the database file 
with additional target specific information. Without this option, the tools 
would only be aware of the built-in devices. 

One issue that might show up is, that one would have to write a database 
parser in plain "C" so that it could be included in gcc and binutils. And the 
parser would have to comply with all of the strict gnu coding standards and 
the GPL requirements.
For simply generating include- and source files that contain a number of 
tables, I probably would be using some kind of script language. Moreover I 
was hoping that one might make use of some kind of library.

Another possibility would be to use some kind of binary representation of the 
information that gcc could simply read in into an array in memory. I.e. 
similar to the method gcc presently uses when dealing with precompiled 
headers.

Anyway, having in mind the difficulties You just had with getting new devices 
added to binutils, I think that it is at least worth to think about, if a 
better solution could be easily realized :-).

Bjoern.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]