Add fiber implementation for riscv32imac

[max-dau]

This adds an implementation for riscv32imac (and other architectures with identical registers) to the internal fiber crate. This enables usage of the async feature of wasmtime on such platforms.

This feature was first discussed here on Zulip: #wasmtime > Wasmtime-fiber on RISCV32

Our concrete implementation was also discussed here: #wasmtime > Question about 64-bit RISC-V fiber implementation

[cfallin]

Thanks! This looks basically fine to me except for the alignment issue below and formatting nits.

[cfallin]

The spacing/formatting here and below is nonstandard. Could you ensure that there is no space before commas (see e.g. line 46 addi sp , sp , -0x40), and one space after commas (see e.g. this line sw ra,-0x4(sp))?

[max-dau]

I've adjusted the spacing around the commas in the newest commit. The spacing was also copied from the riscv64 implementation, so I've adjusted the spacing there too.

[cfallin]

If we want to be 16-byte-aligned, these two fields together are 8 bytes (two 32-bit pointers) so the whole struct is going to be off by 8 bytes, right?

Do we need additional padding between ra and last_sp?

[max-dau]

I was confused about this as well. In nostd.rs (and unix.rs), only the spot between ra and last_sp is explicitly documented to be 16-byte aligned. We also only move the stack pointer to that address, not to the very end of the struct.

I've tested both a version with and a version without 8 bytes of padding between ra and last_sp. Both work fine on my device. I'm honestly not sure whether padding is needed there. If you think we should add padding there, I am happy to add a commit introducing this padding.

[cfallin]

So I think a few things are going on here:

• The 16-byte alignment is required by the RISC-V ABI. Nothing in hardware enforces it (unlike aarch64, where an unaligned sp will actually cause a trap), but other functions are free to rely on stack alignment; so, for example, if we call some function in the fiber that eventually stores something to the stack with an aligned store, lack of alignment could cause a hard-to-diagnose segfault somewhere else. So we do need to ensure the stack as seen by the entry function to the fiber is aligned.
• On our 64-bit architectures, taking the end of a page and aligning the end of this struct with it will naturally provide 16-byte alignment to the top of the fiber save-frame, because the two words at the end -- the last_sp and the run_result -- are both pointers, i.e. 64-bit (8-byte) values.
• This is the first time we have (i) a 32-bit ISA with (ii) a 16-byte alignment requirement. So we need to be mindful of alignment here.

Given all that, I think if we put 8 bytes of padding before last_sp, we'll have satisfied the alignment requirements.

[max-dau]

I've added the padding in the newest commit, thanks for taking the time to look into this!

[cfallin]

Thanks!