Re: [avr-gcc-list] using exceptions

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden On Behalf Of Gabriel Dos
> Reis
> Sent: Tuesday, May 01, 2012 11:48 AM
> To: Weddington, Eric
> Cc: Georg-Johann Lay; address@hidden; Joerg Wunsch
> Subject: Re: [avr-gcc-list] using exceptions
> 
> >
> > I've seen your name extensively on the gcc mailing list. I've also been to a
> number of the GCC Summit events in the past few years; I don't know if you've
> attended them also.
> 
> Unfortunately, I've (consistently :-/) missed GCC Summit because of
> my daytime job -- despite being a libstdc++ maintainer, and maintainer
> of other parts of the compiler, and having been a GCC Release Manager
> for a while.
> 
> >
> > I'm sorry but I've missed your recent post on libstdc++ that explained your
> educational and research activities. Do you have a link? Please let me know if
> there's anything we can do to help you with these activities.
> 
> Essentially, we would like to:
>   (1) "spice up" our programming class projects with
>         robots programming -- many of our students are native C++ speakers,
>         and AVR-based robots are cheap :-)

Yes, thanks to the wider Arduino community, there's a lot of AVR based 
robotics. ;-)

 
>   (2) as a research project, some of my students would like to
>         program AVR microcontrollers in Haskell to explore the
>         "functional reactive programming" paradigm.  However, GHC,
>         the most popular Haskell compiler does not support AVR and I
>         do not think it is going to do so in the near future, based on
> discussions
>          I have had with GHC key developers.  So, a subgroup
>         of students (under my direction) has set up to write a
> compiler for a subset
>         of Haskell targetting AVR.  This is quite an exciting research
> project.

Awesome! :-D

I know of compilers that target the AVR for these languages: C, C++, Ada, 
Modula-2, and strangely, Objective C (though I know of no one actually using 
it). All of this is through GCC. There's also a project to build an AVR target 
of LLVM.

> > Johann is pretty much right in his description. Historically, there haven't
> been very many AVR developers on GCC. Joerg Wunsch (CC) and I, who are both
> admins on the avr-libc project, have had an open request for years for a
> volunteer to help with the C++ side of things, and specifically to help build
> libsupc++ support for the AVR. None of us are experts in C++, but relatively
> good experience in C.
> >
> 
> I am a maintainer for libstdc++ and would be happy to help here.
> But, I must also confess that there has been some confusion among
> us (libstdc++ maintainers) about exactly what is needed for AVR to get
> basic stuff started.  See for example:
> 
>     http://gcc.gnu.org/ml/libstdc++/2012-01/msg00098.html
> 
> I am not expert in AVR -- I know just enough to be dangerous, so I
> would definitely do with some education here.

So, the C++ compiler builds for the AVR, however, libstdc++ has always failed 
to build for the AVR. All previous attempts at trying to work through the build 
errors for libstdc++ have failed, but there haven't been that many attempts to 
fix them, and these attempts have always been by those who aren't that skilled 
in C++ (myself included). So, in the end, we disabled the configuration of 
libstdc++ for the avr so we can still build a working C++ compiler.

Joerg Wunsch and I have repeatedly asked the AVR community for help, but as you 
know that in practically all open source projects, help is hard to come by. ;-) 
In years past, C++ for the AVR was always "exotic" and not that many users, if 
any, so not having libstdc++ was not a big deal. But now with the Arduino 
community extensively using C++ for the AVR, it's become more important that 
these areas get addressed.

Not having libstdc++ for the AVR has not had big consequences; the only 
complaints that we've ever had was for not having the new and delete operators.

As a side note, someone recently got the STL working for the AVR and C++ 
streams:
http://andybrown.me.uk/ws/2011/01/15/the-standard-template-library-stl-for-avr-with-c-streams/
This project also includes an implementation of new and delete.

The only thing I do NOT like about that project is the licensing for the 
streams part. The streams code comes from the uClibc++ project and has the LGPL 
2.1 license. All AVR code is statically linked into a single application, so 
this in effect makes one's application GPL if you link to the streams code. 
This is not good for commercial embedded projects.


 
> > Also let us know if there's anything we can do to help you get up to speed
> on the AVR toolset.
> 
> I guess I would need to get my feet wet with
>    1. minimal free-standing  C++ implementations without exceptions
>    2. get support for RTTI (without exceptions)
>    3. exceptions (assuming 1 and 2 are done successfully)
> 
> Regarding 2., I would like to understand the general policy:  RTTI
> data are generally const
> and should be best stored in read only location.  What is the general
> preference for AVR?  Put
> read only data in program memory or data segment?  Apologies for the
> triviality but
> the recent discussion about __func__ got me thinking.

On an AVR, RAM (data space) is always more limited than Flash (program space). 
However, getting const data out of Flash has, historically, not been 
automatically generated by the compiler.

Johann has recently added support for multiple address spaces to GCC 4.7 that 
should significantly help with that. However, 4.7.0 was released before he 
could fix some critical issues (since AVR is not a primary or secondary 
platform, *yet*). 
 
> Is Johann my main entry point as GCC AVR maintainer?

So, there are 3 of us that are official AVR maintainters: Denis Chertykov, 
Anatoly Sokolov, and myself (all of us listed in MAINTAINERS in GCC). Anatoly 
hasn't done much in a while. Denis has been reviewing and approving all of 
Johann's patches, but only doing some minimal work recently. I'm listed as 
maintainer, but I'm honest in that I'm not really a compiler engineer. Johann 
has been fantastic and doing a lot of work on the AVR backend recently. I'm of 
the opinion that Johann *should* be listed as an official AVR maintainer, if he 
wants it. So, I would suggest working with Johann, and Denis and I can approve 
/ rubber-stamp the patches. ;-)

Eric Weddington
Atmel