I can investigate adding a no_std mode, but in this mode only basic things like the trait definitions will be exported. Most of the interesting runtime parts (executable memory handling) do require std. Particularly annoying is that alloc doesn't contain HashMap, so implementing the label API as only requiring alloc would require changes. Outside of that though, as long as you just define the methods required by the DynasmApi/DynasmLabelApi traits you can already use the plugin on nightly now.

@losfair regarding leaving executable memory management to the user, the way current Assemblers are written is quite intertwined with this memory management, and there are a few ways I could go about this.

The first approach would be to just assemble into a temporary buffer, and then hand it over to the user to remap it (if necessary) after assembling. This would be OK for x64 but would not work for x86 as relocation information requires knowledge of the address the code will end up at.

The second approach would be to have the user reserve a large enough buffer at the start, and pass this to an Assembler for assembling. This would be ok on most instruction sets, as we can assume the buffer never moves. For bare metal situations this would probably be preferable as it works even on systems with complete manual memory management.

Finally, more complex approaches would be possible where dynasmrt would have an unsafe trait for memory management systems that the user could implement and use the full-fledged Assemblers. This would be more flexible but I'm not sure if there's any platforms that you would need this complexity on that do not have a functional libstd.

Do you have an idea of what would suit you best?

I'd prefer the first or the second method to keep things simple. However, I have a few questions about these two approaches:

• For the first approach, is it possible to emit code with 0x0 as the base address and some relocation info, and allow the user to do relocation later, after code is properly set up for execution (which is somehow similar to how dynamic libraries work, I suppose)?

• For the second approach, is it possible to determine the code size ahead of time so that we can allocate just the exact size and avoid wasting memory?

I think it would be possible to have relocations functioning properly with the first approach. This is already how the x86 Assembler backend deals with resizing its internal buffer, so copying the mechanism would be ok.

For the second approach, that would fully depend on the user being able to determine the code size ahead of time.

So the first approach is probably preferable (even though it'll cost a bit of extra memory due to the buffer copy involved).

hashbrown works with alloc only AFAIK.

Are there any plans on implementing this? I am asking because I am looking for no_std support in Wasmer which uses this crate for code generation. I could also try to implement this if there are mentoring instructions to it.

@1c3t3a Currently not from my side, but I'd be happy to assist with mentoring. The runtime support crate got some significant rework since this issue was opened in order to separate label, memory and relocation handling, which should make the required changes easier to implement.

Shouldn't it be pretty easy to add no_std + alloc support with no-std-compat?

That wouldn't work apparently, as no-std-compat doesn't handle std::io (how should it in an environment where it's unclear if there even is a filesystem).

std::io, std::fmt and friends are only used for Display/Debug implementations, which you probably don't need in no-std environments anyway.

As such an environment is probably a lot more limited in needed features, only the basic assembler, label handling and relocation logic needs to be properly ported.

Any updates on this? I'm also interested in using wasmer in a no_std environment where I do have alloc support.

Unfortunately I don't think anyone picked this up. I don't think I'll handle this one myself but I'd be happy to mentor / answer questions if anyone wants to work on it.

Fair enough. I saw there is a pull request open for no_std support, but I have no idea how far in progress it is. Regardless, I think even if this library supported no_std, wasmer would still require a bunch of work to become no_std compatible anyway. I'll simply have to take a look at the existing PR and see what I can do. Thanks for the work on dynasm though!

I completely forgot about that one, whoops. I also don't have any idea how up-to-date it is, but it is probably a good starting point!

I have added the support in #67, feel free to move the discussion over there