zink-lang / zink Goto Github PK

Which library is the bug in?

codegen

Which version of are you on?

0.0.0

Operating System

None

Describe the bug

1. The number comparison implementation will not work for different types or signed-integers and float types
2. the ge and le serie of operators are pointing to gt and lt incorrectly

logs

Describe the feature

requires the design of the ZOF to call the proper function index, also, JUMP implementations

Solution

No response

Have a lot of verbose crates due to the original design in the workspace, now we can remove most of them

1. runtime -> zink/testing

wasm runtime is in plan, but not now

2. evm

no need a new evm, will have evm jit in the future, not now

3. move WasmBuilder to cli/ek

this logic does not belong to the compiler, but a subcommand of cargo tbh

Describe the feature

• Introduce virtual stack
• Apply stack IO on operations

Solution

No response

Describe the feature

The last fragment of the MVP

Solution

No response

https://docs.wasmtime.dev/security.html

(module
  (type (;0;) (func (param i64 i64) (result i64)))
  (func $add (type 0) (param i64 i64) (result i64)
      local.get 1  
      local.get 0 
      i64.add))

;; PUSH1 0x10 
;; CALLDATALOAD
;; PUSH1 0x20 
;; CALLDATALOAD
;; ADD
;; PUSH1 0x00
;; MSTORE8
;; PUSH1 0x10
;; PUSH1 0x00
;; RETURN

both winch and cranelift don't work since they are for register-based target, need to write the compiler on our own now

As the first step of Zink language, parsing functions will just be the most direct way to verify this project

1. Load WASM into sections with instructions
2. parse the functions into Huff functions

Notes

Basic arithmetic operations and stack/memory operations will be enough

References

Huff Function

EDITED: skip huff and cranelift, to bytecode directly

Describe the feature

1. write some scripts to embed the compiled evm bytecode to the project
2. wrap evm and make it a testing util
3. logs
4. ...

Solution

No response

Describe the feature

For the local variables in the main function, we are currently managing it with memory, however, stack is enough, swap, swap, swap

Solution

No response

Describe the feature

hmmm, for a simple if-else condition in rust, it will be compiled to select in WASM directly even though WASM has if-else...

and this is why we currently not have simple if-else example, it doesn't work lmao

Solution

No response

Describe the feature

• rustdocs
• the book
• add vercel.json
• add CI for vercel

Solution

No response

Describe the feature

i32add | i64add -> add
...

• add
• mul
• sub
• div
• sdiv
• mod
• smod
• adddmod
• mulmod
• exp

Solution

No response

Describe the feature

write a script to do it

Solution

No response

Describe the feature

the order for arithmetic operators are different between wasm and evm bytecode, which requires us a swap1 before each of them with 1 more byte and 3 more gas spent

for example: sub, div

Solution

No response

Describe the feature

Support local.get and local.set, requires refactoring the locals implementation

Solution

No response

Describe the feature

We have already addressed all of the bitwise instructions from WASM to EVM bytecdoe, but due the issue for stack orders, they don't work for now, need to fix them and provide tests

Solution

No response

Describe the feature

upload binaries while tagging release

Solution

No response

Describe the feature

related to the memory allocator, after #46

Solution

No response

Describe the feature

Not sure how to reach this instruction for now, needs research

Solution

No response

Describe the feature

components of #41

comparing with if, br_if jumps to labels but not the end of the if-condition block, and loop could be block of branch br_if targets

Solution

No response

Describe the feature

• Tutorial
• Examples
• Command line tool
• Compiler
• Contributing
• Appendix
  • Operators
  • Optimization

Solution

No response

Describe the feature

For building the backtrace of compilation error

Solution

bubble errors from asm generation

Describe the feature

https://pengowray.github.io/wasm-ops/

need to support all of the MVP instructions to make sure the contracts are able to be totally compiled

Solution

there are different cases for this

1. have the same naming => just transform
2. different naming => mapping the names
3. unsupported instructions in EVM => implement them as macro asm codes
4. move all of WASM MVP instructions out of the visitor trait

Describe the feature

flowchart LR

Body --> Locals
Body --> Operators

we have logic visit operators now but no logic for defining locals

Solution

No response

Describe the feature

similar to #71

Solution

No response

Describe the feature

this.fib -> fib

Solution

No response

Describe the feature

make WAT code snippets highlighting for easy reading

Solution

embed https://rust-lang.github.io/mdBook/format/theme/syntax-highlighting.html while building the book

Describe the feature

1. set up a zink project (add-two)
2. compile it to EVM bytecode
3. test it with EVM

Solution

No response

Describe the feature

we don't have any of them atm, related to #20, to be specific, 0x98 - 0xBF in WASM instructions

Solution

No response

summary

1. addition example in zink
2. load compiled wasm with huff
3. evm bytecode as result
4. tests

Describe the feature

• context
• frame
• stack

Solution

No response

Describe the feature

like rust developers rarely use rustc directly, zink users may not use zinkc a lot as well, since the case is that developers are compiling their whole project to EVM bytecode, and this is the reason why we need elko

For compiling cargo project into evm byteocde with elko

1. compile the project into wasm
2. compile the output wasm to evm bytecode

Solution

No response

Describe the feature

Instructions in 0x96 - 0x9F ( especially for f64 ) and same for f32 if exist

Solution

No response

Describe the feature

important for promotion

Solution

No response

Describe the feature

1. fibonacci - benchmark the arithmetic operations
2. loop - benchmark the control flow

Solution

No response

Describe the feature

u16 <-> usize and the buffer limit checks are insane

Solution

No response

Describe the feature

just follow https://docs.soliditylang.org/en/latest/abi-spec.html

Solution

No response

Describe the feature

needs this shadow stack for

1. get local definitions
2. validate inputing types
3. validate stack usages
4. generate return
5. ...

Solution

No response

wasmtime-environ+ cranelift-wasm will be enough

Summary

including examples into the workspace have compilation problems, need to builder outside of target projects to build and post process the wasm output

1. Compile project to wasm
2. Move the compiled output to target/zinc

Describe the feature

If always converts to jumpi in solidity,

JUMPI accepts 1 for jump however this is for the end of the if block that we should follow the semantic of if but not JUMPI, append ISZERO for the JUMPI of if-block, should be solved with #51

Solution

No response

Problem

Need issue templates to format the issues / prs

Solution

1. provide issue templates in /.github/ISSUE_TEMPLATE/
2. custom
3. feature request
4. bug report
5. add config /.github/ISSUE_TEMPLATE/config.yml

Summary

1. opcode table
2. gas cost
3. from u8

Build logs via CI

• build docs
• deploy to github pages

Describe the feature

Inspired by https://eips.ethereum.org/EIPS/eip-3540, here we introduce Zink Object Format in this project, which makes Zink a common smart contract language for the industry.

ZOF is prepared for the Zink runtime in the future, which at least can execute EVM contract and WASM contract and customized contracts just for Zink.

This library will provide an Intermediate Representation for the zink runtime, WASM parser and EOF parser by default as well

Solution

No response

Exactly everything required by ERC20 🤔

https://github.com/zink-lang/zink/milestone/2

1. WebAssembly

Still far away to complete the MVP instructions of WASM, once we have implemented all of these, we can archive that any WASM program works for EVM.

1.1. Memory Allocator

The main blocker of compiling Zink projects EVM contracts in real world is that that we are currently missing the implementation of memory allocator:

Since EVM uses 32-byte as the basic unit for memory management, we need to implement our own memory allocator to align the compiled memory operations in WASM to EVM, see alloc::GlobalAlloc

1.2. Tests of Vector

This is what we can get directly from the implementation of 1.1, require tests for custom vector operations.

1.3. Instructions

reference to wasm-ops, complete the MVP instructions,

• Control Flow: select, br_table, call_indirect
• Data & State: global related instructions
• Memory: tests of loadN, storeN
• Comparison : tests for integers
• Bitwise: implement missed bitwise operations in EVM
• Arithmetic: div and rem are not tested
• Data Conversions: almost missing all of them

2. Contract Interfaces

To be a EVM contract : )

2.1. Selector

The selector implementation is free to go since EVM simply starts from the first byte of EVM binaries which is the main function in general.

The question is that shall we align our selector implementation to solidity?

Guess the answer is yes and no, it is really necessary to adapt the current infrastructure, but, we can do it better with the rust ecosystem, the most simple way to go is that we provide an external function select or just main in the compiled WASM, make it the main function, actually a jump table, jumping to specified function by the selector.

The problem needs to be solved is that, how we detect that if the selected function is called as a transaction or just a internal call? requires research on it.

2.2. Storage

Basically, we need to implement globals to reach this demand, besides, the storage operations require the implementation of host functions since it is out of basic instructions that we can translate from WASM to EVM bytecode.

2.3. Events

Events operations are similar to the storage implementation, however, it requires customized types as well.

3. Example for v0.2.0

ERC20 is reasonable, just do it!

ref: OpenZeppelin/openzeppelin-contracts/contracts/token/ERC20/ERC20.sol

Describe the feature

we only can do static type checks while compiling since the stack item of solidity is 256 bits, so whatever optimize the types or not doesn't matter to EVM, but still needs these types

• i128
• u128
• i256
• u256

Solution

Need an external library to implement these, mb defined in zink/numbers

for u256 operations, we can use host functions like ("zink", "u256_add"), etc, do it in EVM for saving space in WASM:

• u256::Zero -> ("zink", "u256_zero")

Describe the feature

memory related stuffs are different between dlmalloc ( allocator for WASM in rust ) and EVM

The main blocker of compiling Zink projects EVM contracts in real world is that that we are currently missing the implementation of memory allocator:

Since EVM uses 32-byte as the basic unit for memory management, we need to implement our own memory allocator to align the compiled memory operations in WASM to EVM, see alloc::GlobalAlloc

Solution

No response

Describe the feature

now we have ek which is designed for the package manager for zink projects, we need a binary zinkc just like rustc

Solution

• new command compile in cli/src/compile.rs
• new binary cli/bin/zinkc.rs

Describe the feature

drop dirty stack items at the end of blocks

Solution

No response