public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Wilhelm Meier <wilhelm.meier@hs-kl.de>
To: Iain Sandoe <idsandoe@googlemail.com>
Cc: <gcc-help@gcc.gnu.org>
Subject: Re: Use coroutines for avr-gcc
Date: Fri, 23 Sep 2022 09:58:31 +0200	[thread overview]
Message-ID: <b474e60a-227e-8b8a-16b8-d0b0dfde8578@hs-kl.de> (raw)
In-Reply-To: <206B6D0C-6972-442A-96E3-324050A78584@googlemail.com>

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

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.

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
> 

  reply	other threads:[~2022-09-23  7:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 13:38 Wilhelm Meier
2022-09-22 12:28 ` Wilhelm Meier
2022-09-22 12:34   ` Jonathan Wakely
2022-09-22 19:58     ` Iain Sandoe
2022-09-23  7:58       ` Wilhelm Meier [this message]
2022-09-23  8:16         ` Iain Sandoe
2022-09-23  8:42           ` Wilhelm Meier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b474e60a-227e-8b8a-16b8-d0b0dfde8578@hs-kl.de \
    --to=wilhelm.meier@hs-kl.de \
    --cc=gcc-help@gcc.gnu.org \
    --cc=idsandoe@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).