anton-rs / cannon-rs

An alternative implementation of the OP Stack's Cannon, a MIPS emulator for the EVM.
MIT License
59 stars 10 forks source link

feat: The great MIPS64 migration #35

Open clabby opened 7 months ago

clabby commented 7 months ago

Overview

cannon-rs was started as a side project, as a way to learn more about cannon as well as spike out potential optimizations to the FPVM. Today, the project sits largely dormant as a fun toy.

As the OP Stack approaches the multi-proof future, space for new Fault Proof VMs comes into play. Currently, the Test in Prod team is working on bringing https://github.com/protolambda/asterisc to production readiness. cannon-rs sits in an odd spot, where it is just a faster version of cannon, bringing little value to the security of the OP Stack.

Instead of cannon-rs serving as an alternative implementation of cannon, it has the potential to serve as a 3rd fault proof VM with little modification - converting to the MIPS64 ISA. 64-bit register size gives many affordances - more platform support, larger memory address space, etc.

This project is pending specification. If anyone would like to pick this up, please signal below and I'd be glad to help specify the work and guide the project :)

GrapeBaBa commented 7 months ago

@clabby we would like to try it. @thinkAfCod and I are planning to try more rust projects this year.

merklefruit commented 7 months ago

I'd love to help if I can :)

GrapeBaBa commented 5 months ago

@clabby Based on the mips64 documentation and my own understanding, I completed the mips64 modification (including the current instruction set, registers and memory 64 bits, 8-byte alignment, excluding new instruction sets such as double-word support). Retested and found that the current asm file memory operation is 4-byte aligned, and the following code cannot be tested. I am not sure whether I must modify the asm file for 8-byte memory operations?

    #### Test code end ####

    sw      $v0, 8($s0)         # Set the test result
    sw      $s1, 4($s0)         # Set 'done'
clabby commented 5 months ago

@GrapeBaBa Thank you very much for starting work on this! Awesome to see 💪

These tests were pulled from OpenMips, which is an implementation of MIPS32r1. These should still work on a MIPS64 processor - When executing MIPS32 instructions on a MIPS64 processor, the alignment requirements of MIPS32 instructions should be preserved.

See page 27 of the architecture spec:

The CPU uses byte addressing for halfword, word, and doubleword accesses with the following alignment constraints: • Halfword accesses must be aligned on an even byte boundary (0, 2, 4...). • Word accesses must be aligned on a byte boundary divisible by four (0, 4, 8...). • Doubleword accesses must be aligned on a byte boundary divisible by eight (0, 8, 16...)

In other words - for MIPS32 instructions that read or write memory, the memory must preserve the ability to enforce single-word aligned accesses (32 bit / 4 byte alignment). For MIPS64 instructions, doubleword alignment rules apply when accessing memory.

GrapeBaBa commented 5 months ago

@clabby Right now all open_mips_tests passed, but vm tests failed, I changed the test_hello and found the error msg below. Haven't investigate deeply right now, any suggestions? fatal error: failed to get system page size\nruntime: panic before malloc heap initialized\n\nruntime stack:\nruntime.throw({0xa05e0, 0x1e})\n\t/opt/homebrew/Cellar/go/1.19.2/libexec/src/runtime/panic.go:1047 +0x54 fp=0xffffcf90 sp=0xffffcf7c pc=0x4f68c\nruntime.mallocinit()\n\t/opt/homebrew/Cellar/go/1.19.2/libexec/src/runtime/malloc.go:365 +0x5dc fp=0xffffcfc0 sp=0xffffcf90 pc=0x1ae08\nruntime.schedinit()\n\t/opt/homebrew/Cellar/go/1.19.2/libexec/src/runtime/proc.go:693 +0x108 fp=0xffffcff0 sp=0xffffcfc0 pc=0x545b0\nruntime.rt0_go()\n\t/opt/homebrew/Cellar/go/1.19.2/libexec/src/runtime/asm_mipsx.s:62 +0xac fp=0xffffd000 sp=0xffffcff0 pc=0x84ff8\n

GrapeBaBa commented 4 months ago

@clabby Except evm tests, all tests passed. Before the contract supports mips64, it may be necessary to review the rust code, especially the part about patch and memory handling.