Add options to asm

[taiki-e]

• Use nomem when neither memory access nor reordering prevention is needed.
• Use nostack when not pushing data to the stack.
• Use preserves_flags when not modifying the status register.
  refs: https://doc.rust-lang.org/nightly/unstable-book/language-features/asm-experimental-arch.html#flags-covered-by-preserves_flags
• Add comments explaining why specific options are not used.

refs: https://doc.rust-lang.org/nightly/reference/inline-assembly.html#options

cc #11
cc @cr1901

[taiki-e]

The optimization we want to prevent here is the removal of asm (nop), right?
If so, perhaps adding nomem and a comment like "Do not use pure because prevent nop from being removed" would be preferable.

[cr1901]

If I'm using nop, I'm probably using it for timing purposes. For timing between I/O reads/writes, which are inherently volatile (and thus won't be moved around the nop) there is no problem. But if I'm trying to time between doing an algorithm and an I/O read/write, I don't want the end of the algorithm to be moved after the nop.

So I think I want to hold off on adding nomem. The remaining flags look fine to me, I just want to test locally and see what happens w/ a test firmware :).

[taiki-e]

But if I'm trying to time between doing an algorithm and an I/O read/write, I don't want the end of the algorithm to be moved after the nop.

Hmm, I wonder if it would be preferable to explicitly use barriers in this use case.

Also, cortex-m crate seems to use nomem in nop.

[cr1901]

I wonder if it would be preferable to explicitly use barriers in this use case.

Inside the nop() fn implementation, or tell the user to add them manually when calling nop()?

[taiki-e]

I meant the latter.

[YuhanLiin]

Barrier looks like it does what nop does just without nomem. I think for something like nop we should follow what cortex-m does and use barrier for timing usecases. We should also document this distinction.

[cr1901]

I think for something like nop we should follow what cortex-m does and use barrier for timing usecases.

Fair enough; if the cortex-m ppl change nop behavior later, we can follow suit.

We should also document this distinction.

@taiki-e Would you be willing to add this documentation w/ an example, and then I'll accept this? Thanks!

[cr1901]

@taiki-e Did you get the chance to update this PR w/ documentation and an example? I would like to cut a release.

If not, we can wait until v0.4.1.

[taiki-e]

I've updated docs, but I'm not sure what is a good example here, so I didn't add examples.

[cr1901]

That's fine, no need for example. I meant an example like "put barriers before and after the nop sled" if the exact number of nops between I/O access is important".

In any case, merging this, thank you!