Move Correctness and Validity section

This commit is contained in:
Jubilee Young 2023-04-07 22:00:45 -07:00
parent 0a89373cc3
commit aba56b9dd7
1 changed files with 23 additions and 11 deletions

View File

@ -52,17 +52,6 @@ asm := "asm!(" format_string *("," format_string) *("," operand) [","] ")"
global_asm := "global_asm!(" format_string *("," format_string) *("," operand) [","] ")"
```
## Correctness and Validity
In addition to all of the rules that follow, the string argument to `asm!` must ultimately become; after all other arguments are evaluated, formatting is performed, and operands are translated; assembly that is both syntactically correct and semantically valid for the target architecture. The formatting rules allow Rust to generate assembly with correct syntax. Rules concerning operands permit valid translation of Rust operands into and out of `asm!`. Adherence to these rules is necessary, but not sufficient, for the final assembly to be correct and valid. For instance:
- arguments may be placed in positions which are syntactically incorrect after formatting
- an instruction may be correctly written, but given architecturally invalid operands
- an architecturally unspecified instruction may be assembled into unspecified code
- a set of instructions, each correct and valid in isolation, may cause undefined behavior when placed in sequence
As a result, the following rules are _non-exhaustive_. Rust is not required to check the correctness and validity of the initial string nor the final assembly that is generated. The assembler may check for correctness and validity but is not required to do so. When using `asm!`, a typographical error may be sufficient to make a program unsound, and the rules for assembly may include thousands of pages architectural reference manuals. Programmers should exercise appropriate care.
## Scope
Inline assembly can be used in one of two ways.
@ -495,6 +484,29 @@ To avoid undefined behavior, these rules must be followed when using function-sc
> **Note**: As a general rule, the flags covered by `preserves_flags` are those which are *not* preserved when performing a function call.
### Correctness and Validity
In addition to all of the previous rules, the string argument to `asm!` must ultimately become—
after all other arguments are evaluated, formatting is performed, and operands are translated—
assembly that is both syntactically correct and semantically valid for the target architecture.
The formatting rules allow the compiler to generate assembly with correct syntax.
Rules concerning operands permit valid translation of Rust operands into and out of `asm!`.
Adherence to these rules is necessary, but not sufficient, for the final expanded assembly to be
both correct and valid. For instance:
- arguments may be placed in positions which are syntactically incorrect after formatting
- an instruction may be correctly written, but given architecturally invalid operands
- an architecturally unspecified instruction may be assembled into unspecified code
- a set of instructions, each correct and valid, may cause undefined behavior if placed in immediate succession
As a result, these rules are _non-exhaustive_. The compiler is not required to check the
correctness and validity of the initial string nor the final assembly that is generated.
The assembler may check for correctness and validity but is not required to do so.
When using `asm!`, a typographical error may be sufficient to make a program unsound,
and the rules for assembly may include thousands of pages of architectural reference manuals.
Programmers should exercise appropriate care, as invoking this `unsafe` capability comes with
assuming the responsibility of not violating rules of both the compiler or the architecture.
### Directives Support
Inline assembly supports a subset of the directives supported by both GNU AS and LLVM's internal assembler, given as follows.