Solidity: Yul planning

[axic]

This is an umbrella issue to cover the steps needed for Yul, the internal IR of Solidity. Yul aims to be fairly expressive, support basic types (bool, numbers) and be a source to generate both EVM and eWASM bytecode.

A superset of Yul, currently named Yul++ or Solidity--, can include "user defined types", which here means internal types of Solidity, like contracts, address, etc. This superset is also exposed to the user as "inline assembly".

Planned is to have transformations / optimisations on Yul as a middle layer.

Three targets / backends are proposed for Yul: EVM, "EVM 1.5" and eWASM.

1. eWASM can easily handle functions and translate them as-is
2. EVM needs a phase called "desugaring", which removes functions and replaces them with jumps
3. "EVM1.5" has support for functions ("subroutines") and only supports static jumps

In the compiler the following components are affected:

1. libsolidity/inlineasm is extended to support parsing Yul (and Yul++). It also exposes an AST structure which is returned by the parser and is supported as an input by the printer. Since this code is also able to parse current inline assembly, there should be a flag to switch between the two formats. Perhaps we could rename it libsolidity/yul. (flag has been added)
2. libsolidity/frontend is to be created, which receives the Solidity AST and produces a Yul AST
3. libsolidity/backend/evm is to be created, which receives the Yul AST and produces EVM bytecode - has been implemented
4. libsolidity/backend/evm15 is to be created, which receives the Yul AST and produces EVM1.5 bytecode - has been implemented
5. libsolidity/backend/ewasm is to be created, which receives the Yul AST and produces eWASM bytecode
6. Yul is to be supported in "JSON I/O" with the ability to receive Yul source code and output code generated by the selected backend

Another possible layout of code as discussed is:

• libjulia - AST, parser, printer (the current libsolidity/inlineasm)
• libjulia/backend/evm (doesn't uses libevmasm, but the peephole optimiser is copied from there)
• libjulia/backend/evm15
• libjulia/backend/ewasm
• libsolidity/codegen/evm (the current libsolidity/codegen, uses libevmasm)
• libsolidity/codegen/julia - the new Julia AST generator

The first milestone here is the ABI coder

[axic]

The API in StandardCompiler could be:

contractData["julia"] = m_compilerStack.julia(contractName);
contractData["ewasm"]["wast"] = solidity::julia::wast(m_compilerStack.julia(contractName));

[axic]

Possible input for JSON I/O:

{
  "language": "JULIA",
  "settings": {
  },
  "sources": [
    "function assert(x:bool)\n{\n        switch x\n                case false:bool:\n                {\n                        abort()\n                }\n}"
  ]
}

And output:

{
  errors: [],
  julia: "...", // transformed Julia based on the settings (i.e. fold in all "standard functions", run optimisation passes, etc)
  "evm": ..., // see JSON I/O
  "ewasm": ... // see JSON I/O
}

[axic]

@chriseth @pirapira if we could define an AST class for Julia, I could start writing an eWASM backend.

[axic]

Julia parser:

• [x] remove parentheses from functions return values
• [x] add types
• [x] accept multiple variables on a single let (tuples)
• [x] accept let without initial assignment
• [x] allow tuple assignments (single right hand expression)
• [x] disallow assignment from stack (=: variable)
• [x] accept bool as a type (it is a token)
• [x] accept evm instructions as identifiers
• [x] parse for
• [x] parse switch
• [x] parse if
• [x] support true and false as literals for bool
• [x] implement continue
• [x] implement break
• [ ] valdiate types of assignment/call

[axic]

Some other naming/acronym ideas:
Yul - Yet another Universal Language
Jul - Joyfully Universal Language
Julie - Joyfully/Yet another Universal Language without Instructions for Ethereum

[wanderer]

Yalll - Yet another Low Level Language

[axic]

I'd go for Y'all (Yet Another Low-level Language) aka. Texan Assembly

[roadriverrail]

As I live in Atlanta, Georgia, and do say "y'all," I very much approve of
this.

On Thu, Apr 27, 2017, 11:32 Alex Beregszaszi [e-mail]
wrote:

I'd go for Y'all (Yet Another Low-level Language) aka. Texan Assembly

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/solidity/issues/2131#issuecomment-297800668,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAlhYEfs_x9ZVo8NvthPp10bSeZBHMCAks5r0N8ngaJpZM4NBctk
.

[axic]

New name suggestion:

• CALI (Clever/Convenient Assembly Language as Intermediate language)
• CICL/CYCL (Clever Intermediate Compiler Language)

[chriseth]

JULIA - Joyfully Universal Language which is not Instructional Assembly

[axic]

I still have a grudge against the name Julia being used by another more known language :)

[christianpeel]

When I saw the title of @axic 's talk today at DevCon3 on "Julia – IR for Ethereum Contracts" my immediate thought was that the talk involved the scientific computing language Julia. This was also the impression of a Gnosis employee. Julia the scientific computing language has been around since 2009 or 2012, depending on which date one uses; I anticipate the use of the scientific language Julia to grow with upcoming releases. If the name of the IR language in this thread stays "Julia", naming collisions such as that which I experienced can be expected to increase.

I suggest the name for the IR language be changed to something different than Julia.

[cag]

Yeah, totally voting for "not Julia" to avoid confusion with the scientific computation language Julia.

[EricForgy]

Yeah, totally voting for "not Julia" to avoid confusion with the scientific computation language Julia.

Yes please :)

Julia is generally a great language not limited to scientific computing and there is a good chance we and / or others will use it for implementing smart contracts on Ethereum at some point so the chance of confusion is high I think.

[axic]

Some more proposals:

• sil (smartcontract intermediate language)
• ils (intermediate language for smartcontracts)
• slim (smartcontract language for intermediate "machines")
• circle (convenient intermediate representation of (smart)contracts in/of languagues for ethereum - I'm sure it is possible to find a backronym to pretty much everything, as stated by this monster)
• lir (language for intermediate representation of smartcontracts)
• iris (intermediate representation of (?) contracts)

[chriseth]

Decision was to use yul. Finally :)

[EricForgy]

Yay! :tada:

[chriseth]

Updated description a little.

[chriseth]

Ticked some more boxes. The only thing missing is type checking. Do we really need to keep this open for that, @axic?