220 21963 article Path: news.gmane.org!not-for-mail From: Giovanni Piero Deretta Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: is await an extension of the do-notation? (was Re: Re: Resumable expressions p0114r0 vs async/await P0057R0) Date: Fri, 23 Oct 2015 02:37:09 -0700 (PDT) Lines: 178 Approved: news@gmane.org Message-ID: References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <56114953.4030701@wanadoo.fr> <561B403D.4030403@gmail.com> <561C07D1.3080304@gmail.com> <561C213F.1060009@gmail.com> <561C3875.2050701@gmail.com> <86924069-44d0-447f-bf8a-a42e46579832@isocpp.org> <561D79A7.8080007@gmail.com> <894616d6-9609-4038-b2bc-d2c62df21e0f@isocpp.org> <99bdb3ae-9214-4440-8572-4c47a61eda46@isocpp.org> <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> <561DC957.8080603@gmail.com> <2e09660f-d688-474a-8811-85fb041f68b8@isocpp.org> <8b78abb4-16b6-4b65-8513-6e2c17317647@isocpp.org> <779be861-3b2a-427a-b36b-ad2874c81129@isocpp.org> <767364f8-785d-4f8f-9bc0-852df56ee4eb@isocpp.org> <0a728eee-e8e7-48ea-adf6-2a8dae63916e@isocpp.org> <6a4f863e-faf0-42ac-b85d-0951738350ab@isocpp.org> <1f818f79-1fe3-4e9f-b5c7-07836547dd74@isocpp.org> <5d4d4143-dcbb-401f-b809-6d1e50840fc4@isocpp.org> <0167264e-62fa-42bb-85b1-726c48650438@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_25_248676893.1445593029347" X-Trace: ger.gmane.org 1445593043 20333 80.91.229.3 (23 Oct 2015 09:37:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2015 09:37:23 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDEP3I7TGEIMN75HWECRUBFFOWFGG@isocpp.org Fri Oct 23 11:37:22 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZpYmi-00066J-R5 for gclcip-std-proposals@m.gmane.org; Fri, 23 Oct 2015 11:37:17 +0200 Original-Received: by iow1 with SMTP id 1sf208344984iow.1 for ; Fri, 23 Oct 2015 02:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=FKFjkUZGthyWE4RaDWDNYW0Gus/2xuGVcjZKHxH7K8A=; b=LovcaF31HlPGFl8nfkyMxdQCg7x+uT45clAsQCLYoTmBd7yDLcdgta4DApO91Ys3aM R4nM9mW3zeEHBmjdXGU0uBPoZ25kpgm9PPTjl60cCDl42x7XTsKompsexTL4UkhMgcw+ 8tjfW+slTad5n3hOkB+GBNNDbeAAk3EAOpOyXkS+/zbDnKjZZDO7xy4QltBXDq5/eQv2 dqDpl7dDH2z87znBzXHObTnQkBrP9d6uKgBt4ZlVJ7NAKfvo0oJjISiE5z9qh51eeqc/ Tmo1BGmcbXw0F7ba+Tzfj/H+qIwKefX0vhNpTp2AZyaIsdUGuC3k9Ja3RBgyG1CMil3k Sr6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=FKFjkUZGthyWE4RaDWDNYW0Gus/2xuGVcjZKHxH7K8A=; b=kbS3pgYFHImyt3W+GrsvWFro8kvSFHxFtajZH+CCi7wGkMFPXhe7oY0yu2rvO6CyFc WYkIUbmU8qbn61uOUjyomHUcEzDFcnBS5D1KkB2zENqpKoKQfl8nnV4ZOQwmVetF6w98 Yd3bBjvgCX9iSZmDJ+bVPZgfhHOnILOjVOQnHt2SeFMIyuH+4OaWuDj60vyE9fIJo1mF yB534jdI2RVthnO9LJZpaWKh5CyFg/dRrpTUYWKNlOONEFRQ7UuiqmeFQZCeLtAAbGTX NCVwq6/SedomU9hrACtBhIjWQJGVbXNHLCNAQRpAuGdg/tJIUqkAIj/pVbwXFHztQAjg Lbqw== X-Gm-Message-State: ALoCoQnPbykwg0A6eKRguCJBLFCorBUut0yrdhP6IwnDWL0H5ICFg4qafwjUkpmcxk3x1VijgZYh X-Received: by 10.182.245.163 with SMTP id xp3mr14456108obc.19.1445593031037; Fri, 23 Oct 2015 02:37:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.57.84 with SMTP id g20ls156457igq.36.gmail; Fri, 23 Oct 2015 02:37:10 -0700 (PDT) X-Received: by 10.50.57.17 with SMTP id e17mr54424igq.2.1445593030317; Fri, 23 Oct 2015 02:37:10 -0700 (PDT) In-Reply-To: X-Original-Sender: gpderetta@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21963 Archived-At: ------=_Part_25_248676893.1445593029347 Content-Type: multipart/alternative; boundary="----=_Part_26_157917747.1445593029348" ------=_Part_26_157917747.1445593029348 Content-Type: text/plain; charset=UTF-8 On Friday, October 23, 2015 at 9:21:14 AM UTC+1, Oliver Kowalke wrote: > > template >> struct context { >> fcontext_t * to; >> >> > well, yes the same pattern is used in boost.coroutine - but I didn't > something is missing here? > > >> I slightly better implementation wouldn't need a level of indirection via >> the stack to access p and current as they would be both passed in >> registers. Something like this would work: >> >> struct fcontext_t; // opaque type >> std::pair jump_fcontext(fcontext_t * to, void* parm); >> Note: no 'from' parameter: fcontext simply pushes any context state to >> the top of the stack; fcontext_t is just a pointer to the stack. Many ABIs >> allow passing the std::pair result in two registers instead of the stack. >> > > jump_fcontext() implementation does actually push all registers at the end > of the stack and returns the last stack address - the difference that the > current impl updates the first parameter (== from). > void jump_fcontext( fcontext_t * from, fcontext_t to, intptr_t data); > Ok, it is exactly the same then, fcontext_t already has pointer semantics and 'from' is an input/output parameter. My only extra requirement is that jump_fcontext should zero the 'from' context between switches so that a swapped out context can be detected. > > maybe it's a good idea to change the return type of jump_fcontext() from > void to result_t { fcontext_t, void * } (or std::pair()) - of course it > would require modifications in the asm implementation. > I prefer input parameter plus result than input/output parameters, but it is not a big deal. > > >> as long as the thread_local is not part of the api, it is just an >> implementation detail. The problem is that the proposal makes is available >> so its semantics must be preserved, which means that the just saved context >> excapes to a potentially untrackable location from the compiler. >> > > can you elaborate it > void foo(context x) { x(1); x(2); } void bar() { context y(foo); int i = y(); i = y(); } I want the compiler to completely inline foo inside bar and remove any allocation. It can do that if jump_fcontext is a builtin *and* it can accurately track all uses of the fcontex_t; Writing its address to a global variable can make the analysis more difficult. In fact to guarantee the optimisation I would like to propose attributes that would prevent a context address to be (transitively) passed to non attributed functions or non-local variables; such a schema would not work well if assigning to a global is always part of every use of context. -- gpd -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_26_157917747.1445593029348 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, October 23, 2015 at 9:21:14 AM UTC+1, Oliver Ko= walke wrote:
<= div>
template<class R, class T>
struct context = {
=C2=A0=C2=A0=C2=A0 fcontext_t * to;

well, yes the same pattern is used in boost.coroutine - but I d= idn't

something is mi= ssing here?
=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I slightly better imp= lementation wouldn't need a level of indirection via the stack to acces= s p and current as they would be both passed in registers. Something like t= his would work:

struct fcontext_t; // opaque type
std::pair<fc= ontext_t*, void *> jump_fcontext(fcontext_t * to, void* parm);
Note: = no 'from' parameter: fcontext simply pushes any context state to th= e top of the stack; fcontext_t is just a pointer to the stack. Many ABIs al= low passing the std::pair result in=C2=A0 two registers instead of the stac= k.

jump_fcontext() implementation= does actually push all registers at the end of the stack and returns the l= ast stack address - the difference that the current impl updates the first = parameter (=3D=3D from).
void jump_fcontext( fcontext_t * fro= m, fcontext_t to, intptr_t data);
<= div>
Ok, it is exactly the same then,=C2=A0 fcontext_t already has point= er semantics and 'from' is an input/output parameter. My only extra= requirement is that jump_fcontext should zero the 'from' context b= etween switches so that a swapped out context can be detected.
=C2=A0

maybe it's a good idea to cha= nge the return type of jump_fcontext() from void to result_t { fcontext_t, = void * } (or std::pair()) - of course it would require modifications in the= asm implementation.

I pre= fer input parameter plus result than input/output parameters, but it is not= a big deal.
=C2=A0
=C2=A0
=
as long= as the thread_local is not part of the api, it is just an implementation d= etail. The problem is that the proposal makes is available so its semantics= must be preserved, which means that the just saved context excapes to a po= tentially untrackable location from the compiler.

can you elaborate it

void foo(context x)
{
=C2=A0=C2=A0=C2=A0=C2=A0 x(1); x(2= );
}

void bar()
{=C2=A0
context y(foo);
int i =3D y(); = i =3D y();
}
=C2=A0
I want the compiler to completely inline foo i= nside bar and remove any allocation. It can do that if jump_fcontext is a b= uiltin *and* it can accurately track all uses of the fcontex_t; Writing its= address to a global variable can make the analysis more difficult. In fact= to guarantee the optimisation I would like to propose attributes that woul= d prevent a context address to be (transitively) passed to non attributed f= unctions or non-local variables; such a schema would not work well if assig= ning to a global is always part of every use of context.

-- gpd
<= /div>

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_26_157917747.1445593029348-- ------=_Part_25_248676893.1445593029347-- .