Skip to content

Conversation

@BenJilks
Copy link

Trying to compile this for my armv7 based system, I ran into a platform not supported error from wasmer. In the latest version this issue is fixed.

So, I updated this project to use the latest version, and now everything is compiling fine.

BenJilks added 2 commits June 13, 2022 09:01
The current verion doesn't support certain architectures. For example
armv7, the platform I was trying to compile for. The latest version
works fine.
Since we're indexing from 0, this value should be one less. Using
u32::MAX also allows us to compile on 32bit systems without and overflow
error.

The tests have also been updated to reflect this.
@webmaster128
Copy link
Member

Thank you! May I ask about the use case for armv7? That would be the first 32 bit host environment and I would not be surprised if we assume hosts are >= 64 bit in a few places.

@BenJilks
Copy link
Author

The second commit was the only issue I had with that to get things compiling. There's still some issues wasmer itself during runtime but I'm working on a solution. It's not going to be fast but I just want it to sync with the network. Rusts usize typing really seems to work in general I guess.

I'm just trying to get things to compile and thought I'd push any changes that might improve things in general.

/// most 65536 pages, for a total of 2^32 bytes (4 gibibytes).
/// https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md
const MAX_WASM_MEMORY: usize = 4 * 1024 * 1024 * 1024;
const MAX_WASM_MEMORY: usize = u32::MAX as usize;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WebAssembly linear memory objects have sizes measured in pages. Each page is 65536 (2^16) bytes. In WebAssembly version 1, a linear memory can have at most 65536 pages, for a total of 2^32 bytes (4 gibibytes).

The value should be 4294967296 (4 GiB), not 4294967295 (2**32-1). Just the largest memory location is 4294967295 because counting starts at 0. That's the same as 0, 1, 2, 3 is 4 elements.

But the code can be rewritten in a way to overcome the limitation that you cannot store 4294967296 in an usize on a 32 bit system. Will send a PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you rebase this work into current main? The issue should be solved there and d2d5489 can be skipped.

@webmaster128
Copy link
Member

Done in #1346 and #1360

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

Successfully merging this pull request may close these issues.

2 participants