Skip to content
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

feat: The great MIPS64 migration #35

Open
clabby opened this issue Apr 2, 2024 · 6 comments
Open

feat: The great MIPS64 migration #35

clabby opened this issue Apr 2, 2024 · 6 comments
Labels
enhancement New feature or request help wanted Extra attention is needed mipsevm Touches the `cannon-mipsevm` crate

Comments

@clabby
Copy link
Collaborator

clabby commented Apr 2, 2024

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 :)

@clabby clabby added enhancement New feature or request help wanted Extra attention is needed mipsevm Touches the `cannon-mipsevm` crate labels Apr 2, 2024
@GrapeBaBa
Copy link

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

@merklefruit
Copy link

I'd love to help if I can :)

@GrapeBaBa
Copy link

GrapeBaBa commented Jun 3, 2024

@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
Copy link
Collaborator Author

clabby commented Jun 3, 2024

@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
Copy link

@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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed mipsevm Touches the `cannon-mipsevm` crate
Projects
None yet
Development

No branches or pull requests

3 participants