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

[David Brown]

> 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. 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. 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. 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. Maybe the AVR community should join efforts and try to
> convince the gcc community to get this feature introduced?
>
> 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.
>
> Svein
>

I have not looked much into the "guts" of gcc, other than getting an m68k
interrupt patch to work on a different version of the compiler, but I've
compiled and used it on about half a dozen different architectures.  It
strikes me that there would be scope for benifits on many targets if the
concept of memory spaces were in the core of gcc (as an example for
non-microcontrollers, "small data segment" data could benifit from the same
ideas).  Perhaps if there are enough of such benifits on "big" cpus, it
would be possible to get more support for memory spaces?

Would it be practical to deal with program memory (and io space) using C++
types and function (and, in particular, operator) overloading?  I know it
would be possible, but could it be done in such a way that the resulting
code is (at least close to) optimal, rather than generating piles of extra
code to handle inheritance and method tables?

David