diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 013f49dc..d2f2330c 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -443,7 +443,7 @@
     - [Inline assembly](unsafe/asm.md)
 -->
 - [安全でない操作](unsafe.md)
-    - [Inline assembly](unsafe/asm.md)
+    - [インラインアセンブリ](unsafe/asm.md)
 
 <!--
 - [Compatibility](compatibility.md)
diff --git a/src/unsafe/asm.md b/src/unsafe/asm.md
index 1a3fab90..1439665c 100644
--- a/src/unsafe/asm.md
+++ b/src/unsafe/asm.md
@@ -1,21 +1,46 @@
+<!--
 # Inline assembly
+-->
+# インラインアセンブリ
 
+<!--
 Rust provides support for inline assembly via the `asm!` macro.
 It can be used to embed handwritten assembly in the assembly output generated by the compiler.
 Generally this should not be necessary, but might be where the required performance or timing
 cannot be otherwise achieved. Accessing low level hardware primitives, e.g. in kernel code, may also demand this functionality.
+-->
+Rustは`asm!`マクロによってインラインアセンブリをサポートしています。
+コンパイラが生成するアセンブリに、手書きのアセンブリを埋め込むことができます。
+一般的には必要ありませんが、要求されるパフォーマンスやタイミングを達成するために必要な場合があります。
+カーネルコードのような、低レベルなハードウェアの基本要素にアクセスする場合にも、この機能が必要でしょう。
 
+<!--
 > **Note**: the examples here are given in x86/x86-64 assembly, but other architectures are also supported.
+-->
+> **注意**: 以下の例はx86/x86-64アセンブリで書かれていますが、他のアーキテクチャもサポートされています。
 
+<!--
 Inline assembly is currently supported on the following architectures:
 - x86 and x86-64
 - ARM
 - AArch64
 - RISC-V
+-->
+インラインアセンブリは現在以下のアーキテクチャでサポートされています。
+- x86とx86-64
+- ARM
+- AArch64
+- RISC-V
 
+<!--
 ## Basic usage
+-->
+## 基本的な使い方
 
+<!--
 Let us start with the simplest possible example:
+-->
+最も単純な例から始めましょう。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -27,15 +52,28 @@ unsafe {
 # }
 ```
 
+<!--
 This will insert a NOP (no operation) instruction into the assembly generated by the compiler.
 Note that all `asm!` invocations have to be inside an `unsafe` block, as they could insert
 arbitrary instructions and break various invariants. The instructions to be inserted are listed
 in the first argument of the `asm!` macro as a string literal.
+-->
+これは、コンパイラが生成したアセンブリに、NOP (no operation) 命令を挿入します。
+すべての`asm!`呼び出しは、`unsafe`ブロックの中になければいけません。
+インラインアセンブリは任意の命令を挿入でき、不変条件を壊してしまうからです。
+挿入される命令は、文字列リテラルとして`asm!`マクロの第一引数に列挙されます。
 
+<!--
 ## Inputs and outputs
+-->
+## 入力と出力
 
+<!--
 Now inserting an instruction that does nothing is rather boring. Let us do something that
 actually acts on data:
+-->
+何もしない命令を挿入しても面白くありません。
+実際にデータを操作してみましょう。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -49,6 +87,7 @@ assert_eq!(x, 5);
 # }
 ```
 
+<!--
 This will write the value `5` into the `u64` variable `x`.
 You can see that the string literal we use to specify instructions is actually a template string.
 It is governed by the same rules as Rust [format strings][format-syntax].
@@ -59,10 +98,24 @@ We also need to specify in what kind of register the assembly expects the variab
 In this case we put it in an arbitrary general purpose register by specifying `reg`.
 The compiler will choose an appropriate register to insert into
 the template and will read the variable from there after the inline assembly finishes executing.
+-->
+これは`u64`型の変数`x`に`5`の値を書き込んでいます。
+命令を指定するために利用している文字列リテラルが、実はテンプレート文字列になっています。
+これはRustの[フォーマット文字列][format-syntax]と同じルールに従います。
+ですが、テンプレートに挿入される引数は、みなさんがよく知っているものとは少し違っています。
+まず、変数がインラインアセンブリの入力なのか出力なのかを指定する必要があります。
+上記の例では出力となっています。
+`out`と書くことで出力であると宣言しています。
+また、アセンブリが変数をどの種類のレジスタに格納するかについても指定する必要があります。
+上の例では、`reg`を指定して任意の汎用レジスタに格納しています。
+コンパイラはテンプレートに挿入する適切なレジスタを選び、インラインアセンブリの実行終了後、そのレジスタから変数を読みこみます。
 
 [format-syntax]: https://doc.rust-lang.org/std/fmt/#syntax
 
+<!--
 Let us see another example that also uses an input:
+-->
+入力を利用する別の例を見てみましょう。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -82,25 +135,49 @@ assert_eq!(o, 8);
 # }
 ```
 
+<!--
 This will add `5` to the input in variable `i` and write the result to variable `o`.
 The particular way this assembly does this is first copying the value from `i` to the output,
 and then adding `5` to it.
+-->
+この例では、変数`i`の入力に`5`を加え、その結果を変数`o`に書き込んでいます。
+このアセンブリ特有のやり方として、はじめに`i`の値を出力にコピーし、それから`5`を加えています。
 
+<!--
 The example shows a few things:
+-->
+この例はいくつかのことを示します。
 
+<!--
 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.
+-->
+まず、`asm!`では複数のテンプレート文字列を引数として利用できます。
+それぞれの文字列は、改行を挟んで結合されたのと同じように、独立したアセンブリコードとして扱われます。
+このおかげで、アセンブリコードを容易にフォーマットできます。
 
+<!--
 Second, we can see that inputs are declared by writing `in` instead of `out`.
+-->
+つぎに、入力は`out`ではなく`in`と書くことで宣言されています。
 
+<!--
 Third, we can see that we can specify an argument number, or name as in any format string.
 For inline assembly templates this is particularly useful as arguments are often used more than once.
 For more complex inline assembly using this facility is generally recommended, as it improves
 readability, and allows reordering instructions without changing the argument order.
+-->
+そして、他のフォーマット文字列と同じように引数を番号や名前で指定できます。
+インラインアセンブリのテンプレートでは、引数が2回以上利用されることが多いため、これは特に便利です。
+より複雑なインラインアセンブリを書く場合、この機能を使うのが推奨されます。
+可読性が向上し、引数の順序を変えることなく命令を並べ替えることができるからです。
 
+<!--
 We can further refine the above example to avoid the `mov` instruction:
+-->
+上記の例をさらに改善して、`mov`命令をやめることもできます。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -114,10 +191,17 @@ assert_eq!(x, 8);
 # }
 ```
 
+<!--
 We can see that `inout` is used to specify an argument that is both input and output.
 This is different from specifying an input and output separately in that it is guaranteed to assign both to the same register.
+-->
+`inout`で入力でもあり出力でもある引数を指定しています。
+こうすることで、入力と出力を個別に指定する場合と違って、入出力が同じレジスタに割り当てられることが保証されます。
 
+<!--
 It is also possible to specify different variables for the input and output parts of an `inout` operand:
+-->
+`inout`のオペランドとして、入力と出力それぞれに異なる変数を指定することも可能です。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -132,8 +216,12 @@ assert_eq!(y, 8);
 # }
 ```
 
+<!--
 ## Late output operands
+-->
+## 遅延出力オペランド
 
+<!--
 The Rust compiler is conservative with its allocation of operands. It is assumed that an `out`
 can be written at any time, and can therefore not share its location with any other argument.
 However, to guarantee optimal performance it is important to use as few registers as possible,
@@ -141,8 +229,19 @@ so they won't have to be saved and reloaded around the inline assembly block.
 To achieve this Rust provides a `lateout` specifier. This can be used on any output that is
 written only after all inputs have been consumed.
 There is also a `inlateout` variant of this specifier.
-
+-->
+Rustコンパイラはオペランドの割り当てに保守的です。
+`out`はいつでも書き込めるので、他の引数とは場所を共有できません。
+しかし、最適なパフォーマンスを保証するためには、できるだけ少ないレジスタを使うことが重要です。
+そうすることで、インラインアセンブリブロックの前後でレジスタを保存したり再読み込みしたりする必要がありません。
+これを達成するために、Rustは`lateout`指定子を提供します。
+全ての入力が消費された後でのみ書き込まれる出力に利用できます。
+この指定子には`inlateout`という変化形もあります。
+
+<!--
 Here is an example where `inlateout` *cannot* be used in `release` mode or other optimized cases:
+-->
+以下は、`release`モードやその他の最適化された場合に、`inlateout`を利用 *できない* 例です。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -163,11 +262,25 @@ unsafe {
 assert_eq!(a, 12);
 # }
 ```
+<!--
 The above could work well in unoptimized cases (`Debug` mode), but if you want optimized performance (`release` mode or other optimized cases), it could not work.
+-->
+上記は`Debug`モードなど最適化されていない場合にはうまく動作します。
+しかし、`release`モードなど最適化されたパフォーマンスが必要な場合、動作しない可能性があります。
 
+<!--
 That is because in optimized cases, the compiler is free to allocate the same register for inputs `b` and `c` since it knows they have the same value. However it must allocate a separate register for `a` since it uses `inout` and not `inlateout`. If `inlateout` was used, then `a` and `c` could be allocated to the same register, in which case the first instruction to overwrite the value of `c` and cause the assembly code to produce the wrong result.
-
+-->
+というのも、最適化されている場合、コンパイラは`b`と`c`が同じ値だと知っているので、
+`b`と`c`の入力に同じレジスタを割り当てる場合があります。
+しかし、`a`については`inlateout`ではなく`inout`を使っているので、独立したレジスタを割り当てる必要があります。
+もし`inlateout`が使われていたら、`a`と`c`に同じレジスタが割り当てられたかもしれません。
+そうすると、最初の命令によって`c`の値が上書きされ、アセンブリコードが間違った結果を引き起こします。
+
+<!--
 However the following example can use `inlateout` since the output is only modified after all input registers have been read:
+-->
+しかし、次の例では、全ての入力レジスタが読み込まれた後でのみ出力が変更されるので、`inlateout`を利用できます。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -182,13 +295,25 @@ assert_eq!(a, 8);
 # }
 ```
 
+<!--
 As you can see, this assembly fragment will still work correctly if `a` and `b` are assigned to the same register.
+-->
+このアセンブリコードは、`a`と`b`が同じレジスタに割り当てられても、正しく動作します。
 
+<!--
 ## Explicit register operands
+-->
+## 明示的なレジスタオペランド
 
+<!--
 Some instructions require that the operands be in a specific register.
 Therefore, Rust inline assembly provides some more specific constraint specifiers.
 While `reg` is generally available on any architecture, explicit registers are highly architecture specific. E.g. for x86 the general purpose registers `eax`, `ebx`, `ecx`, `edx`, `ebp`, `esi`, and `edi` among others can be addressed by their name.
+-->
+いくつかの命令では、オペランドが特定のレジスタにある必要があります。
+したがって、Rustのインラインアセンブリでは、より具体的な制約指定子を提供しています。
+`reg`は一般的にどのアーキテクチャでも利用可能ですが、明示的レジスタはアーキテクチャに強く依存しています。
+たとえば、x86の汎用レジスタである`eax`、`ebx`、`ecx`、`edx`、`ebp`、`esi`、`edi`などは、その名前で指定できます。
 
 ```rust,no_run
 # #[cfg(target_arch = "x86_64")] {
@@ -201,11 +326,24 @@ unsafe {
 # }
 ```
 
+<!--
 In this example we call the `out` instruction to output the content of the `cmd` variable to port `0x64`. Since the `out` instruction only accepts `eax` (and its sub registers) as operand we had to use the `eax` constraint specifier.
+-->
+この例では、`out`命令を呼び出して、`cmd`変数の中身を`0x64`ポートに出力しています。
+`out`命令は`eax`とそのサブレジスタのみをオペランドとして受け取るため、
+`eax`の制約指定子を使わなければなりません。
 
+<!--
 > **Note**: unlike other operand types, explicit register operands cannot be used in the template string: you can't use `{}` and should write the register name directly instead. Also, they must appear at the end of the operand list after all other operand types.
+-->
+> **注意**: 他のオペランドタイプと異なり、明示的なレジスタオペランドはテンプレート文字列中で利用できません。
+`{}`を使えないので、レジスタの名前を直接書く必要があります。
+また、オペランドのリストの中で他のオペランドタイプの一番最後に置かれなくてはなりません。
 
+<!--
 Consider this example which uses the x86 `mul` instruction:
+-->
+x86の`mul`命令を使った次の例を考えてみましょう。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -219,6 +357,8 @@ fn mul(a: u64, b: u64) -> u128 {
         asm!(
             // The x86 mul instruction takes rax as an implicit input and writes
             // the 128-bit result of the multiplication to rax:rdx.
+            // x86のmul命令はraxを暗黙的な入力に取り、
+            // 128ビットの乗算結果をrax:rdxに書き込む。
             "mul {}",
             in(reg) a,
             inlateout("rax") b => lo,
@@ -231,18 +371,37 @@ fn mul(a: u64, b: u64) -> u128 {
 # }
 ```
 
+<!--
 This uses the `mul` instruction to multiply two 64-bit inputs with a 128-bit result.
 The only explicit operand is a register, that we fill from the variable `a`.
 The second operand is implicit, and must be the `rax` register, which we fill from the variable `b`.
 The lower 64 bits of the result are stored in `rax` from which we fill the variable `lo`.
 The higher 64 bits are stored in `rdx` from which we fill the variable `hi`.
-
+-->
+`mul`命令を使って2つの64ビットの入力を128ビットの結果に出力しています。
+唯一の明示的なオペランドはレジスタで、変数`a`から入力します。
+2つ目のオペランドは暗黙的であり、`rax`レジスタである必要があります。変数`b`から`rax`レジスタに入力します。
+計算結果の下位64ビットは`rax`レジスタに保存され、そこから変数`lo`に出力されます。
+上位64ビットは`rdx`レジスタに保存され、そこから変数`hi`に出力されます。
+
+<!--
 ## Clobbered registers
+-->
+## クロバーレジスタ
 
+<!--
 In many cases inline assembly will modify state that is not needed as an output.
 Usually this is either because we have to use a scratch register in the assembly or because instructions modify state that we don't need to further examine.
 This state is generally referred to as being "clobbered".
 We need to tell the compiler about this since it may need to save and restore this state around the inline assembly block.
+-->
+多くの場合、インラインアセンブリは出力として必要のない状態を変更することがあります。
+これは普通、アセンブリでスクラッチレジスタを利用する必要があったり、
+私たちがこれ以上必要としていない状態を命令が変更したりするためです。
+この状態を一般的に"クロバー"（訳注：上書き）と呼びます。
+私たちはコンパイラにこのことを伝える必要があります。
+なぜならコンパイラは、インラインアセンブリブロックの前後で、
+この状態を保存して復元しなくてはならない可能性があるからです。
 
 ```rust
 use std::arch::asm;
@@ -250,11 +409,16 @@ use std::arch::asm;
 # #[cfg(target_arch = "x86_64")]
 fn main() {
     // three entries of four bytes each
+    // 4バイトのエントリー3つ
     let mut name_buf = [0_u8; 12];
     // String is stored as ascii in ebx, edx, ecx in order
     // Because ebx is reserved, the asm needs to preserve the value of it.
     // So we push and pop it around the main asm.
     // (in 64 bit mode for 64 bit processors, 32 bit processors would use ebx)
+    // 文字列はasciiとしてebx, edx, ecxの順に保存されている。
+    // ebxは予約されているので、アセンブリはebxの値を維持する必要がある。
+    // 従ってメインのアセンブリの前後でプッシュおよびポップを行う。
+    // (以下は64ビットプロセッサの64ビットモードの場合。32ビットプロセッサはebxを利用する。)
 
     unsafe {
         asm!(
@@ -269,10 +433,17 @@ fn main() {
             // This is more explicit with how the asm works however, as opposed
             // to explicit register outputs such as `out("ecx") val`
             // The *pointer itself* is only an input even though it's written behind
+            // いくつかのアセンブリ命令を追加してRustのコードを単純化するために
+            // 値を格納する配列へのポインタを利用する。
+            // しかし、`out("ecx") val`のような明示的なレジスタの出力とは違い、
+            // アセンブリの動作をより明示的にする。
+            // *ポインタそのもの* は後ろに書かれていても入力にすぎない。
             in("rdi") name_buf.as_mut_ptr(),
             // select cpuid 0, also specify eax as clobbered
+            // cpuid 0を選択し、eaxをクロバーに指定する
             inout("eax") 0 => _,
             // cpuid clobbers these registers too
+            // cpuidは以下のレジスタもクロバーする
             out("ecx") _,
             out("edx") _,
         );
@@ -286,22 +457,50 @@ fn main() {
 # fn main() {}
 ```
 
+<!--
 In the example above we use the `cpuid` instruction to read the CPU manufacturer ID.
 This instruction writes to `eax` with the maximum supported `cpuid` argument and `ebx`, `edx`, and `ecx` with the CPU manufacturer ID as ASCII bytes in that order.
+-->
+上の例では、`cpuid`命令を使い、CPUベンタIDを読み込んでいます。
+この命令は`eax`にサポートされている最大の`cpuid`引数を書き込み、
+`ebx`、`edx`、`ecx`の順にCPUベンダIDをASCIIコードとして書き込みます。
 
+<!--
 Even though `eax` is never read we still need to tell the compiler that the register has been modified so that the compiler can save any values that were in these registers before the asm. This is done by declaring it as an output but with `_` instead of a variable name, which indicates that the output value is to be discarded.
+-->
+`eax`は読み込まれることはありません。
+しかし、コンパイラがアセンブリ以前にこれらのレジスタにあった値を保存できるように、
+レジスタが変更されたことをコンパイラに伝える必要があります。
+そのために、変数名の代わりに`_`を用いて出力を宣言し、出力の値が破棄されるということを示しています。
 
+<!--
 This code also works around the limitation that `ebx` is a reserved register by LLVM. That means that LLVM assumes that it has full control over the register and it must be restored to its original state before exiting the asm block, so it cannot be used as an input or output **except** if the compiler uses it to fulfill a general register class (e.g. `in(reg)`). This makes `reg` operands dangerous when using reserved registers as we could unknowingly corrupt our input or output because they share the same register.
-
+-->
+このコードは`ebx`がLLVMによって予約されたレジスタであるという制約を回避しています。
+LLVMは、自身がレジスタを完全にコントロールし、
+アセンブリブロックを抜ける前に元の状態を復元しなくてはならないと考えています。
+そのため、コンパイラが`in(reg)`のような汎用レジスタクラスを満たすために使用する場合 **を除いて** `ebx`を入力や出力として利用できません。
+つまり、予約されたレジスタを利用する場合に、`reg`オペランドは危険なのです。入力と出力が同じレジスタを共有しているので、知らないうちに入力や出力を破壊してしまうかもしれません。
+
+<!--
 To work around this we use `rdi` to store the pointer to the output array, save `ebx` via `push`, read from `ebx` inside the asm block into the array and then restore `ebx` to its original state via `pop`. The `push` and `pop` use the full 64-bit `rbx` version of the register to ensure that the entire register is saved. On 32 bit targets the code would instead use `ebx` in the `push`/`pop`.
+-->
+これを回避するために、`rdi`を用いて出力の配列へのポインタを保管し、`push`で`ebx`を保存し、アセンブリブロック内で`ebx`から読み込んで配列に書き込み、`pop`で`ebx`を元の状態に戻しています。
+`push`と`pop`は完全な64ビットの`rbx`レジスタを使って、レジスタ全体を確実に保存しています。
+32ビットの場合、`push`と`pop`において`ebx`がかわりに利用されるでしょう。
 
+<!--
 This can also be used with a general register class to obtain a scratch register for use inside the asm code:
+-->
+アセンブリコード内部で利用するスクラッチレジスタを獲得するために、
+汎用レジスタクラスとともに使用することもできます。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
 use std::arch::asm;
 
 // Multiply x by 6 using shifts and adds
+// シフト演算と加算を利用してxに6をかける
 let mut x: u64 = 4;
 unsafe {
     asm!(
@@ -317,9 +516,19 @@ assert_eq!(x, 4 * 6);
 # }
 ```
 
+<!--
 ## Symbol operands and ABI clobbers
+-->
+## シンボル・オペランドとABIクロバー
 
+<!--
 By default, `asm!` assumes that any register not specified as an output will have its contents preserved by the assembly code. The [`clobber_abi`] argument to `asm!` tells the compiler to automatically insert the necessary clobber operands according to the given calling convention ABI: any register which is not fully preserved in that ABI will be treated as clobbered.  Multiple `clobber_abi` arguments may be provided and all clobbers from all specified ABIs will be inserted.
+-->
+デフォルトでは、`asm!`は、出力として指定されていないレジスタはアセンブリコードによって中身が維持される、と考えます。
+`asm!`に渡される[`clobber_abi`]引数は、与えられた呼び出し規約のABIに従って、
+必要なクロバーオペランドを自動的に挿入するようコンパイラに伝えます。
+そのABIで完全に保存されていないレジスタは、クロバーとして扱われます。
+複数の `clobber_abi` 引数を指定すると、指定されたすべてのABIのクロバーが挿入されます。
 
 [`clobber_abi`]: ../../reference/inline-assembly.html#abi-clobbers
 
@@ -338,13 +547,17 @@ fn call_foo(arg: i32) -> i32 {
         asm!(
             "call {}",
             // Function pointer to call
+            // 呼び出す関数ポインタ
             in(reg) foo,
             // 1st argument in rdi
+            // 最初の引数はrdiにある
             in("rdi") arg,
             // Return value in rax
+            // 戻り値はraxにある
             out("rax") result,
             // Mark all registers which are not preserved by the "C" calling
             // convention as clobbered.
+            // "C"の呼び出し規約で保存されていないすべてのレジスタをクロバーに指定
             clobber_abi("C"),
         );
         result
@@ -353,13 +566,27 @@ fn call_foo(arg: i32) -> i32 {
 # }
 ```
 
+<!--
 ## Register template modifiers
+-->
+## レジスタテンプレート修飾子
 
+<!--
 In some cases, fine control is needed over the way a register name is formatted when inserted into the template string. This is needed when an architecture's assembly language has several names for the same register, each typically being a "view" over a subset of the register (e.g. the low 32 bits of a 64-bit register).
+-->
+テンプレート文字列に挿入されるレジスタの名前のフォーマット方法について、細かい制御が必要な場合があります。
+アーキテクチャのアセンブリ言語が、同じレジスタに別名を持っている場合です。
+典型的な例としては、レジスタの部分集合に対する"ビュー"があります（例：64ビットレジスタの下位32ビット）。
 
+<!--
 By default the compiler will always choose the name that refers to the full register size (e.g. `rax` on x86-64, `eax` on x86, etc).
+-->
+デフォルトでは、コンパイラは常に完全なレジスタサイズの名前を選択します（例：x86-64では`rax`、x86では`eax`、など）。
 
+<!--
 This default can be overridden by using modifiers on the template string operands, just like you would with format strings:
+-->
+この挙動は、フォーマット文字列と同じように、テンプレート文字列のオペランドに修飾子を利用することで上書きできます。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -375,18 +602,38 @@ assert_eq!(x, 0xabab);
 # }
 ```
 
+<!--
 In this example, we use the `reg_abcd` register class to restrict the register allocator to the 4 legacy x86 registers (`ax`, `bx`, `cx`, `dx`) of which the first two bytes can be addressed independently.
+-->
+この例では、`reg_abcd`レジスタクラスを用いて、レジスタアロケータを4つのレガシーなx86レジスタ (`ax`, `bx`, `cx`, `dx`) に制限しています。このうち最初の2バイトは独立して指定できます。
 
+<!--
 Let us assume that the register allocator has chosen to allocate `x` in the `ax` register.
 The `h` modifier will emit the register name for the high byte of that register and the `l` modifier will emit the register name for the low byte. The asm code will therefore be expanded as `mov ah, al` which copies the low byte of the value into the high byte.
+-->
+レジスタアロケータが`x`を`ax`レジスタに割り当てることにしたと仮定しましょう。
+`h`修飾子はそのレジスタの上位バイトのレジスタ名を出力し、`l`修飾子は下位バイトのレジスタ名を出力します。
+したがって、このアセンブリコードは`mov ah, al`に展開され、値の下位バイトを上位バイトにコピーします。
 
+<!--
 If you use a smaller data type (e.g. `u16`) with an operand and forget to use template modifiers, the compiler will emit a warning and suggest the correct modifier to use.
+-->
+より小さなデータ型（例：`u16`）をオペランドに利用し、テンプレート修飾子を使い忘れた場合、
+コンパイラは警告を出力し、正しい修飾子を提案してくれます。
 
+<!--
 ## Memory address operands
+-->
+## メモリアドレスオペランド
 
+<!--
 Sometimes assembly instructions require operands passed via memory addresses/memory locations.
 You have to manually use the memory address syntax specified by the target architecture.
 For example, on x86/x86_64 using Intel assembly syntax, you should wrap inputs/outputs in `[]` to indicate they are memory operands:
+-->
+アセンブリ命令はオペランドがメモリアドレスやメモリロケーション経由で渡される必要なこともあります。
+そのときは手動で、ターゲットのアーキテクチャによって指定されたメモリアドレスのシンタックスを利用しなくてはなりません。
+例えば、Intelのアセンブリシンタックスを使うx86/x86_64の場合、入出力を`[]`で囲んで、メモリオペランドであることを示さなくてはなりません。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -400,17 +647,40 @@ fn load_fpu_control_word(control: u16) {
 # }
 ```
 
+<!--
 ## Labels
+-->
+## ラベル
 
+<!--
 Any reuse of a named label, local or otherwise, can result in an assembler or linker error or may cause other strange behavior. Reuse of a named label can happen in a variety of ways including:
+-->
+名前つきラベルの再利用は、ローカルかそうでないかに関わらず、アセンブラやリンカのエラーを引き起こしたり、変な挙動の原因となります。
+名前つきラベルの再利用は以下のようなケースがあります。
 
+<!--
 -   explicitly: using a label more than once in one `asm!` block, or multiple times across blocks.
 -   implicitly via inlining: the compiler is allowed to instantiate multiple copies of an `asm!` block, for example when the function containing it is inlined in multiple places.
 -   implicitly via LTO: LTO can cause code from *other crates* to be placed in the same codegen unit, and so could bring in arbitrary labels.
+-->
+- 明示的再利用: 同じラベルを1つの`asm!`ブロック中で、または複数のブロック中で2回以上利用する場合です。
+- インライン化による暗黙の再利用: コンパイラは`asm!`ブロックの複数のコピーをインスタンス化する場合があります。例えば、`asm!`ブロックを含む関数が複数箇所でインライン化される場合です。
+- LTO(訳注: Link Time Optimizationの略)による暗黙の再利用: LTOは *他のクレート* のコードを同じコード生成単位に配置するため、同じ名前のラベルを持ち込む場合があります。
 
+<!--
 As a consequence, you should only use GNU assembler **numeric** [local labels] inside inline assembly code. Defining symbols in assembly code may lead to assembler and/or linker errors due to duplicate symbol definitions.
+-->
+そのため、インラインアセンブリコードの中では、GNUアセンブラの **数値型** [ローカルラベル][local labels]のみ使用してください。
+アセンブリコード内でシンボルを定義すると、シンボル定義の重複により、アセンブラやリンカのエラーが発生する可能性があります。
 
+<!--
 Moreover, on x86 when using the default Intel syntax, due to [an LLVM bug], you shouldn't use labels exclusively made of `0` and `1` digits, e.g. `0`, `11` or `101010`, as they may end up being interpreted as binary values. Using `options(att_syntax)` will avoid any ambiguity, but that affects the syntax of the _entire_ `asm!` block. (See [Options](#options), below, for more on `options`.)
+-->
+さらに、x86でデフォルトのIntel構文を使用する場合、[LLVMのバグ][an LLVM bug]によって、
+`0`、`11`、`101010`といった`0`と`1`だけで構成されたラベルは、
+バイナリ値として解釈されてしまうため、使用してはいけません。
+`options(att_syntax)`を使うと曖昧さを避けられますが、`asm!`ブロック _全体_ の構文に影響します。
+(`options`については、後述の[オプション](#options)を参照してください。)
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -434,21 +704,41 @@ assert_eq!(a, 5);
 # }
 ```
 
+<!--
 This will decrement the `{0}` register value from 10 to 3, then add 2 and store it in `a`.
+-->
+このコードは、`{0}`のレジスタの値を10から3にデクリメントし、2を加え、`a`にその値を保存します。
 
+<!--
 This example shows a few things:
+-->
+この例は、以下のことを示しています。
 
+<!--
 - First, that the same number can be used as a label multiple times in the same inline block.
 - Second, that when a numeric label is used as a reference (as an instruction operand, for example), the suffixes “b” (“backward”) or ”f” (“forward”) should be added to the numeric label. It will then refer to the nearest label defined by this number in this direction.
+-->
+- まず、ラベルとして同じ数字を複数回、同じインラインブロックで利用できます。
+- つぎに、数字のラベルが参照として(例えば、命令のオペランドに)利用された場合、"b"("後方")や"f"("前方")の接尾辞が数字のラベルに追加されなくてはなりません。そうすることで、この数字の指定された方向の最も近いラベルを参照できます。
 
 [local labels]: https://sourceware.org/binutils/docs/as/Symbol-Names.html#Local-Labels
 [an LLVM bug]: https://bugs.llvm.org/show_bug.cgi?id=36144
 
+<!--
 ## Options
+-->
+## オプション
 
+<!--
 By default, an inline assembly block is treated the same way as an external FFI function call with a custom calling convention: it may read/write memory, have observable side effects, etc. However, in many cases it is desirable to give the compiler more information about what the assembly code is actually doing so that it can optimize better.
+-->
+デフォルトでは、インラインアセンブリブロックは、カスタム呼び出し規約をもつ外部のFFI関数呼び出しと同じように扱われます: メモリを読み込んだり書き込んだり、観測可能な副作用を持っていたりするかもしれません。
+しかし、多くの場合、アセンブリコードが実際に何をするかという情報を多く与えて、より最適化できる方が望ましいでしょう。
 
+<!--
 Let's take our previous example of an `add` instruction:
+-->
+先ほどの`add`命令の例を見てみましょう。
 
 ```rust
 # #[cfg(target_arch = "x86_64")] {
@@ -467,11 +757,24 @@ assert_eq!(a, 8);
 # }
 ```
 
+<!--
 Options can be provided as an optional final argument to the `asm!` macro. We specified three options here:
 - `pure` means that the asm code has no observable side effects and that its output depends only on its inputs. This allows the compiler optimizer to call the inline asm fewer times or even eliminate it entirely.
 - `nomem` means that the asm code does not read or write to memory. By default the compiler will assume that inline assembly can read or write any memory address that is accessible to it (e.g. through a pointer passed as an operand, or a global).
 - `nostack` means that the asm code does not push any data onto the stack. This allows the compiler to use optimizations such as the stack red zone on x86-64 to avoid stack pointer adjustments.
-
+-->
+オプションは`asm!`マクロの最後の任意引数として渡されます。
+ここでは3つのオプションを利用しました:
+- `pure`は、アセンブリコードが観測可能な副作用を持っておらず、出力は入力のみに依存することを意味します。これにより、コンパイラオプティマイザはインラインアセンブリの呼び出し回数を減らしたり、インラインアセンブリを完全に削除したりできます。
+- `nomem`は、アセンブリコードがメモリの読み書きをしないことを意味します。デフォルトでは、インラインアセンブリはアクセス可能なメモリアドレス(例えばオペランドとして渡されたポインタや、グローバルなど)の読み書きを行うとコンパイラは仮定しています。
+- `nostack`は、アセンブリコードがスタックにデータをプッシュしないことを意味します。これにより、コンパイラはx86-64のスタックレッドゾーンなどの最適化を利用し、スタックポインタの調整を避けることができます。
+
+<!--
 These allow the compiler to better optimize code using `asm!`, for example by eliminating pure `asm!` blocks whose outputs are not needed.
+-->
+これにより、コンパイラは、出力が全く必要とされていない純粋な`asm!`ブロックを削除するなどして、`asm!`を使ったコードをより最適化できます。
 
+<!--
 See the [reference](../../reference/inline-assembly.html) for the full list of available options and their effects.
+-->
+利用可能なオプションとその効果の一覧は[リファレンス](https://doc.rust-lang.org/stable/reference/inline-assembly.html)を参照してください。

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html xmlns='http://www.w3.org/1999/xhtml'>
<head>
<title>pFad - Phonifier reborn</title>
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
</head>
<body>
<h1>Pfad - The Proxy pFad of &#169; 2024 Garber Painting. All rights reserved.</h1>


<!-- Disclaimer -->
<p>Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.</p>
<br>
<p>Alternative Proxies:</p><p><a href="http://rainy.clevelandohioweatherforecast.com/php-proxy/index.php?q=https://patch-diff.githubusercontent.com/raw/rust-lang-ja/rust-by-example-ja/pull/183.diff" target="_blank">Alternative Proxy</a></p><p><a href="http://rainy.clevelandohioweatherforecast.com/pFad/index.php?u=https://patch-diff.githubusercontent.com/raw/rust-lang-ja/rust-by-example-ja/pull/183.diff" target="_blank">pFad Proxy</a></p><p><a href="http://rainy.clevelandohioweatherforecast.com/pFad/v3index.php?u=https://patch-diff.githubusercontent.com/raw/rust-lang-ja/rust-by-example-ja/pull/183.diff" target="_blank">pFad v3 Proxy</a></p><p><a href="http://rainy.clevelandohioweatherforecast.com/pFad/v4index.php?u=https://patch-diff.githubusercontent.com/raw/rust-lang-ja/rust-by-example-ja/pull/183.diff" target="_blank">pFad v4 Proxy</a></p></body>
</html>