Use const operand for ARM syscall implementation

[Ioan-Cristian]

asm_const feature has been stabilized in Rust 1.82. Using const operands for inline assembly eliminates a lot of the duplicated code in the ARM syscall implementation.

This commit has been tested by running a simple application that periodically blinks and writes a message on Raspberry Pi Pico.

[lschuermann]

The only difference I can see between this and the previous version is that now, you technically can invoke a system call class with a syscallX function that doesn't match its arity whereas previously the CLASS argument would've either been ignored, or an incorrect one would have resulted in an unreachable! panic.

However, these are clearly low-level unsafe primitives that have been intended as "raw" gadgets to issue system calls, and trust their caller's CLASS argument. So this difference seems unproblematic, or even desirable.

[Ioan-Cristian]

@lschuermann These are unsafe functions and unsafe functions can involve undefined behaviour if not used correctly. As such, it is in the caller's responsability to ensure they are correctly used, as you said.

[lschuermann]

@Ioan-Cristian While it is true that they are unsafe functions, the story is often more nuanced. If an unsafe function could do arbitrarily bad things, it'd never be safe to call. Therefore, the unsafe function should have a clear and concise contract that details the exact invariants that the caller must uphold for that unsafe function call to be sound.

In fact, these functions do have such a contract specified, namely in raw_syscalls.rs in libtock-platform:

libtock-rs/platform/src/raw_syscalls.rs

Lines 130 to 133 in 5b4d692

	/// # Safety
	/// This directly makes a system call. It can only be used for Memop calls
	/// that accept 1 argument and only overwrite r0 and r1 on return. It is
	/// unsafe any time the underlying system call is unsafe.

What I was trying to do with my comment above is reason about this contract (in particular, reasoning through the difference in behavior between the old and new versions), to conclude that these changes have no meaningful implications on existing callers.

In particular, the safety documentation of all syscallX and yieldX functions already contains a clause that implicitly limits the allowed CLASS arguments, which renders this change unproblematic.