Re: [avr-gcc-list] using exceptions

[Georg-Johann Lay]

Gabriel Dos Reis wrote:
>>> 
>>> My recent interests in AVR grew out of educational and research 
>>> activities -- as I explained in a relatively recent post on libstdc++.
>>> I am still learning AVR and its toolsets but I can definitely help with
>>> the C++ part.
>>> 
>>> We are in the situation where we would like to compile a restricted 
>>> subset of Haskell to AVR via C++ intermediate codes.
>>> 
>>> I will have a look at PR50925.
>>> 
>>> -- Gaby
>> Hi Gaby,
>> 
>> 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 :-)
> 
> (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.

Doesn't GHC has a C backend?

And I wonder if C-- is a reasonable language to have it as GCC frontend.

Or is there too much "functional" stuff that does not fit GCC's structure
that aims at imperative programs?

> 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.
> 
>> 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

hmm, I don't read that list; it's way too far away from current state of avr 
BE...

A first start would be to activate respective parts of libwhatever and look
what happens; to the build process and to the C++ testsuite results.

> I am not expert in AVR -- I know just enough to be dangerous, so I would
> definitely do with some education here.

One thing to keep eye on is the frame pointer. avr is one target where the
FP spans several hard registers (28,29), but in some places GCC just
use FRAME_POINTER_REGNUM and assume it is all in one hard reg.

There were attempts to replace FRAME_POINTER_REGNUM by
HARD_FRAME_POINTER_REGNUM, but that lead to other problems.

One more problem is that AVR is poorly equipped with pointer registers.
There are just 3, and if frame pointer is used, just X and Z are remaining,
and if fake addressing is forbidden for X (see -mstrict-X and PR46278.

>> 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.

The preferred place is program memory, i.e. flash, i.e. something like
.progmem section.

Read-only data is located in .rodata which is located in RAM.

This is because const qualifier is not enough to put data in flash,
just assume:

char bar (const char *p)
{
    return *p;
}

char foo (char *p)
{
    char c = bar (p);

    *p = 0;

    return c;
}

bar() must not read from flash.


The issue is not locating the data, it's accessing the data with the right
instructions, i.e. LPM* for data in flash and LD* and ST* for data in RAM.

Similar issues as with rtti arise with vtables, see PR43745.

RAM is a very scarce resource on AVRs, but with current GCC it is not
possible to place+access rtti/vtable data in flash.

The right feature would be something like an internal, "artificial"
address space to qualify/locate respective pointers/data.
This should be easier than adding named address spaces as full-featured
C++ extension.

However, I'd guess that none of the code to handle address spaces is present
in C++ part and/or FE as named addresses are not a G++ feature, so there
is no need to have named address code in C++ (or other languages' parts)
in the compiler.

An artificial address space would be an address space used internally by
the compiler, not triggered by the user by means of, e.g. explicit __flash.

However, address space support is limited and no target except avr makes
that extensive use of address spaces, see respective doc chapter.

Another field of problems may be constant merging and linkonce.

It's not easy to hook in and fully support what a backend needs.
There is many hard-coded stuff in varasm.c and errors like PR50739.
Problem is that it's not correct to replace .rodata by .progmem, and
the varasm.c does not arrange for better support of that, it's really
antique code there that badly needs cleanup.

Then there is PR50807; it's rather exotic source code and the information
from GCC seems not to be enough to issue an error for such code.

Also, binutils' PR13812 is an issue on big devices when .trampolines is
shifted out of the first 128 KiB of flash. It's easy to work around
by home-brew ld script.

FYI, there is a buglist at

http://www.mikrocontroller.net/articles/Avr-gcc_Bugs

It's a bit easier to track avr-ralated issues than by the official
bugtrackers, but the list is GCC-centric.

> Is Johann my main entry point as GCC AVR maintainer?

If you like to become AVR port maintainer, the process should be the same as
when you became libstc++ maintainer, i.e. by appointment by steering committee.
I don't know the exact procedure.

Johann