From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 8A4EC3858C52 for ; Fri, 23 Sep 2022 08:16:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A4EC3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=googlemail.com Received: by mail-wr1-x42d.google.com with SMTP id c11so19158733wrp.11 for ; Fri, 23 Sep 2022 01:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date; bh=K5zqFcurjD4TRDPL9sVF9e9NxoI2/b3rYzmn6CSN0Go=; b=J2jjp9qpwC2/HfqQafYlv8Y424RdKLvLQGTgtfkp76zOKGmNAlcTgVTWwn5HeK5r45 6yo2vZ0oSfaUhSDqCdknpp2THCrzTcoRcebqZZoJg+kVsCY0zBMBF2nnpSi6hOJibRPI KrykhZ25KWMNc1r1OC0mHqMD+7X1FuhgPtLHwpQm3qwSdnMRRwt2s9NC7JtnbM9H7BAb 5moXy8lHKQvVuFr0bFcskF9XqpvxrEouHR2sU1Wv42iDW1IqTduUaGRuC7ztX7iIyg3n QycHVLVc12r4n59xoKe41unK1JH7/ca1513gPm5LMC+hVq6gb0GNMYRucVm6J2d2wlVI J46g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=K5zqFcurjD4TRDPL9sVF9e9NxoI2/b3rYzmn6CSN0Go=; b=ympHgg3maPO15NzD6T/aIM76Tme7dHjRDOVfEa3KPS9vgOut1G1fykIKdVXOl/a+61 zNv8HOUP23122rPWZueVlSyUmp2qS0O/jiRggfqkassjudG0OZGoBxxJbhMYpzV5JPTv lxk8mEEOh89GnFJwUpNkf9Hj0AMDIr6/4v5QRwr21oyaUhoKqZP+dt9G92TqsybVWze4 iMY5t0aEAvojiGRyDeZz7d2A6+KHelhazpjErGhji1uVk2/bWcE/IWG72RCNsTSl5oxR 5EPcAK5oznxUFWUrS0EUNvsrQV5I4yKIOQCeGPCC3weq9/oiZ/UaGmUwgNmRrzlCsS87 JrwA== X-Gm-Message-State: ACrzQf3PtikoOkS+ldxZoqHh+L5DDIzOwgPK3Uw2qKYjeNEdzf8Dmchw K/JH+r8gbgy4E3twZKxKOdM= X-Google-Smtp-Source: AMsMyM47U9qEdJdV7Khp+nEro/o3jkBJJt8bYMHMZppwhQYNkJshxKihqYLiV39qduYD3qT7l5gXCA== X-Received: by 2002:a5d:4487:0:b0:22a:e803:927b with SMTP id j7-20020a5d4487000000b0022ae803927bmr4588042wrq.353.1663921000982; Fri, 23 Sep 2022 01:16:40 -0700 (PDT) Received: from [192.168.1.95] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id t5-20020a05600001c500b0022abcc1e3cesm6760992wrx.116.2022.09.23.01.16.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Sep 2022 01:16:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Use coroutines for avr-gcc From: Iain Sandoe In-Reply-To: Date: Fri, 23 Sep 2022 09:16:39 +0100 Cc: gcc-help@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <407645D3-B529-41ED-A015-8BDB6912EC47@googlemail.com> References: <206B6D0C-6972-442A-96E3-324050A78584@googlemail.com> To: Wilhelm Meier X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Wilhelm, > On 23 Sep 2022, at 08:58, Wilhelm Meier = wrote: >=20 > On 22.09.22 21:58, Iain Sandoe wrote: >>> On 22 Sep 2022, at 13:34, Jonathan Wakely = wrote: >>>=20 >>> On Thu, 22 Sept 2022 at 13:29, Wilhelm Meier wrote: >>>>=20 >>>> 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 >>>>=20 >>>> 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) >=20 > 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 =E2=80=98boiler plate=E2=80=99 = (although some copying is mandated by the standard). 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). However, AFAIK, no-one is actively working on frame = elision. 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. Of course, if you have a patch to implement the elision, we would also = be very happy to review it. cheers Iain=20 >=20 > Regards, > Wilhelm >=20 >>>>=20 >>>> Is there any work on this topic? >>>=20 >>> The so-called HALO optimizations are much more difficult than was >>> originally thought when the wording in the standard was written. >>>=20 >>> = https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2477r3.html#back= ground-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 >>>=20 >>>=20 >>>> Thanks! >>>> Wilhelm >>>>=20 >>>> 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. >>>>>=20 >>>>> It compiles well, but then I get undefined symbols: >>>>>=20 >>>>> 1) new and delete operator-functions >>>>> 2) f(f()::f().Frame*) >>>>>=20 >>>>> Therefore two question arise here: >>>>>=20 >>>>> 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? >>>>>=20 >>>>> Thanks for any hints, >>>>> Wilhelm