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 <rahulm...@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 <omeraga...@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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > Rahul Muttineni _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs