From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgate-4.zdv.net (mailgate-4.zdv.net [IPv6:2001:4c80:40:62d::25:4]) by sourceware.org (Postfix) with ESMTPS id C79863858C52 for ; Fri, 23 Sep 2022 07:58:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C79863858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hs-kl.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hs-kl.de X-IPAS-Result: =?us-ascii?q?A2DqAgDeZS1j/2UNXY9aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+BfIEpgVgXAYQ2kRQDgROKF5NjCwEBAQ4BOQkEAQGFBQKEbSY4EwECBAEBA?= =?us-ascii?q?QEDAgMBAQEBAQEDAQEBBQEBAQEBAQYDAYEchS85DYZDAQEBAyMVQRALDgoCA?= =?us-ascii?q?iYCAiE2Bg0BBQIBAYIhWAGCbQMwE6xVgTKBAYNQARVBgwINZ4FfBgkBgQcsh?= =?us-ascii?q?wOBSIdeN4FVRIEVJ4JMNz6CICQeBIFIg2yCZgSEApB4hAMcJgQOAxkrHUECA?= =?us-ascii?q?QtCNBgDFAMFJAcDGQ8jDQ0EFgcMAwMFJQMCAhsHAgIDAgYTBQICTTYIBAgEK?= =?us-ascii?q?yQPBQIHLwUELwIeBAUGEQgCFgIGBAQEBBUCEAgCCCYXBxMYGxkBBTInEAkhH?= =?us-ascii?q?AoEGg0FBhMDIG8FCjoPKDFrKx0bCoEMKigVAwQEAwIGEwMDIgIQKjEUBCkTE?= =?us-ascii?q?i0HK3MJAgMiZwUDAwQoLAMJIR8HKCY8B1g6AQQDAxAiPQYDCQMCJFp3NxMVB?= =?us-ascii?q?QMNGSYIBSMXHQQIPAIFBlcTAgoSA5hXggALRCQGUQIpJ0FJBCZzA5F3kBeeU?= =?us-ascii?q?jo0B4IXgUSBQwYMiWeOd4VwBkGWdQaSCZcKhQeINRWDUpYdAgQCBAUCFoF4g?= =?us-ascii?q?WsMBzMaJIM2URcCD44sFoY5giuFTHMCATgCBgsBAQMJiCOBNQGBEQEB?= IronPort-Data: A9a23:XUYC+qOLBzrM85/vrR0UlcFynXyQoLVcMsEvi/4bfWQNrUongWdWn zBKW2CBOayPNzGme4okbt7n9RxT68WGm4I1HAZtpSBmQlt08seUXt7xwmUcns+xwm8vaGo9s q3yv/GZdJhcokf0/0vraP65xZVF/fngbqLmD+LZMTxGSwZhSSMw4TpugOdRbrRA2LBVOCvQ/ 4KpyyHjEAX9gWQsYzhPs/vrRC5H5ZwehhtJ4zTSWtgT1LPuvyF9JI4SI6i3M0z5TuF8dgJtb 7+epF0R1jqxEyYFUrtJoJ6iGqE5aue60Ty1t5Zjc/PKbi6uBMAF+v1T2PI0MS+7gtgS9jx74 I0lWZeYEW/FMkBQ8QgQe0EwLs1wAUFJ0KXhOni1q9a29B3PWVLe+MxTAXNoOIJNr46bAUkWn RAZACIBcFaFiv7eLLCTE7U3wJV4apCwetpH4xmMzhmAZRoiaa/CR6XH4doe+Toxi9pmHe2bZ M5fZTcHgBHoOUAfYQdOV89WcOGAm2DiVzJDtH2vqvRt00XD9SN1woHfCY+AEjCNbYAP9qqCn UrH83/wBB0dOfSQzj2K9n+pj+7L2yj8Xeo6G7azs/5nhEW7yWcYThIQSB28u/bRt6Klc9dWK kgb5XJ366gpsU+vCNXwN/GlnEO5Utcnc4I4O4UHBMulk8I4Py7x6rA4cwN8 IronPort-HdrOrdr: A9a23:ij0deaP2uxGSxcBcTuyjsMiBIKoaSvp037By7TEUdfUnSL3+qy nIpoVg6faUskdrZJhOo7C90cW7LE80sKQFhLX5Xo3SITUO2lHYT72KhLGKq1aLJ8S9zJ8+6U 4KScdD4ajLbGSS+vyV3ODXKbodKZK8gcaVbK/lvg5QpC9RGtld0zs= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.93,337,1654552800"; d="scan'208";a="25838175" Received: from mailgw01.hs-kl.de (HELO zdv.net) ([143.93.13.101]) by mailgate-4.zdv.net with ESMTP/TLS/AES256-GCM-SHA384; 23 Sep 2022 09:58:32 +0200 Received: from [192.168.178.62] (84.183.30.31) by klrz-mail01.ds.fh-kl.de (10.1.3.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 23 Sep 2022 09:58:31 +0200 Message-ID: Date: Fri, 23 Sep 2022 09:58:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Thunderbird/105.0 Subject: Re: Use coroutines for avr-gcc Content-Language: de-DE To: Iain Sandoe CC: References: <206B6D0C-6972-442A-96E3-324050A78584@googlemail.com> From: Wilhelm Meier In-Reply-To: <206B6D0C-6972-442A-96E3-324050A78584@googlemail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [84.183.30.31] X-ClientProxiedBy: klrz-mail01.ds.fh-kl.de (10.1.3.101) To klrz-mail01.ds.fh-kl.de (10.1.3.101) X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 22.09.22 21:58, Iain Sandoe wrote: > > >> On 22 Sep 2022, at 13:34, Jonathan Wakely 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 >