BPF List
 help / color / mirror / Atom feed
* [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm
@ 2024-05-20 21:52 Dave Thaler
  2024-05-20 21:52 ` [Bpf] " Dave Thaler
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: Dave Thaler @ 2024-05-20 21:52 UTC (permalink / raw)
  To: bpf; +Cc: bpf, Dave Thaler, Dave Thaler

imm is defined as a 32-bit signed integer.

{MOV, K, ALU64} says it does "dst = src" (where src is 'imm') and it
does do dst = (s64)imm, which in that sense does sign extend imm. The MOVSX
instruction is explained as sign extending, so added the example of
{MOV, K, ALU64} to make this more clear.

{JLE, K, JMP} says it does "PC += offset if dst <= src" (where src is 'imm',
and the comparison is unsigned). This was apparently ambiguous to some
readers as to whether the comparison was "dst <= (u64)(u32)imm" or
"dst <= (u64)(s64)imm" so added an example to make this more clear.

v1 -> v2: Address comments from Yonghong

Signed-off-by: Dave Thaler <dthaler1968@googlemail.com>
---
 .../bpf/standardization/instruction-set.rst     | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index 997560aba..7bb1281c5 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -385,6 +385,19 @@ The ``MOVSX`` instruction does a move operation with sign extension.
 operands into 64-bit operands.  Unlike other arithmetic instructions,
 ``MOVSX`` is only defined for register source operands (``X``).
 
+``{MOV, K, ALU64}`` means::
+
+  dst = (s64)imm
+
+``{MOV, X, ALU}`` means::
+
+  dst = (u32)src
+
+``{MOVSX, X, ALU}`` with 'offset' 8 means::
+
+  dst = (u32)(s32)(s8)src
+
+
 The ``NEG`` instruction is only defined when the source bit is clear
 (``K``).
 
@@ -486,6 +499,10 @@ Example:
 
 where 's>=' indicates a signed '>=' comparison.
 
+``{JLE, K, JMP}`` means::
+
+  if dst <= (u64)(s64)imm goto +offset
+
 ``{JA, K, JMP32}`` means::
 
   gotol +imm
-- 
2.40.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [Bpf] [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm
  2024-05-20 21:52 [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm Dave Thaler
@ 2024-05-20 21:52 ` Dave Thaler
  2024-05-21  2:20 ` Yonghong Song
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 7+ messages in thread
From: Dave Thaler @ 2024-05-20 21:52 UTC (permalink / raw)
  To: bpf; +Cc: bpf, Dave Thaler, Dave Thaler

imm is defined as a 32-bit signed integer.

{MOV, K, ALU64} says it does "dst = src" (where src is 'imm') and it
does do dst = (s64)imm, which in that sense does sign extend imm. The MOVSX
instruction is explained as sign extending, so added the example of
{MOV, K, ALU64} to make this more clear.

{JLE, K, JMP} says it does "PC += offset if dst <= src" (where src is 'imm',
and the comparison is unsigned). This was apparently ambiguous to some
readers as to whether the comparison was "dst <= (u64)(u32)imm" or
"dst <= (u64)(s64)imm" so added an example to make this more clear.

v1 -> v2: Address comments from Yonghong

Signed-off-by: Dave Thaler <dthaler1968@googlemail.com>
---
 .../bpf/standardization/instruction-set.rst     | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
index 997560aba..7bb1281c5 100644
--- a/Documentation/bpf/standardization/instruction-set.rst
+++ b/Documentation/bpf/standardization/instruction-set.rst
@@ -385,6 +385,19 @@ The ``MOVSX`` instruction does a move operation with sign extension.
 operands into 64-bit operands.  Unlike other arithmetic instructions,
 ``MOVSX`` is only defined for register source operands (``X``).
 
+``{MOV, K, ALU64}`` means::
+
+  dst = (s64)imm
+
+``{MOV, X, ALU}`` means::
+
+  dst = (u32)src
+
+``{MOVSX, X, ALU}`` with 'offset' 8 means::
+
+  dst = (u32)(s32)(s8)src
+
+
 The ``NEG`` instruction is only defined when the source bit is clear
 (``K``).
 
@@ -486,6 +499,10 @@ Example:
 
 where 's>=' indicates a signed '>=' comparison.
 
+``{JLE, K, JMP}`` means::
+
+  if dst <= (u64)(s64)imm goto +offset
+
 ``{JA, K, JMP32}`` means::
 
   gotol +imm
-- 
2.40.1

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm
  2024-05-20 21:52 [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm Dave Thaler
  2024-05-20 21:52 ` [Bpf] " Dave Thaler
@ 2024-05-21  2:20 ` Yonghong Song
  2024-05-21  2:20   ` [Bpf] " Yonghong Song
  2024-05-22 18:21 ` David Vernet
  2024-05-25 17:50 ` patchwork-bot+netdevbpf
  3 siblings, 1 reply; 7+ messages in thread
From: Yonghong Song @ 2024-05-21  2:20 UTC (permalink / raw)
  To: Dave Thaler, bpf; +Cc: bpf, Dave Thaler


On 5/20/24 3:52 PM, Dave Thaler wrote:
> imm is defined as a 32-bit signed integer.
>
> {MOV, K, ALU64} says it does "dst = src" (where src is 'imm') and it
> does do dst = (s64)imm, which in that sense does sign extend imm. The MOVSX
> instruction is explained as sign extending, so added the example of
> {MOV, K, ALU64} to make this more clear.
>
> {JLE, K, JMP} says it does "PC += offset if dst <= src" (where src is 'imm',
> and the comparison is unsigned). This was apparently ambiguous to some
> readers as to whether the comparison was "dst <= (u64)(u32)imm" or
> "dst <= (u64)(s64)imm" so added an example to make this more clear.
>
> v1 -> v2: Address comments from Yonghong
>
> Signed-off-by: Dave Thaler <dthaler1968@googlemail.com>

Acked-by: Yonghong Song <yonghong.song@linux.dev>


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bpf] Re: [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm
  2024-05-21  2:20 ` Yonghong Song
@ 2024-05-21  2:20   ` Yonghong Song
  0 siblings, 0 replies; 7+ messages in thread
From: Yonghong Song @ 2024-05-21  2:20 UTC (permalink / raw)
  To: Dave Thaler, bpf; +Cc: bpf, Dave Thaler


On 5/20/24 3:52 PM, Dave Thaler wrote:
> imm is defined as a 32-bit signed integer.
>
> {MOV, K, ALU64} says it does "dst = src" (where src is 'imm') and it
> does do dst = (s64)imm, which in that sense does sign extend imm. The MOVSX
> instruction is explained as sign extending, so added the example of
> {MOV, K, ALU64} to make this more clear.
>
> {JLE, K, JMP} says it does "PC += offset if dst <= src" (where src is 'imm',
> and the comparison is unsigned). This was apparently ambiguous to some
> readers as to whether the comparison was "dst <= (u64)(u32)imm" or
> "dst <= (u64)(s64)imm" so added an example to make this more clear.
>
> v1 -> v2: Address comments from Yonghong
>
> Signed-off-by: Dave Thaler <dthaler1968@googlemail.com>

Acked-by: Yonghong Song <yonghong.song@linux.dev>

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm
  2024-05-20 21:52 [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm Dave Thaler
  2024-05-20 21:52 ` [Bpf] " Dave Thaler
  2024-05-21  2:20 ` Yonghong Song
@ 2024-05-22 18:21 ` David Vernet
  2024-05-22 18:21   ` [Bpf] " David Vernet
  2024-05-25 17:50 ` patchwork-bot+netdevbpf
  3 siblings, 1 reply; 7+ messages in thread
From: David Vernet @ 2024-05-22 18:21 UTC (permalink / raw)
  To: Dave Thaler; +Cc: bpf, bpf, Dave Thaler

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Mon, May 20, 2024 at 02:52:55PM -0700, Dave Thaler wrote:
> imm is defined as a 32-bit signed integer.
> 
> {MOV, K, ALU64} says it does "dst = src" (where src is 'imm') and it
> does do dst = (s64)imm, which in that sense does sign extend imm. The MOVSX
> instruction is explained as sign extending, so added the example of
> {MOV, K, ALU64} to make this more clear.
> 
> {JLE, K, JMP} says it does "PC += offset if dst <= src" (where src is 'imm',
> and the comparison is unsigned). This was apparently ambiguous to some
> readers as to whether the comparison was "dst <= (u64)(u32)imm" or
> "dst <= (u64)(s64)imm" so added an example to make this more clear.
> 
> v1 -> v2: Address comments from Yonghong
> 
> Signed-off-by: Dave Thaler <dthaler1968@googlemail.com>

Acked-by: David Vernet <void@manifault.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bpf] Re: [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm
  2024-05-22 18:21 ` David Vernet
@ 2024-05-22 18:21   ` David Vernet
  0 siblings, 0 replies; 7+ messages in thread
From: David Vernet @ 2024-05-22 18:21 UTC (permalink / raw)
  To: Dave Thaler; +Cc: bpf, bpf, Dave Thaler


[-- Attachment #1.1: Type: text/plain, Size: 835 bytes --]

On Mon, May 20, 2024 at 02:52:55PM -0700, Dave Thaler wrote:
> imm is defined as a 32-bit signed integer.
> 
> {MOV, K, ALU64} says it does "dst = src" (where src is 'imm') and it
> does do dst = (s64)imm, which in that sense does sign extend imm. The MOVSX
> instruction is explained as sign extending, so added the example of
> {MOV, K, ALU64} to make this more clear.
> 
> {JLE, K, JMP} says it does "PC += offset if dst <= src" (where src is 'imm',
> and the comparison is unsigned). This was apparently ambiguous to some
> readers as to whether the comparison was "dst <= (u64)(u32)imm" or
> "dst <= (u64)(s64)imm" so added an example to make this more clear.
> 
> v1 -> v2: Address comments from Yonghong
> 
> Signed-off-by: Dave Thaler <dthaler1968@googlemail.com>

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: 88 bytes --]

-- 
Bpf mailing list -- bpf@ietf.org
To unsubscribe send an email to bpf-leave@ietf.org

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm
  2024-05-20 21:52 [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm Dave Thaler
                   ` (2 preceding siblings ...)
  2024-05-22 18:21 ` David Vernet
@ 2024-05-25 17:50 ` patchwork-bot+netdevbpf
  3 siblings, 0 replies; 7+ messages in thread
From: patchwork-bot+netdevbpf @ 2024-05-25 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 Mon, 20 May 2024 14:52:55 -0700 you wrote:
> imm is defined as a 32-bit signed integer.
> 
> {MOV, K, ALU64} says it does "dst = src" (where src is 'imm') and it
> does do dst = (s64)imm, which in that sense does sign extend imm. The MOVSX
> instruction is explained as sign extending, so added the example of
> {MOV, K, ALU64} to make this more clear.
> 
> [...]

Here is the summary with links:
  - [bpf-next,v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm
    https://git.kernel.org/bpf/bpf-next/c/4e1215d9a190

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] 7+ messages in thread

end of thread, other threads:[~2024-05-25 17:50 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-20 21:52 [PATCH bpf-next v2] bpf, docs: clarify sign extension of 64-bit use of 32-bit imm Dave Thaler
2024-05-20 21:52 ` [Bpf] " Dave Thaler
2024-05-21  2:20 ` Yonghong Song
2024-05-21  2:20   ` [Bpf] " Yonghong Song
2024-05-22 18:21 ` David Vernet
2024-05-22 18:21   ` [Bpf] " David Vernet
2024-05-25 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