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

32bit target support #436

Closed
acheroncrypto opened this issue Feb 3, 2023 · 2 comments
Closed

32bit target support #436

acheroncrypto opened this issue Feb 3, 2023 · 2 comments

Comments

@acheroncrypto
Copy link

I would like to make interpreter work on 32bit architechtures. Currently there is no compilation error and regular programs seem to work as expected but various memory readings during syscalls like InvokeSignedRust return invalid pointers which results in program fails to complete error.

Going by the comment of

// Memory map regions virtual addresses need to be (1 << VIRTUAL_ADDRESS_BITS) bytes apart.
// Also the region at index 0 should be skipped to catch NULL ptr accesses.

I've played with some of the values like MM_PROGRAM_START and VIRTUAL_ADDRESS_BITS and got some improvements(some of the memory translations ended up being correct during syscalls) but programs still failed to complete on 32bit and worked fine on 64bit after the changes.

And what's the effect of program-runtime-v2 on this? Particularly this part solana-labs/solana#29864:

Dynamic function calls replacing CPI and Syscalls
Replace VM nesting by dynamic linking using two levels of indirection
[Not MVP] Replace syscalls by CPI to built-in programs

A general advice on how to achieve this would be really helpful, thank you!

@Lichtso
Copy link

Lichtso commented Feb 17, 2023

Is this related to compiling the Interpreter for WASM or is there a different motivation of bringing it to 32 bit?
The thing is that our entire ecosystem relies on the implicit assumption of running 64bit guests on 64bit host systems.
So while not impossible, it is hard to pull off and will probably not receive much attention from our side.

That being said, the memory mapping system currently in place does assume that the 64bit address space is essentially for fat pointers which are split into a 32bit region index and a 32bit address space inside each region. We also have unaligned memory mapping, so that design broke down a little.

In program runtime v2, if we manage to remove address translation, then this will be a lot easier as the host could dictate the memory layout and also address space size, thus would be able to use 32 bit pointers.

@acheroncrypto
Copy link
Author

Yes, the motivation is to run programs in browsers with wasm32-unknown-unknown target as wasm64 is not ready yet.

Unfortunately, as you've said there seems to be a quite a bit of 64bit assumption of usize etc.

In program runtime v2, if we manage to remove address translation, then this will be a lot easier as the host could dictate the memory layout and also address space size, thus would be able to use 32 bit pointers.

That sounds great! All of the issues that I've run into so far with WASM seems to be caused by the address translation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants