Re: Use coroutines for avr-gcc

[Wilhelm Meier <wilhelm.meier@hs-kl.de>]

On 23.09.22 10:16, Iain Sandoe wrote:
> Hi Wilhelm,
> 
>> On 23 Sep 2022, at 08:58, Wilhelm Meier <wilhelm.meier@hs-kl.de> wrote:
>>
>> On 22.09.22 21:58, Iain Sandoe wrote:
>>>> On 22 Sep 2022, at 13:34, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>>>
>>>> On Thu, 22 Sept 2022 at 13:29, Wilhelm Meier wrote:
>>>>>
>>>>> According to the standard, an implementation can avoid the
>>>>> heap-allocation, if
>>>>> - the lifetime of the coroutine is strictly within the lifetime of the
>>>>> caller
>>>>> - the size of coroutine state can be determined at compile time
>>>>>
>>>>> Looks like this optimization is not yet available because new/delete-ops
>>>>> are required.
>>> You can provide your own allocation and deallocation functions in the promise
>>> class :
>>> see  -  https://eel.is/c++draft/dcl.fct.def.coroutine#9
>>> (and #12).
>>> NOTE: this link is the current C++23 draft, the implementation in GCC follows the
>>> C++20 version (but the basic provision is stil there)
>>
>> Ok, thank you.
>> I did that and now it works also on target AVR ;-)
> 
> great!
> 
>> But: the asm-output contains a whole bunch of boilerplate code for storing the state of the coroutine. So for now I would say it is really unusable on small targets like AVR.
> 
>> I think, if the heap operations could be elided away, then the whole thing should be more efficient.
> 
> The generator style of coroutine is one specific case.
> 
> Asynchronous cases (e.g. the behaviour of an I/O interaction) modelled by a coroutine rather than a hand-written state machine strike me as potentially very useful for embedded systems (since those hand-written cases are notoriously hard to maintain).  So perhaps we could see if there is some way to optimise the ‘boiler plate’ (although some copying is mandated by the standard).

Yes, I would like to use that for serial protocol analyzers.

> FWIW: there are some other optimisations in the pipeline (one that minimizes frame size, and one that avoids saving some of the variables to the frame). 

I think, this would be helpful.

> However, AFAIK, no-one is actively working on frame elision.

That's a pitty because I think, that this renders it unusable on the 
small µC like AVR. On these plattform optimal code generation is mandatory.

> 
> There is also a paper to WG21 that seeks to mandate some of these optimisations - so maybe frame elision will get some more attention in the future.

That would be great!

> 
> Of course, if you have a patch to implement the elision, we would also be very happy to review it.

Well, I'm really not in the skills positions to provide any valuable 
input on that ...

Regards,
  Wilhelm

> 
> cheers
> Iain
> 
>>
>> Regards,
>> Wilhelm
>>
>>>>>
>>>>> Is there any work on this topic?
>>>>
>>>> The so-called HALO optimizations are much more difficult than was
>>>> originally thought when the wording in the standard was written.
>>>>
>>>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2477r3.html#background-and-motivation
>>>> describes some of the problems.
>>> Agreed, this topic needs more consideration (and it is not mandatory, so should not be relied upon
>>> for the use-case described in any event).
>>> cheers
>>> Iain
>>>>
>>>>
>>>>> Thanks!
>>>>>   Wilhelm
>>>>>
>>>>> On 21.09.22 15:38, Wilhelm Meier wrote:
>>>>>> I tried to use coroutines with avr-gcc (13.0.0) for the AVR target. I
>>>>>> managed to include the coroutine-header and to write a very simple
>>>>>> generator using the example from cppreference.
>>>>>>
>>>>>> It compiles well, but then I get undefined symbols:
>>>>>>
>>>>>> 1) new and delete operator-functions
>>>>>> 2) f(f()::f().Frame*)
>>>>>>
>>>>>> Therefore two question arise here:
>>>>>>
>>>>>> a) is it possible to use coroutines without head-allocation? E.g. define
>>>>>> some global storage for the state of the coroutine?
>>>>>> b) if a) can be fullfilled, what is 2) supposed to do?
>>>>>>
>>>>>> Thanks for any hints,
>>>>>>   Wilhelm
>