* [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst
@ 2024-04-05 15:52 Dave Thaler
2024-04-05 15:52 ` [Bpf] " Dave Thaler
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Dave Thaler @ 2024-04-05 15:52 UTC (permalink / raw)
To: bpf; +Cc: bpf, Dave Thaler
This patch addresses a number of editorial nits including
spelling, punctuation, grammar, and wording consistency issues
in instruction-set.rst.
Signed-off-by: Dave Thaler <dthaler1968@gmail.com>
---
.../bpf/standardization/instruction-set.rst | 47 ++++++++++---------
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index a5ab00ac0..8d0781f0b 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -43,7 +43,7 @@ a type's signedness (`S`) and bit width (`N`), respectively.
===== =========
For example, `u32` is a type whose valid values are all the 32-bit unsigned
-numbers and `s16` is a types whose valid values are all the 16-bit signed
+numbers and `s16` is a type whose valid values are all the 16-bit signed
numbers.
Functions
@@ -108,7 +108,7 @@ conformance group means it must support all instructions in that conformance
group.
The use of named conformance groups enables interoperability between a runtime
-that executes instructions, and tools as such compilers that generate
+that executes instructions, and tools such as compilers that generate
instructions for the runtime. Thus, capability discovery in terms of
conformance groups might be done manually by users or automatically by tools.
@@ -181,10 +181,13 @@ A basic instruction is encoded as follows::
(`64-bit immediate instructions`_ reuse this field for other purposes)
**dst_reg**
- destination register number (0-10)
+ destination register number (0-10), unless otherwise specified
+ (future instructions might reuse this field for other purposes)
**offset**
- signed integer offset used with pointer arithmetic
+ signed integer offset used with pointer arithmetic, except where
+ otherwise specified (some arithmetic instructions reuse this field
+ for other purposes)
**imm**
signed integer immediate value
@@ -228,10 +231,12 @@ This is depicted in the following figure::
operation to perform, encoded as explained above
**regs**
- The source and destination register numbers, encoded as explained above
+ The source and destination register numbers (unless otherwise
+ specified), encoded as explained above
**offset**
- signed integer offset used with pointer arithmetic
+ signed integer offset used with pointer arithmetic, unless
+ otherwise specified
**imm**
signed integer immediate value
@@ -342,8 +347,8 @@ where '(u32)' indicates that the upper 32 bits are zeroed.
dst = dst ^ imm
-Note that most instructions have instruction offset of 0. Only three instructions
-(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero offset.
+Note that most arithmetic instructions have 'offset' set to 0. Only three instructions
+(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero 'offset'.
Division, multiplication, and modulo operations for ``ALU`` are part
of the "divmul32" conformance group, and division, multiplication, and
@@ -370,10 +375,10 @@ etc. This specification requires that signed modulo use truncated division
a % n = a - n * trunc(a / n)
The ``MOVSX`` instruction does a move operation with sign extension.
-``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32
-bit operands, and zeroes the remaining upper 32 bits.
+``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into
+32-bit operands, and zeroes the remaining upper 32 bits.
``{MOVSX, X, ALU64}`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit
-operands into 64 bit operands. Unlike other arithmetic instructions,
+operands into 64-bit operands. Unlike other arithmetic instructions,
``MOVSX`` is only defined for register source operands (``X``).
The ``NEG`` instruction is only defined when the source bit is clear
@@ -411,19 +416,19 @@ conformance group.
Examples:
-``{END, TO_LE, ALU}`` with imm = 16/32/64 means::
+``{END, TO_LE, ALU}`` with 'imm' = 16/32/64 means::
dst = htole16(dst)
dst = htole32(dst)
dst = htole64(dst)
-``{END, TO_BE, ALU}`` with imm = 16/32/64 means::
+``{END, TO_BE, ALU}`` with 'imm' = 16/32/64 means::
dst = htobe16(dst)
dst = htobe32(dst)
dst = htobe64(dst)
-``{END, TO_LE, ALU64}`` with imm = 16/32/64 means::
+``{END, TO_LE, ALU64}`` with 'imm' = 16/32/64 means::
dst = bswap16(dst)
dst = bswap32(dst)
@@ -475,7 +480,7 @@ where 's>=' indicates a signed '>=' comparison.
gotol +imm
-where 'imm' means the branch offset comes from insn 'imm' field.
+where 'imm' means the branch offset comes from the 'imm' field.
Note that there are two flavors of ``JA`` instructions. The
``JMP`` class permits a 16-bit jump offset specified by the 'offset'
@@ -494,25 +499,25 @@ Helper functions are a concept whereby BPF programs can call into a
set of function calls exposed by the underlying platform.
Historically, each helper function was identified by an address
-encoded in the imm field. The available helper functions may differ
+encoded in the 'imm' field. The available helper functions may differ
for each program type, but address values are unique across all program types.
Platforms that support the BPF Type Format (BTF) support identifying
-a helper function by a BTF ID encoded in the imm field, where the BTF ID
+a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID
identifies the helper name and type.
Program-local functions
~~~~~~~~~~~~~~~~~~~~~~~
Program-local functions are functions exposed by the same BPF program as the
caller, and are referenced by offset from the call instruction, similar to
-``JA``. The offset is encoded in the imm field of the call instruction.
-A ``EXIT`` within the program-local function will return to the caller.
+``JA``. The offset is encoded in the 'imm' field of the call instruction.
+An ``EXIT`` within the program-local function will return to the caller.
Load and store instructions
===========================
For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the
-8-bit 'opcode' field is divided as::
+8-bit 'opcode' field is divided as follows::
+-+-+-+-+-+-+-+-+
|mode |sz |class|
@@ -580,7 +585,7 @@ instructions that transfer data between a register and memory.
dst = *(signed size *) (src + offset)
-Where size is one of: ``B``, ``H``, or ``W``, and
+Where '<size>' is one of: ``B``, ``H``, or ``W``, and
'signed size' is one of: s8, s16, or s32.
Atomic operations
--
2.40.1
^ permalink raw reply related [flat|nested] 5+ messages in thread* [Bpf] [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst
2024-04-05 15:52 [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst Dave Thaler
@ 2024-04-05 15:52 ` Dave Thaler
2024-04-05 17:40 ` David Vernet
2024-04-05 17:50 ` patchwork-bot+netdevbpf
2 siblings, 0 replies; 5+ messages in thread
From: Dave Thaler @ 2024-04-05 15:52 UTC (permalink / raw)
To: bpf; +Cc: bpf, Dave Thaler
This patch addresses a number of editorial nits including
spelling, punctuation, grammar, and wording consistency issues
in instruction-set.rst.
Signed-off-by: Dave Thaler <dthaler1968@gmail.com>
---
.../bpf/standardization/instruction-set.rst | 47 ++++++++++---------
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index a5ab00ac0..8d0781f0b 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -43,7 +43,7 @@ a type's signedness (`S`) and bit width (`N`), respectively.
===== =========
For example, `u32` is a type whose valid values are all the 32-bit unsigned
-numbers and `s16` is a types whose valid values are all the 16-bit signed
+numbers and `s16` is a type whose valid values are all the 16-bit signed
numbers.
Functions
@@ -108,7 +108,7 @@ conformance group means it must support all instructions in that conformance
group.
The use of named conformance groups enables interoperability between a runtime
-that executes instructions, and tools as such compilers that generate
+that executes instructions, and tools such as compilers that generate
instructions for the runtime. Thus, capability discovery in terms of
conformance groups might be done manually by users or automatically by tools.
@@ -181,10 +181,13 @@ A basic instruction is encoded as follows::
(`64-bit immediate instructions`_ reuse this field for other purposes)
**dst_reg**
- destination register number (0-10)
+ destination register number (0-10), unless otherwise specified
+ (future instructions might reuse this field for other purposes)
**offset**
- signed integer offset used with pointer arithmetic
+ signed integer offset used with pointer arithmetic, except where
+ otherwise specified (some arithmetic instructions reuse this field
+ for other purposes)
**imm**
signed integer immediate value
@@ -228,10 +231,12 @@ This is depicted in the following figure::
operation to perform, encoded as explained above
**regs**
- The source and destination register numbers, encoded as explained above
+ The source and destination register numbers (unless otherwise
+ specified), encoded as explained above
**offset**
- signed integer offset used with pointer arithmetic
+ signed integer offset used with pointer arithmetic, unless
+ otherwise specified
**imm**
signed integer immediate value
@@ -342,8 +347,8 @@ where '(u32)' indicates that the upper 32 bits are zeroed.
dst = dst ^ imm
-Note that most instructions have instruction offset of 0. Only three instructions
-(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero offset.
+Note that most arithmetic instructions have 'offset' set to 0. Only three instructions
+(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero 'offset'.
Division, multiplication, and modulo operations for ``ALU`` are part
of the "divmul32" conformance group, and division, multiplication, and
@@ -370,10 +375,10 @@ etc. This specification requires that signed modulo use truncated division
a % n = a - n * trunc(a / n)
The ``MOVSX`` instruction does a move operation with sign extension.
-``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32
-bit operands, and zeroes the remaining upper 32 bits.
+``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into
+32-bit operands, and zeroes the remaining upper 32 bits.
``{MOVSX, X, ALU64}`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit
-operands into 64 bit operands. Unlike other arithmetic instructions,
+operands into 64-bit operands. Unlike other arithmetic instructions,
``MOVSX`` is only defined for register source operands (``X``).
The ``NEG`` instruction is only defined when the source bit is clear
@@ -411,19 +416,19 @@ conformance group.
Examples:
-``{END, TO_LE, ALU}`` with imm = 16/32/64 means::
+``{END, TO_LE, ALU}`` with 'imm' = 16/32/64 means::
dst = htole16(dst)
dst = htole32(dst)
dst = htole64(dst)
-``{END, TO_BE, ALU}`` with imm = 16/32/64 means::
+``{END, TO_BE, ALU}`` with 'imm' = 16/32/64 means::
dst = htobe16(dst)
dst = htobe32(dst)
dst = htobe64(dst)
-``{END, TO_LE, ALU64}`` with imm = 16/32/64 means::
+``{END, TO_LE, ALU64}`` with 'imm' = 16/32/64 means::
dst = bswap16(dst)
dst = bswap32(dst)
@@ -475,7 +480,7 @@ where 's>=' indicates a signed '>=' comparison.
gotol +imm
-where 'imm' means the branch offset comes from insn 'imm' field.
+where 'imm' means the branch offset comes from the 'imm' field.
Note that there are two flavors of ``JA`` instructions. The
``JMP`` class permits a 16-bit jump offset specified by the 'offset'
@@ -494,25 +499,25 @@ Helper functions are a concept whereby BPF programs can call into a
set of function calls exposed by the underlying platform.
Historically, each helper function was identified by an address
-encoded in the imm field. The available helper functions may differ
+encoded in the 'imm' field. The available helper functions may differ
for each program type, but address values are unique across all program types.
Platforms that support the BPF Type Format (BTF) support identifying
-a helper function by a BTF ID encoded in the imm field, where the BTF ID
+a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID
identifies the helper name and type.
Program-local functions
~~~~~~~~~~~~~~~~~~~~~~~
Program-local functions are functions exposed by the same BPF program as the
caller, and are referenced by offset from the call instruction, similar to
-``JA``. The offset is encoded in the imm field of the call instruction.
-A ``EXIT`` within the program-local function will return to the caller.
+``JA``. The offset is encoded in the 'imm' field of the call instruction.
+An ``EXIT`` within the program-local function will return to the caller.
Load and store instructions
===========================
For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the
-8-bit 'opcode' field is divided as::
+8-bit 'opcode' field is divided as follows::
+-+-+-+-+-+-+-+-+
|mode |sz |class|
@@ -580,7 +585,7 @@ instructions that transfer data between a register and memory.
dst = *(signed size *) (src + offset)
-Where size is one of: ``B``, ``H``, or ``W``, and
+Where '<size>' is one of: ``B``, ``H``, or ``W``, and
'signed size' is one of: s8, s16, or s32.
Atomic operations
--
2.40.1
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [Bpf] [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst
2024-04-05 15:52 [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst Dave Thaler
2024-04-05 15:52 ` [Bpf] " Dave Thaler
@ 2024-04-05 17:40 ` David Vernet
2024-04-05 17:40 ` David Vernet
2024-04-05 17:50 ` patchwork-bot+netdevbpf
2 siblings, 1 reply; 5+ messages in thread
From: David Vernet @ 2024-04-05 17:40 UTC (permalink / raw)
To: Dave Thaler; +Cc: bpf, bpf, Dave Thaler
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
On Fri, Apr 05, 2024 at 08:52:45AM -0700, Dave Thaler wrote:
> This patch addresses a number of editorial nits including
> spelling, punctuation, grammar, and wording consistency issues
> in instruction-set.rst.
>
> Signed-off-by: Dave Thaler <dthaler1968@gmail.com>
LG, thanks
Acked-by: David Vernet <void@manifault.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bpf] [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst
2024-04-05 17:40 ` David Vernet
@ 2024-04-05 17:40 ` David Vernet
0 siblings, 0 replies; 5+ messages in thread
From: David Vernet @ 2024-04-05 17:40 UTC (permalink / raw)
To: Dave Thaler; +Cc: bpf, bpf, Dave Thaler
[-- Attachment #1.1: Type: text/plain, Size: 335 bytes --]
On Fri, Apr 05, 2024 at 08:52:45AM -0700, Dave Thaler wrote:
> This patch addresses a number of editorial nits including
> spelling, punctuation, grammar, and wording consistency issues
> in instruction-set.rst.
>
> Signed-off-by: Dave Thaler <dthaler1968@gmail.com>
LG, thanks
Acked-by: David Vernet <void@manifault.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 76 bytes --]
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst
2024-04-05 15:52 [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst Dave Thaler
2024-04-05 15:52 ` [Bpf] " Dave Thaler
2024-04-05 17:40 ` David Vernet
@ 2024-04-05 17:50 ` patchwork-bot+netdevbpf
2 siblings, 0 replies; 5+ messages in thread
From: patchwork-bot+netdevbpf @ 2024-04-05 17:50 UTC (permalink / raw)
To: Dave Thaler; +Cc: bpf, bpf, dthaler1968
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Fri, 5 Apr 2024 08:52:45 -0700 you wrote:
> This patch addresses a number of editorial nits including
> spelling, punctuation, grammar, and wording consistency issues
> in instruction-set.rst.
>
> Signed-off-by: Dave Thaler <dthaler1968@gmail.com>
> ---
> .../bpf/standardization/instruction-set.rst | 47 ++++++++++---------
> 1 file changed, 26 insertions(+), 21 deletions(-)
Here is the summary with links:
- [bpf-next] bpf, docs: Editorial nits in instruction-set.rst
https://git.kernel.org/bpf/bpf-next/c/00d5d22a5b42
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-04-05 17:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-05 15:52 [PATCH bpf-next] bpf, docs: Editorial nits in instruction-set.rst Dave Thaler
2024-04-05 15:52 ` [Bpf] " Dave Thaler
2024-04-05 17:40 ` David Vernet
2024-04-05 17:40 ` David Vernet
2024-04-05 17:50 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox