<div dir="ltr">On 19 March 2018 at 00:53, Rahul Muttineni <span dir="ltr"><<a href="mailto:rahulmutt@gmail.com" target="_blank">rahulmutt@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Omer,</div><div><br></div><div>An INFO_TABLE_RET is a frame that "can be returned to" and the return keyword allows you to provide a name for the value(s) that was(were) returned to this frame and do something with it if you wish. If you didn't have this keyword, you would have to do low-level stack manipulations yourself to get a handle on the return value and it's easy to mess up. <br></div><div><br></div><div>You can think of INFO_TABLE_RET as a traditional stack frame in languages like C, except it's powerful because you can specify custom logic on how you deal with the returned value. In some cases, like stg_atomically_frame, you may not even return the value further down into the stack until certain conditions are met (the transaction is valid).<br></div></div></blockquote><div><br></div><div>This is correct. The "documentation" for this is in the CmmParse.y module: <a href="https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/CmmParse.y;b3b394b44e42f19ab7c23668a4008e4f728b51ba$151-165">https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/CmmParse.y;b3b394b44e42f19ab7c23668a4008e4f728b51ba$151-165</a><br><br></div><div>It wouldn't hurt to move all that to the wiki and leave a link behind, if anyone wants to do that.<br><br></div><div>Cheers<br></div><div>Simon<br> <br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Hope that helps,</div><div>Rahul<br></div></div><div class="gmail_extra"><div><div class="gmail-h5"><br><div class="gmail_quote">On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan <span dir="ltr"><<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I'm trying to understand what a "return" list in INFO_TABLE_RET declaration<br>
line specifies. As far as I understand a "return" in the declaration line is<br>
something different than a "return" in the body. For example, in this<br>
definition: (in HeapStackCheck.cmm)<br>
<br>
INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr )<br>
return (/* no return values */)<br>
{<br>
return (ptr);<br>
}<br>
<br>
The return list is empty and it even says "no return values" explicitly, yet it<br>
returns something.<br>
<br>
My guess is that the "return" list in the header is actually for arguments. I<br>
found this info table which has an argument: (in StgMiscClosures.cmm)<br>
<br>
INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, W_ cccs)<br>
return (P_ ret)<br>
{<br>
unwind Sp = Sp + WDS(2);<br>
#if defined(PROFILING)<br>
CCCS = cccs;<br>
#endif<br>
jump stg_ap_0_fast(ret);<br>
}<br>
<br>
This is the use site: (in Interpreter.c)<br>
<br>
#if defined(PROFILING)<br>
// restore the CCCS after evaluating the closure<br>
Sp_subW(2);<br>
SpW(1) = (W_)cap->r.rCCCS;<br>
SpW(0) = (W_)&stg_restore_cccs_eval_inf<wbr>o;<br>
#endif<br>
Sp_subW(2);<br>
SpW(1) = (W_)tagged_obj;<br>
SpW(0) = (W_)&stg_enter_info;<br>
RETURN_TO_SCHEDULER_NO_PAUSE(T<wbr>hreadRunGHC, ThreadYielding);<br>
<br>
If I understand this correctly, the "tagged_obj" code will put the return value<br>
in R1, pop the stack (which will have stg_restore_ccs_eval_info at the bottom)<br>
and jump to this the info table code shown above. So `P_ ret` is the value of<br>
`tagged_obj`, and the "return" list is actually for parameters.<br>
<br>
Did I get this right? If I did, I'm curious why it's called "return" and not<br>
"args" or something like that.<br>
<br>
Thanks,<br>
<br>
Ömer<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br><br clear="all"><br></div></div><span class="gmail-HOEnZb"><font color="#888888">-- <br><div class="gmail-m_3799511712165444548gmail_signature">Rahul Muttineni</div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div></div>