What does "return" keyword mean in INFO_TABLE_RET declarations?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

What does "return" keyword mean in INFO_TABLE_RET declarations?

Ömer Sinan Ağacan
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: What does "return" keyword mean in INFO_TABLE_RET declarations?

Rahul Muttineni
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



--
Rahul Muttineni

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: What does "return" keyword mean in INFO_TABLE_RET declarations?

Ömer Sinan Ağacan
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 <[hidden email]>:

> 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 <[hidden email]>
> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>
> --
> Rahul Muttineni
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: What does "return" keyword mean in INFO_TABLE_RET declarations?

GHC - devs mailing list
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 <[hidden email]> On Behalf Of Ömer Sinan
|  Agacan
|  Sent: 19 March 2018 10:03
|  To: Rahul Muttineni <[hidden email]>
|  Cc: ghc-devs <[hidden email]>
|  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 <[hidden email]>:
|  > 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
|  > <[hidden email]>
|  > 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
|  >> [hidden email]
|  >>
|  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
|  [hidden email]
|  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
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: What does "return" keyword mean in INFO_TABLE_RET declarations?

Simon Marlow-7
In reply to this post by Rahul Muttineni
On 19 March 2018 at 00:53, Rahul Muttineni <[hidden email]> wrote:
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).

It wouldn't hurt to move all that to the wiki and leave a link behind, if anyone wants to do that.

Cheers
Simon
 

 
Hope that helps,
Rahul

On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



--
Rahul Muttineni

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: What does "return" keyword mean in INFO_TABLE_RET declarations?

GHC - devs mailing list

It’s fine where it is, provided it takes the form of

            Note [Stack frames]

and that Note is referred to from relevant places elsewhere.  E.g. Omer didn’t find it.   One plausible place to point to it is the very definition site of INFO_TABLE_RET, wherever that is.

 

Simon

 

From: ghc-devs <[hidden email]> On Behalf Of Simon Marlow
Sent: 19 March 2018 18:50
To: Rahul Muttineni <[hidden email]>
Cc: ghc-devs <[hidden email]>
Subject: Re: What does "return" keyword mean in INFO_TABLE_RET declarations?

 

On 19 March 2018 at 00:53, Rahul Muttineni <[hidden email]> wrote:

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).

 

It wouldn't hurt to move all that to the wiki and leave a link behind, if anyone wants to do that.

Cheers

Simon
 


 

Hope that helps,

Rahul

 

On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



--

Rahul Muttineni


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: What does "return" keyword mean in INFO_TABLE_RET declarations?

Ömer Sinan Ağacan
I think this may be my bad. Both StgMiscClosures.cmm and Updates.cmm have this
line in the header:

    This file is written in a subset of C--, extended with various
    features specific to GHC.  It is compiled by GHC directly.  For the
    syntax of .cmm files, see the parser in ghc/compiler/cmm/CmmParse.y.

and CmmParse.y explains INFO_TABLE_RET:

    Stack Frames
    ------------

    A stack frame is written like this:

    INFO_TABLE_RET ( label, FRAME_TYPE, info_ptr, field1, ..., fieldN )
                   return ( arg1, ..., argM )
    {
      ... code ...
    }

    where field1 ... fieldN are the fields of the stack frame (with types)
    arg1...argN are the values returned to the stack frame (with types).
    The return values are assumed to be passed according to the
    NativeReturn convention.

    ...

It's just that sometimes it's not easy to find your way in a 880kloc code base.

Sorry for the noise,

Ömer

2018-03-20 12:57 GMT+03:00 Simon Peyton Jones via ghc-devs
<[hidden email]>:

> It’s fine where it is, provided it takes the form of
>
>             Note [Stack frames]
>
> and that Note is referred to from relevant places elsewhere.  E.g. Omer
> didn’t find it.   One plausible place to point to it is the very definition
> site of INFO_TABLE_RET, wherever that is.
>
>
>
> Simon
>
>
>
> From: ghc-devs <[hidden email]> On Behalf Of Simon Marlow
> Sent: 19 March 2018 18:50
> To: Rahul Muttineni <[hidden email]>
> Cc: ghc-devs <[hidden email]>
> Subject: Re: What does "return" keyword mean in INFO_TABLE_RET declarations?
>
>
>
> On 19 March 2018 at 00:53, Rahul Muttineni <[hidden email]> wrote:
>
> 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).
>
>
>
> This is correct.  The "documentation" for this is in the CmmParse.y module:
> https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/CmmParse.y;b3b394b44e42f19ab7c23668a4008e4f728b51ba$151-165
>
> It wouldn't hurt to move all that to the wiki and leave a link behind, if
> anyone wants to do that.
>
> Cheers
>
> Simon
>
>
>
>
>
> Hope that helps,
>
> Rahul
>
>
>
> On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan <[hidden email]>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
>
> Rahul Muttineni
>
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: What does "return" keyword mean in INFO_TABLE_RET declarations?

GHC - devs mailing list
It might help to

a) make the reference more specific, et

        See Note [Stack frames] in CmmParse.y

b) put that citation close to the relevant definitions,
   rather than at the head of the file.



It's not easy for authors to anticipate the path that others will follow later.  But /you/ now know what you didn't understand, and what would have helped you.

Just add the info, in the places that would have meant you found it instantly.  That'll save time for others.

Simon

|  -----Original Message-----
|  From: Ömer Sinan Ağacan <[hidden email]>
|  Sent: 20 March 2018 13:09
|  To: Simon Peyton Jones <[hidden email]>
|  Cc: Simon Marlow <[hidden email]>; Rahul Muttineni
|  <[hidden email]>; ghc-devs <[hidden email]>
|  Subject: Re: What does "return" keyword mean in INFO_TABLE_RET
|  declarations?
|  
|  I think this may be my bad. Both StgMiscClosures.cmm and Updates.cmm
|  have this line in the header:
|  
|      This file is written in a subset of C--, extended with various
|      features specific to GHC.  It is compiled by GHC directly.  For
|  the
|      syntax of .cmm files, see the parser in
|  ghc/compiler/cmm/CmmParse.y.
|  
|  and CmmParse.y explains INFO_TABLE_RET:
|  
|      Stack Frames
|      ------------
|  
|      A stack frame is written like this:
|  
|      INFO_TABLE_RET ( label, FRAME_TYPE, info_ptr, field1, ..., fieldN
|  )
|                     return ( arg1, ..., argM )
|      {
|        ... code ...
|      }
|  
|      where field1 ... fieldN are the fields of the stack frame (with
|  types)
|      arg1...argN are the values returned to the stack frame (with
|  types).
|      The return values are assumed to be passed according to the
|      NativeReturn convention.
|  
|      ...
|  
|  It's just that sometimes it's not easy to find your way in a 880kloc
|  code base.
|  
|  Sorry for the noise,
|  
|  Ömer
|  
|  2018-03-20 12:57 GMT+03:00 Simon Peyton Jones via ghc-devs
|  <[hidden email]>:
|  > It’s fine where it is, provided it takes the form of
|  >
|  >             Note [Stack frames]
|  >
|  > and that Note is referred to from relevant places elsewhere.  E.g.
|  Omer
|  > didn’t find it.   One plausible place to point to it is the very
|  definition
|  > site of INFO_TABLE_RET, wherever that is.
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  > From: ghc-devs <[hidden email]> On Behalf Of Simon
|  > Marlow
|  > Sent: 19 March 2018 18:50
|  > To: Rahul Muttineni <[hidden email]>
|  > Cc: ghc-devs <[hidden email]>
|  > Subject: Re: What does "return" keyword mean in INFO_TABLE_RET
|  declarations?
|  >
|  >
|  >
|  > On 19 March 2018 at 00:53, Rahul Muttineni <[hidden email]>
|  wrote:
|  >
|  > 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).
|  >
|  >
|  >
|  > This is correct.  The "documentation" for this is in the CmmParse.y
|  module:
|  >
|  https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/c
|  > mm/CmmParse.y;b3b394b44e42f19ab7c23668a4008e4f728b51ba$151-165
|  >
|  > It wouldn't hurt to move all that to the wiki and leave a link
|  behind,
|  > if anyone wants to do that.
|  >
|  > Cheers
|  >
|  > Simon
|  >
|  >
|  >
|  >
|  >
|  > Hope that helps,
|  >
|  > Rahul
|  >
|  >
|  >
|  > On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan
|  > <[hidden email]>
|  > 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
|  > [hidden email]
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=04%7C01%7Csi
|  >
|  monpj%40microsoft.com%7Ce0440775dc534fcb0dca08d58e63c808%7C72f988bf86f
|  >
|  141af91ab2d7cd011db47%7C1%7C0%7C636571481562185434%7CUnknown%7CTWFpbGZ
|  >
|  sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1
|  > &sdata=DzEyrLjKI2jlGBd6J%2BqUUgKfCxW9XErYlRjDDK2rcaQ%3D&reserved=0
|  >
|  >
|  >
|  > --
|  >
|  > Rahul Muttineni
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > [hidden email]
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=04%7C01%7Csi
|  >
|  monpj%40microsoft.com%7Ce0440775dc534fcb0dca08d58e63c808%7C72f988bf86f
|  >
|  141af91ab2d7cd011db47%7C1%7C0%7C636571481562185434%7CUnknown%7CTWFpbGZ
|  >
|  sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1
|  > &sdata=DzEyrLjKI2jlGBd6J%2BqUUgKfCxW9XErYlRjDDK2rcaQ%3D&reserved=0
|  >
|  >
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > [hidden email]
|  >
|  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%7Ce0440775dc534fcb0dca08d5
|  8e63c808%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365714815621854
|  34%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
|  6Ik1haWwifQ%3D%3D%7C-
|  1&sdata=DzEyrLjKI2jlGBd6J%2BqUUgKfCxW9XErYlRjDDK2rcaQ%3D&reserved=0
|  >
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs