Systematic support for call-by-value vs call-by-reference in EVM backend

Description

We would like to support boxed types in addition the current support for unboxed types.

Example builtin non-immediate types:

  • Signature (65 bytes, r, s, v fields)

And then at some point we need to handle strings: immediate, non-immediate? A new kind of "indirect" values?

  • a ByteString has a length + an offset in memory.

What we need

  • Notion of immediate vs non-immediate types.
  • Provide the proper interface for marshaling values to the EVM. Type descriptors with methods for storing / loading etc...

Patches for gerbil-ethereum

Tracked here.

Patches for Glow

Type descriptors (See: !158)

  • boxed/unboxed type descriptor
  • size descriptors
  • descriptors for conversion between objects, bytes.

Refactor current handling

Consensus code generator handles variables in the following way:

  1. Get type via lookup-type: 
    (def type (lookup-type (.@ self program) argument-name))
  2. Get length via param-length: 
    (def len (and type (param-length type)))
  3. Get static offset via lookup-variable-offset.
  4. Use mloadat / mstoreat to handle the variable's loading / storing.

Once EVM type descriptor interface is stabilized, we should use its methods instead. In consensus code generator:

  • Update define-small-functions to use EVM type descriptor methods.
  • Update compile-consensus-statement to use EVM type descriptor methods.
  • Update load-immediate-variable to use EVM type descriptor methods.
  • Update add-local-variable-to-frame to use EVM type descriptor methods.
  • Update add-temporary-variable-offset to use EVM type descriptor methods.
  • Update trivial-expression to use EVM type descriptor methods.
  • Update setup-tail-call to use EVM type descriptor methods.
  • Update compute-variable-offsets to use EVM type descriptor methods.

TODO how to integrate with EVM type descriptor methods? TODO any other areas we need to handle?

Edited by noel kwan