Return mapping from variables to registers in fate compilation #902

2022-09-01T21:33:19+09:00

ghallak commented

2022-09-01 21:33:19 +09:00

(Migrated from gitlab.com)

This PR will change the result of the compilation to include a mapping from variables to fate registers.

Code example:

contract X =
  function g(z) =
    let g = 1
    g + z

  entrypoint f() =
    let g = g(5)
    let h = g + 2
    h + h

main contract C =
  entrypoint f(x) =
    let x = x + x
    let y = x + x
    let x = y + y
    x + x

  entrypoint g() =
    let x = 3
    x + x

  entrypoint q(x) =
    x + 1

  stateful entrypoint xz() =
    let aa : X = Chain.create()
    aa.f()

Registers in the compilation result:

variables_registers =>
 #{{"C","f","x"} => {var,2},
   {"C","f","y"} => {var,1},
   {"C","g","x"} => {var,0},
   {"C","q","x"} => {arg,0},
   {"C","x","a"} => {var,0},
   {"X",".X.g","g"} => {var,0},
   {"X",".X.g","z"} => {arg,0},
   {"X","f","g"} => {var,0},
   {"X","f","h"} => {var,1}},

This PR will change the result of the compilation to include a mapping from variables to fate registers. Code example: ``` contract X = function g(z) = let g = 1 g + z entrypoint f() = let g = g(5) let h = g + 2 h + h main contract C = entrypoint f(x) = let x = x + x let y = x + x let x = y + y x + x entrypoint g() = let x = 3 x + x entrypoint q(x) = x + 1 stateful entrypoint xz() = let aa : X = Chain.create() aa.f() ``` Registers in the compilation result: ``` variables_registers => #{{"C","f","x"} => {var,2}, {"C","f","y"} => {var,1}, {"C","g","x"} => {var,0}, {"C","q","x"} => {arg,0}, {"C","x","a"} => {var,0}, {"X",".X.g","g"} => {var,0}, {"X",".X.g","z"} => {arg,0}, {"X","f","g"} => {var,0}, {"X","f","h"} => {var,1}}, ```

ghallak commented

2022-10-23 18:18:45 +09:00

(Migrated from gitlab.com)

@radrow Notice how the local function X.g is called .X.g. I'm using an existing function (aeso_fcode_to_fate:make_function_name/1) to get the functions names. I don't think we need this distinction in the names between local function and entrypoints. Should it just be called g instead of .X.g?

@radrow Notice how the local function `X.g` is called `.X.g`. I'm using an existing function (`aeso_fcode_to_fate:make_function_name/1`) to get the functions names. I don't think we need this distinction in the names between local function and entrypoints. Should it just be called `g` instead of `.X.g`?

zxq9 commented

2022-10-23 18:42:29 +09:00

(Migrated from gitlab.com)

Created by: radrow

Yes, let's make it just g. I think you can hack it around by calling that make name with the env set to entrypoint/nonprivate or something like that

*Created by: radrow* Yes, let's make it just g. I think you can hack it around by calling that make name with the env set to entrypoint/nonprivate or something like that

ghallak commented

2022-10-23 18:47:05 +09:00

(Migrated from gitlab.com)

I have made the change here f0db4fb96b9b6edcada96291d656a45c3eb1b924 and here is how the new output looks like:

variables_registers =>
 #{{"C","f","x"} => {var,2},
   {"C","f","y"} => {var,1},
   {"C","g","x"} => {var,0},
   {"C","q","x"} => {arg,0},
   {"C","x","a"} => {var,0},
   {"X","f","g"} => {var,0},
   {"X","f","h"} => {var,1},
   {"X","g","g"} => {var,0},
   {"X","g","z"} => {arg,0}}

I have made the change here f0db4fb96b9b6edcada96291d656a45c3eb1b924 and here is how the new output looks like: ``` variables_registers => #{{"C","f","x"} => {var,2}, {"C","f","y"} => {var,1}, {"C","g","x"} => {var,0}, {"C","q","x"} => {arg,0}, {"C","x","a"} => {var,0}, {"X","f","g"} => {var,0}, {"X","f","h"} => {var,1}, {"X","g","g"} => {var,0}, {"X","g","z"} => {arg,0}} ```

zxq9 commented

2022-10-24 20:06:05 +09:00

(Migrated from gitlab.com)

Created by: hanssv

Review: Dismissed

Looks good! Just checking, there is no usage of the compiler where the extra data is a burden? If so it might be an idea to make this configurable?

*Created by: hanssv* **Review:** Dismissed Looks good! Just checking, there is no usage of the compiler where the extra data is a burden? If so it might be an idea to make this configurable?

zxq9 commented

2022-10-25 15:16:11 +09:00

(Migrated from gitlab.com)

Created by: radrow

Review: Approved

*Created by: radrow* **Review:** Approved

ghallak commented

2022-10-25 15:21:20 +09:00

(Migrated from gitlab.com)

@hanssv I have added a compiler option that enables/disables the returning of the newly introduced map here ee37e187e8.

@hanssv I have added a compiler option that enables/disables the returning of the newly introduced map here ee37e187e892c32303370919ee048a21ec18e25f.

zxq9 commented

2022-10-25 15:40:54 +09:00

(Migrated from gitlab.com)

Created by: hanssv

Review: Approved

*Created by: hanssv* **Review:** Approved

zxq9 commented

2022-10-25 15:42:03 +09:00

(Migrated from gitlab.com)

Merged by: ghallak at 2022-10-25 06:42:03 UTC

*Merged by: ghallak at 2022-10-25 06:42:03 UTC*

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/sophia#902