rv32i: transition llvm_asm! to asm! #2363
Conversation
arch/rv32i/src/syscall.rs
Outdated
There was a problem hiding this comment.
Why add all of the "", on each line?
There was a problem hiding this comment.
I've seen some examples of other people using asm!() doing that. It has the added benefit of my editor and rustfmt aligning the instructions correctly and detecting whether I'm using the correct, spaces-based indentation. I think either would be fine with me though.
There was a problem hiding this comment.
The Rust unstable book seems to prefer this syntax over multiline strings, for what it's worth.
There was a problem hiding this comment.
I do wish they would add more examples to the book. The longest assembly block there is just two instructions.
There was a problem hiding this comment.
I agree that the documentation is very sparse. Reading through the documentation again seems that using multiple strings was chosen exactly for the benefits I've noticed while using it (indentation, proper Rust comments). To cite them: "First, we can see that asm! allows multiple template string arguments; each one is treated as a separate line of assembly code, as if they were all joined together with newlines between them. This makes it easy to format assembly code."
As I said both is fine with me. Should I change it to be a multiline string?
There was a problem hiding this comment.
I'm typically on the side of smaller commits are better. However, I'm also a believer that if rustfmt doesn't enforce it then it's completely up to the author. I am worried about a collision with my stack pointer PR however :)
dc330e0 to
bc5c2e7
Compare
This assures that the compiler may never choose to pass the pointer to the Riscv32iStoredState in a register that is otherwise used and overwritten in the assembly (e.g. t0). Presumably this is a not a general issue, but specific to this assembly block, as we first store all registers and later restore them, but still rely on the values of the registers further down in the assembly, while overwriting specific ones with temporary values.
This potentially dangerous function is not referenced anywhere and hence can be removed, reducing the amount of unsafe code.
bc5c2e7 to
20c0698
Compare
|
I did the rebase needed because of my stack pointer changes, and I simplified the PR to just the changes needed which makes the diff much easier to compare. |
Fair enough. I have a slight preference over the other syntax, but in the end what really matters is that we have a consistent style around the Tock kernel. If we were to change it to the multi-string syntax (which the book seems to have a slight preference over) we should do so throughout the kernel, in a separate commit. Thanks for doing the work. |
|
There is certainly discussion about this: rust-lang/style-team#152. But I assume rustfmt will not actually add the |
|
bors r+ |
I didn't want to imply we must switch, and my personal preference probably doesn't matter much for the project. Sorry if my statements were a bit confusing. I haven't seen the rustfmt discussion, thanks for sharing the link. Maybe the best approach is to let dust settle there and see what the most commonly accepted and preferred syntax is in a few months? |
Pull Request Overview
This pull request transitions the remaining
llvm_asm!snippet of therv32itowards the new Rustasm!macro (see #1923 for the respective tracking issue). It's split up into commits that represent atomic changes respectively.In addition to the raw transition, this changes two things
it removes the unused
abort()/_abortfuction. It was previously public & safe, such that untrusted code could simply call to it.in
switch_to_process, it forces theRiscv32iStoredStatepointer to be passed in a specific register. This is important since, while we don't clobber any registers in the assembly block there, we do write tot0after we've saved it to the stack. Later, we access the stored state pointer (from some unspecified register). If the compiler were to put this information int0, we would access the overwritten contents instead. By fixing the state pointer to always be passed ina0(which the compiler has done up to now), we can rely on being able to safely overwritet0after it's been saved on the stack.Notably, knowing the register where the stored state is passed in potentially enables an optimization where we don't need to save it to the stack twice (and hence save a memory write & read). However, implementing that made the ASM quite a bit more confusing, so I might implement that as a follow up PR, once I find the time to write it in a clean fashion.
All in all, the abort function assembly is removed
and the
switch_to_processfunction seems to generate the exact same assembly.One weird thing about
asm!(): I tried to replace thelui+addibased immediate load by alipseudo-instruction, however the compiler complained that_return_to_kernelwas not a valid immediate value there, whereas it continues to work with the%hi/%loaccessors. The solution™ is to insert the immediate value as a constant, however we can't refer to an assembly label there. Hence leaving it the way it is.Testing Strategy
This pull request was tested by running a userspace app in the LiteX simulator and on the LiteX Arty board.
TODO or Help Wanted
This pull request still needs careful review. I can recommend stepping through the commits individually such that the changes can be reviewed separately.
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.