New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial Julia description #2129

Merged
merged 30 commits into from Nov 22, 2017

Conversation

Projects
None yet
5 participants
@axic
Member

axic commented Apr 18, 2017

Split off #2107 in order to show what layout I thought about.

Fixes #1484.

@axic axic added the in progress label Apr 18, 2017

@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 18, 2017

Member

Didn't wanted to push to #2107 because that messes up the comments (closes the ones we haven't addressed yet).

Member

axic commented Apr 18, 2017

Didn't wanted to push to #2107 because that messes up the comments (closes the ones we haven't addressed yet).

Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
@gnidan

This comment has been minimized.

Show comment
Hide comment
@gnidan

gnidan Apr 18, 2017

Question about this effort: is a formal description of the desugaring phase to be covered by this spec?

gnidan commented Apr 18, 2017

Question about this effort: is a formal description of the desugaring phase to be covered by this spec?

Show outdated Hide outdated docs/julia.rst
@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 18, 2017

Member

It may make sense to have a "blob" or "bytes" type, which is preallocated and can be used by mstore/mload/return/codecopy etc.

Essentially abstracting the memory into variables, where there could also be one referring to the entire memory.

Member

axic commented Apr 18, 2017

It may make sense to have a "blob" or "bytes" type, which is preallocated and can be used by mstore/mload/return/codecopy etc.

Essentially abstracting the memory into variables, where there could also be one referring to the entire memory.

@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth Apr 18, 2017

Contributor

@gnidan this spec is actually more abstract. Desugaring is only relevant for translating JULIA programs into EVM, but it can also translate into eWASM and EVM1.5.

@axic blob might also be an element of the higher level type system.

Contributor

chriseth commented Apr 18, 2017

@gnidan this spec is actually more abstract. Desugaring is only relevant for translating JULIA programs into EVM, but it can also translate into eWASM and EVM1.5.

@axic blob might also be an element of the higher level type system.

@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 18, 2017

Member

The usual example we have is allocating a memory object. This can obviously work on a reference/pointer basis:

    {
        let size := calldatasize()
        let data := allocate(size)
        // note, this operates 
        calldatacopy(data, 0, size)

        // load first 32 bytes
        let sig := mload32(data, 0)
    }

Not entirely sure whether it is practical or useful to have this other than as a pointer. Though my main motivation is that in wasm the memory most be expanded explicitly and not implicitly by writing out of bounds.

Member

axic commented Apr 18, 2017

The usual example we have is allocating a memory object. This can obviously work on a reference/pointer basis:

    {
        let size := calldatasize()
        let data := allocate(size)
        // note, this operates 
        calldatacopy(data, 0, size)

        // load first 32 bytes
        let sig := mload32(data, 0)
    }

Not entirely sure whether it is practical or useful to have this other than as a pointer. Though my main motivation is that in wasm the memory most be expanded explicitly and not implicitly by writing out of bounds.

@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 18, 2017

Member

The notes from today regarding the definition of "data":

{
     let offset, size := data "julia" {
     }
}

vs.

{
  let offset := dataOffset(dataName)
  let size := dataSize(dataName)
  data dataName "assembly" { ... }
  // interleaving instructions here will not be placed between the data chunks?
  data otherData "hex" 0x2348
}

or perhaps something like this

// Code consists of a single object. A single "code" node is the code of the object.
// Every (other) named object or data section is serialized and
// made accessible to datacopy / dataoffset / datasize
object {
	code {
		let size = datasize("runtime")
		let offset = allocate(size)
		// This will turn into a memory->memory copy for eWASM and
		// a codecopy for EVM
		datacopy(dataoffset("runtime"), offset, size)
		// this is a constructor and the runtime code is returned
		return(offset, size)
	}

	object "runtime" {
		code {
			// runtime code

			let size = datasize("Contract2")
			let offset = allocate(size)
			// This will turn into a memory->memory copy for eWASM and
			// a codecopy for EVM
			datacopy(dataoffset("Contract2"), offset, size)
			// constructor parameter is a single number 0x1234
			mstore(add(offset, size), 0x1234)
			create(offset, add(size, 32))
		}

                // Embedded object. Use case is that the outside is a factory contract,
                // and Contract2 is the code to be created by the factory
		object "Contract2" {
			code {
				...
			}

			object "runtime" {
				code {

				}
			}
		}

		data "Table1" "0x4123"
	}

	data "Table2" "0x4123"
}
Member

axic commented Apr 18, 2017

The notes from today regarding the definition of "data":

{
     let offset, size := data "julia" {
     }
}

vs.

{
  let offset := dataOffset(dataName)
  let size := dataSize(dataName)
  data dataName "assembly" { ... }
  // interleaving instructions here will not be placed between the data chunks?
  data otherData "hex" 0x2348
}

or perhaps something like this

// Code consists of a single object. A single "code" node is the code of the object.
// Every (other) named object or data section is serialized and
// made accessible to datacopy / dataoffset / datasize
object {
	code {
		let size = datasize("runtime")
		let offset = allocate(size)
		// This will turn into a memory->memory copy for eWASM and
		// a codecopy for EVM
		datacopy(dataoffset("runtime"), offset, size)
		// this is a constructor and the runtime code is returned
		return(offset, size)
	}

	object "runtime" {
		code {
			// runtime code

			let size = datasize("Contract2")
			let offset = allocate(size)
			// This will turn into a memory->memory copy for eWASM and
			// a codecopy for EVM
			datacopy(dataoffset("Contract2"), offset, size)
			// constructor parameter is a single number 0x1234
			mstore(add(offset, size), 0x1234)
			create(offset, add(size, 32))
		}

                // Embedded object. Use case is that the outside is a factory contract,
                // and Contract2 is the code to be created by the factory
		object "Contract2" {
			code {
				...
			}

			object "runtime" {
				code {

				}
			}
		}

		data "Table1" "0x4123"
	}

	data "Table2" "0x4123"
}
@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 19, 2017

Member

While I'm still against naming this JULIA (due to julialang.org), if we stick with this name, I propose to use the extension .julia, because the other one uses .jl.

Member

axic commented Apr 19, 2017

While I'm still against naming this JULIA (due to julialang.org), if we stick with this name, I propose to use the extension .julia, because the other one uses .jl.

@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 19, 2017

Member

Also once we settle on a name, I'd like to rename the ir field in the JSON I/O to the decided name of the IR.

Member

axic commented Apr 19, 2017

Also once we settle on a name, I'd like to rename the ir field in the JSON I/O to the decided name of the IR.

@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 20, 2017

Member

Explicit type conversion functions must be available in Julia, where converting from larger to shorter type will have overflow check and can cause runtime exception:

  • u32tobool(x:u32) -> (y:bool)
  • booltou32(x:bool) -> (y:u32)
  • u32tou64(x:u32) -> (y:u64)
  • u64tou32(x:u64) -> (y:u32)
  • etc.
Member

axic commented Apr 20, 2017

Explicit type conversion functions must be available in Julia, where converting from larger to shorter type will have overflow check and can cause runtime exception:

  • u32tobool(x:u32) -> (y:bool)
  • booltou32(x:bool) -> (y:u32)
  • u32tou64(x:u32) -> (y:u64)
  • u64tou32(x:u64) -> (y:u32)
  • etc.
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
+---------------------------------------------------------------------------------------------------------------+
| *Arithmetics* |
+---------------------------------------------------------------------------------------------------------------+
| addu256(x:u256, y:u256) -> z:u256 | x + y |

This comment has been minimized.

@chriseth

chriseth Apr 20, 2017

Contributor

All return values should be in parentheses

@chriseth

chriseth Apr 20, 2017

Contributor

All return values should be in parentheses

This comment has been minimized.

@pirapira

pirapira Apr 20, 2017

Member

That's kind-of inconsistent with our choice of a, b := f() without parentheses on the left-hand side.

@pirapira

pirapira Apr 20, 2017

Member

That's kind-of inconsistent with our choice of a, b := f() without parentheses on the left-hand side.

This comment has been minimized.

@chriseth

chriseth Apr 21, 2017

Contributor

I see, and the grammar also seems to be fine with no parentheses.

@chriseth

chriseth Apr 21, 2017

Contributor

I see, and the grammar also seems to be fine with no parentheses.

+---------------------------------------------------------------------------------------------------------------+
| shru256(x:u256, y:u256) -> z:u256 | logical right shift of x by y |
+---------------------------------------------------------------------------------------------------------------+
| saru256(x:u256, y:u256) -> z:u256 | arithmetic right shift of x by y |

This comment has been minimized.

@chriseth

chriseth Apr 20, 2017

Contributor

Same discussion as in Solidity applies here: If you have signed and unsigned types, you do not have to distinguish between arithmetic and logical shift.

@chriseth

chriseth Apr 20, 2017

Contributor

Same discussion as in Solidity applies here: If you have signed and unsigned types, you do not have to distinguish between arithmetic and logical shift.

This comment has been minimized.

@pirapira

pirapira Apr 20, 2017

Member

Why? I want both the arithmetic shift and logical shift on s64.

@pirapira

pirapira Apr 20, 2017

Member

Why? I want both the arithmetic shift and logical shift on s64.

This comment has been minimized.

@pirapira

pirapira Apr 20, 2017

Member

Ah, but not on u64 or u256.

@pirapira

pirapira Apr 20, 2017

Member

Ah, but not on u64 or u256.

This comment has been minimized.

@chriseth

chriseth Apr 21, 2017

Contributor

Perhaps it would be safer to only allow bit operations on a bit-type that has no direct meaning as a number.

@chriseth

chriseth Apr 21, 2017

Contributor

Perhaps it would be safer to only allow bit operations on a bit-type that has no direct meaning as a number.

This comment has been minimized.

@pirapira

pirapira Apr 24, 2017

Member

I don't think so.

@pirapira

pirapira Apr 24, 2017

Member

I don't think so.

@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 21, 2017

Member

Need to add object, code, data to the grammar.

Member

axic commented Apr 21, 2017

Need to add object, code, data to the grammar.

@axic

This comment has been minimized.

Show comment
Hide comment
@axic

axic Apr 21, 2017

Member

@chriseth @pirapira please review the grammar

Member

axic commented Apr 21, 2017

@chriseth @pirapira please review the grammar

Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst
Show outdated Hide outdated docs/julia.rst

@axic axic merged commit b7fb1bc into develop Nov 22, 2017

0 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
ci/circleci CircleCI is running your tests
Details
continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details

@axic axic deleted the julia branch Nov 22, 2017

@axic axic removed the in progress label Nov 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment