Re: [avr-gcc-list] using exceptions

[Gabriel Dos Reis]

On Wed, May 2, 2012 at 7:58 AM, Georg-Johann Lay <address@hidden> wrote:
> 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?

Oh yes, it does.  Though it is scheduled to be phased out.
That was the original route we took.
I did spend a fair amount of my time
trying to get it work.  To no avail.  Simply said, GHC
appears to be  set up for "desktop" (though now it works for iPhones)
but definitely not "small" devices like AVR.
I did have extensive discussions with the key GHC developers.
Retargeting GHC for AVR appeared to be too much work
compared to the benefit; this is primarily because of the
 build system (the "easy" part) and the runtime system ("hard")
and support libraries ("harder").

sorry if I did not mention this before.

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

C-- is fairly imperative, below C; it does not have any "functional"
flavour.  I do not know whether the GHC folks would be interested
in having it as a GCC front-end -- there are some licensing issues to resolve
and bunch of other stuff.  Also, I do not know to what degree the llvm backend
would eventually replace C--.

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

Thank you!

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

Yes, "const" qualifier on *parameters* is not enough.
However "const" qualifier on *objects* should be enough.
(and for C++, we now have "constexpr" to statically
guarantee that)

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

yes; I agree.  My question though was whether there was a general
policy about where to put things we know are never going to change
in program memory because of RAM being so scarce.

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

Thanks for the PR number.

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

Agreed.  I will talk to Jason to see what can be done here.

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

Agreed.  I would like to refrain from full fledged named address spaces in the
C++ front-end until the WG21 committee got a clear direction.  On the other
hand something like the one you describes above should suffice.


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

The last time I touched  varasm.c was early 2002 and it
did not look pretty then :-/

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

This is very useful.  Thanks!


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

I know the drill but I think the first thing to do is to get you as
AVR port maintainer.
You are far more qualified than I.

Thanks for all these sources of information.

-- Gaby