From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgate-2.zdv.net (mailgate-2.zdv.net [IPv6:2001:4c80:40:62d::25:2]) by sourceware.org (Postfix) with ESMTPS id F0E113857426 for ; Fri, 23 Sep 2022 08:42:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F0E113857426 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?A2A9BAChcC1j/2UNXY9aHQEBAQEJARIBBQUBQIFPgXyBK?= =?us-ascii?q?YFYFwGENpEUA4ETiheTYwsBAQEOATkJBAEBhQUChG0mOBMBAgQBAQEBAwIDA?= =?us-ascii?q?QEBAQEBAwEBAQUBAQEBAQEGAwGBHIUvOQ2GQgEBAQECASMPAQVBBQsLDgoCA?= =?us-ascii?q?iYCAiE2Bg0BBQIBAYIhWAGCbQMNIxOrV3qBMoEBg1ABFUGDAg1ngV8GCQGBB?= =?us-ascii?q?yyHA4FIh143gVVEgRUnDIJANz6CICQeBIFIg2yCZgSEApB4hAMcJgQOAxkrH?= =?us-ascii?q?UECAQtCNBgDFAMFJAcDGQ8jDQ0EFgcMAwMFJQMCAhsHAgIDAgYTBQICTTYIB?= =?us-ascii?q?AgEKyQPBQIHLwUELwIeBAUGEQgCFgIGBAQEBBUCEAgCCCYXBxMYGxkBBTInE?= =?us-ascii?q?AkhHAoEGg0FBhMDIG8FCjoPKDFrKx0bCoEMKigVAwQEAwIGEwMDIgIQKjEUB?= =?us-ascii?q?CkTEi0HK3MJAgMiZwUDAwQoLAMJIR8HKCY8B1g6AQQDAxAiPQYDCQMCJFp3N?= =?us-ascii?q?xMVBQMNGSYIBSMXHQQIPAIFBlcTAgoSA5hXggALRCQGUQIpJw00DD0EJg9kA?= =?us-ascii?q?4xWhSGcMZI4OjQHgheBRIFDBgyJZ410gQOFcAYQMZZ1BpIJlwqFB4g1FYNSl?= =?us-ascii?q?h0CBAIEBQIWgXiBawwHMxokgzZRFwIPjiwWhjmCK4VMcwIBOAIGAQoBAQMJi?= =?us-ascii?q?COBNQEzXgEB?= IronPort-Data: A9a23:WowPp6hm0rEJPk1Lx6kJ8GS0X1610BIKZh0ujC45NGQN5FlHY01je htvXjvVM/7bZ2anfox2YYqz9U8PvJXRytQxSwo++39gRXgW8JqUDtmwEBz9bniYRiHhoOOLz Cm8hv3odp1coqr0/0/1WlTZhSAgk/vOHtIQMcacUghpXwhoVSw9vhxqnu89k+ZAjMOwa++3k YqaT/b3ZRn0gFaYDkpOs/jZ8EI156yr0N8llgVWic5j7QK2e0Y9VPrzFYnpR1PkT49dGPKNR uqr5NlVKUuAon/Bovv8+lrKWhViroz6ZGBiuVIPM0SWuSWukwRpukoN2FjwXm8M49mBt4gZJ NygLvVcQy9xVkHHsLx1vxW1j0iSMIUekIIrL0RTvuSRlGz2cF/i/clRCV0WNoBJ4OZ2Anxno KlwxDAlNnhvhsqkzKz9TORw7ighBJC3Z8VO4Tc5lneAVa9OrZPrGs0m4fdn3TMwi8RLW9PTZ scDQTp0KRfEJRFCUrsSIMtix7fx3CGvLlW0rnq+iLJs6GP4xzAh2ZvwH+fJdv+VVJV8yxPwS mXuuj6R7gshHN2T0jOD/nWhruDImiz/VYcbFbn+/flv6HWczWdWCBASTXO0qvL/hUijHdVFJ CQpFjEGqKEz8EO0FoC7Xwb9o3rCshN0t8dsLtDWITqlksL8izt1zEBdJtKdQLTKbPMLeAE= IronPort-HdrOrdr: A9a23:LurkS6rg5YqO72KNAhafRh0aV5rqeYIsimQD101hICG9Evb0qy nOpoV56faQsl0ssR4b+exoW5PwI080l6Qa3WB5B97LNjUO3lHYSb2KhrGM/9SxIUHD398Y7L wlWYUWMqyXMXFKyf/gpCX9OftI+qj+zImYwd7Ei1dBJDsaDJ1I3kNBEUKhVmdaLTM2fKYRJd 6k/Y574xCMEE5nFfhSoBQ+Loz+jsDM/aiGXSI7 X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.93,337,1654552800"; d="scan'208";a="143812085" Received: from mailgw01.hs-kl.de (HELO zdv.net) ([143.93.13.101]) by mailgate-2.zdv.net with ESMTP/TLS/AES256-GCM-SHA384; 23 Sep 2022 10:42:43 +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 10:42:42 +0200 Message-ID: <40281029-ccc8-853e-3762-1f1b7df8275a@hs-kl.de> Date: Fri, 23 Sep 2022 10:42:42 +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> <407645D3-B529-41ED-A015-8BDB6912EC47@googlemail.com> From: Wilhelm Meier In-Reply-To: <407645D3-B529-41ED-A015-8BDB6912EC47@googlemail.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit 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.6 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 23.09.22 10:16, Iain Sandoe wrote: > Hi Wilhelm, > >> On 23 Sep 2022, at 08:58, Wilhelm Meier wrote: >> >> 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 ;-) > > 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 >