What does "return" keyword mean in INFO_TABLE_RET declarations?

[Simon Peyton Jones]

It'd be good to document this clearly somewhere; and explain how it is used.  So that the next time someone wonders, they don't have to reproduce Omer's journey

Simon

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ömer Sinan
|  Agacan
|  Sent: 19 March 2018 10:03
|  To: Rahul Muttineni <rahulmutt at gmail.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: What does "return" keyword mean in INFO_TABLE_RET
|  declarations?
|  
|  Hi Rahul,
|  
|  Thanks, that is really helpful.
|  
|  So my intuition was correct. I think the naming here is a bit
|  unfortunate because unless you're already familiar with Cmm, when you
|  see this:
|  
|      INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr )
|          return (/* no return values */)
|      {
|          return (ptr);
|      }
|  
|  you will be _very_ confused.
|  
|  Ömer
|  
|  2018-03-19 3:53 GMT+03:00 Rahul Muttineni <rahulmutt at gmail.com>:
|  > Hi Omer,
|  >
|  > 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.
|  >
|  > 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).
|  >
|  > Hope that helps,
|  > Rahul
|  >
|  > On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan
|  > <omeragacan at gmail.com>
|  > wrote:
|  >>
|  >> Hi,
|  >>
|  >> I'm trying to understand what a "return" list in INFO_TABLE_RET
|  >> declaration line specifies. As far as I understand a "return" in
|  the
|  >> declaration line is something different than a "return" in the
|  body.
|  >> For example, in this
|  >> definition: (in HeapStackCheck.cmm)
|  >>
|  >>     INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr )
|  >>         return (/* no return values */)
|  >>     {
|  >>         return (ptr);
|  >>     }
|  >>
|  >> The return list is empty and it even says "no return values"
|  >> explicitly, yet it returns something.
|  >>
|  >> My guess is that the "return" list in the header is actually for
|  >> arguments. I found this info table which has an argument: (in
|  >> StgMiscClosures.cmm)
|  >>
|  >>     INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr,
|  W_
|  >> cccs)
|  >>         return (P_ ret)
|  >>     {
|  >>         unwind Sp = Sp + WDS(2);
|  >>     #if defined(PROFILING)
|  >>         CCCS = cccs;
|  >>     #endif
|  >>         jump stg_ap_0_fast(ret);
|  >>     }
|  >>
|  >> This is the use site: (in Interpreter.c)
|  >>
|  >>     #if defined(PROFILING)
|  >>         // restore the CCCS after evaluating the closure
|  >>         Sp_subW(2);
|  >>         SpW(1) = (W_)cap->r.rCCCS;
|  >>         SpW(0) = (W_)&stg_restore_cccs_eval_info;
|  >>     #endif
|  >>         Sp_subW(2);
|  >>         SpW(1) = (W_)tagged_obj;
|  >>         SpW(0) = (W_)&stg_enter_info;
|  >>         RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding);
|  >>
|  >> If I understand this correctly, the "tagged_obj" code will put the
|  >> return value in R1, pop the stack (which will have
|  >> stg_restore_ccs_eval_info at the
|  >> bottom)
|  >> and jump to this the info table code shown above. So `P_ ret` is
|  the
|  >> value of `tagged_obj`, and the "return" list is actually for
|  >> parameters.
|  >>
|  >> Did I get this right? If I did, I'm curious why it's called
|  "return"
|  >> and not "args" or something like that.
|  >>
|  >> Thanks,
|  >>
|  >> Ömer
|  >> _______________________________________________
|  >> ghc-devs mailing list
|  >> ghc-devs at haskell.org
|  >>
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  >> haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=04%7C01%7C
|  >>
|  simonpj%40microsoft.com%7Cb990019591bd43f5ba2508d58d80b93d%7C72f988bf
|  >>
|  86f141af91ab2d7cd011db47%7C1%7C0%7C636570506392775790%7CUnknown%7CTWF
|  >>
|  pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D
|  >> %7C-
|  1&sdata=ULVGoJr6gEijZOI7uQCLJ9JR4xS6SoNGPo5sIvGff50%3D&reserved=0
|  >
|  >
|  >
|  >
|  > --
|  > Rahul Muttineni
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=04%7C01%7Csimonpj%40microsoft.com%7Cb990019591bd43f5ba2508d5
|  8d80b93d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365705063927858
|  00%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
|  6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=sEL63DuafSAYG0GgGcu30qdU22xkmnq5XLNJVKFlNtA%3D&reserved=0