Re: [avr-gcc-list] Structs in program memory.

[E. Weddington]

On 27 Apr 2004 at 16:29, Svein E. Seldal wrote:

> E. Weddington wrote:
> > You're right Christian, it could be added to GCC itself; I've been aware of
> > this. The problem of course is finding people who are: 1. Willing to do it. 
> > 2.
> > Capable of doing it.
> > 
> > Right now, there are 2 listed maintainers of the AVR port of GCC, both of
> > which are not very actively involved in it. There is a bug list for the AVR
> > port of GCC that is languishing. Granted there aren't many bugs, and
> > especially show-stopper bugs. I know of one other person (Ted Roth) who is
> > getting his FSF paperwork done so he can submit patches to GCC. However, Ted
> > is so incredibly busy with maintaining avr-libc, uisp, avrdude, simulavr,
> > avarice, and the AVR port of GDB. It would certainly help to have other
> > volunteers, especially with GCC. I agree that it would be incredibly
> > beneficial to have this feature; it would be quite the coup. But it's not
> > going to easily happen without volunteers willing to go through all the 
> > hoops
> > to get there.
> > 
> 
> Well.. I have all the papers required for submitting patches to gcc, 
> binutils and gdb. However, the main issue with this PROGMEM thing is to 
> do it correctly. 

Ok I went and reviewed the gcc list archive on this issue....

> According to my knowledge of gcc, I fear that making 
> support for several memoryspaces, might turn up to be a bigger problem 
> than it sounds. 

Could be....

> This thing will hit gcc in the central core, and thus 
> affect all targets. GCC is might be flexible in some areas, while its 
> quite rigid in others...
> 
> Thats mostly why I would surely like to get "central" gcc support for 
> this idea first. 

I doubt that this will happen: Not because you won't get support, it looks like 
it's a desired feature; but because there really isn't anything "central" about 
gcc. :-)

> If the core developer gets the point that this is a 
> rather major feature for the AVR port, this project has higher odds of 
> surviving. 

Realise that the AVR port is NOT considered a primary platform, nor even a 
secondary platform:
<http://gcc.gnu.org/gcc-3.4/criteria.html>

Even though WinAVR has had thousands of downloads:
<http://sourceforge.net/project/showfiles.php?group_id=68108>
And that's not counting Linux, FreeBSD, and Mac.

> Maybe the AVR community should join efforts and try to 
> convince the gcc community to get this feature introduced?

Doubtful. We can scream all we want, but in the end there will be gcc 
developers coming back to say: "Fine. Go ahead and implement it and submit a 
patch." It all comes down to volunteering and writing the code.

> I do not want to burn up too much energy trying to implement something 
> that is either too complex or having the risk of being rejected by the 
> gcc team becuase of policy reasons.

It will be complex. That much is clear from browsing the archives. I doubt that 
it will be rejected for policy reasons. It could very well be rejected for 
technical reasons: they will probably want to make sure:
1. It doesn't break primary platforms
2. It doesn't break secondary platforms
3. That it's technically complete.
Which will be a tall order for anyone.

The journey of a thousand miles begins with the first step. :-)