BPF Archive mirror
 help / color / mirror / Atom feed
* ISA: "code pointer"/"address" clarity
@ 2024-03-18 17:04 dthaler1968
  2024-03-18 17:04 ` [Bpf] " dthaler1968=40googlemail.com
  0 siblings, 1 reply; 2+ messages in thread
From: dthaler1968 @ 2024-03-18 17:04 UTC (permalink / raw
  To: bpf, bpf

I have a slide about the following question at the end of the ISA
presentation
at IETF later today, so putting it on the list in case there are any
comments before
the meeting.

The jump instruction section defines CALL with src_reg = 0 as
"call helper function by address", with
> Historically, each helper function was identified by an address encoded in
the
> imm field. The available helper functions may differ for each program
type,
> but address values are unique across all program types.

First, this text is slightly confusing since imm is only 32-bits whereas the
document
never states the size of a memory pointers in the BPF VM.  One
interpretation is
that ALL pointers are 32-bits, and another interpretation is that the
pointer size
is up to the runtime, but one can only use the CALL instruction with larger
pointers
if the upper bits are zero so that all non-zero bits fit in imm.  It would
be helpful to
clarify either way.

The 64-bit immediate instructions section then says:

> src_reg	pseudocode		imm type	dst type
> 0x4		dst = code_addr(imm)	integer		code pointer

The use of "code pointer" rather than "code address" in the table above
to some readers may beg the question of whether a "code pointer" and an
"address" as used with the CALL instruction are the same or different.

It then goes on to say:
> code_addr(imm) gets the address of the instruction at a specified relative
offset
> in number of (64-bit) instructions

Which uses "address of the instruction", and that sounds synonymous with
"code pointer" so the reader wonders why the same term isn't used.

Is there a better way to clarify in the text what the intent is, either by
using the
same term in the table ("code address"?) or by distinguishing the
definitions
if they are different concepts?

I know in Linux the "address" of a helper function is internally implemented
as an index, but that could just be an implementation detail not worth
mentioning in the standard.

Although detailed discussion may be in a different document (e.g., the
"[PS] cross-platform helper functions" document mentioned in the charter,
or an ABI document) I'm wondering if there's some trivial wording
Improvement that should be made in the ISA draft.

Dave


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

* [Bpf] ISA: "code pointer"/"address" clarity
  2024-03-18 17:04 ISA: "code pointer"/"address" clarity dthaler1968
@ 2024-03-18 17:04 ` dthaler1968=40googlemail.com
  0 siblings, 0 replies; 2+ messages in thread
From: dthaler1968=40googlemail.com @ 2024-03-18 17:04 UTC (permalink / raw
  To: bpf, bpf

I have a slide about the following question at the end of the ISA
presentation
at IETF later today, so putting it on the list in case there are any
comments before
the meeting.

The jump instruction section defines CALL with src_reg = 0 as
"call helper function by address", with
> Historically, each helper function was identified by an address encoded in
the
> imm field. The available helper functions may differ for each program
type,
> but address values are unique across all program types.

First, this text is slightly confusing since imm is only 32-bits whereas the
document
never states the size of a memory pointers in the BPF VM.  One
interpretation is
that ALL pointers are 32-bits, and another interpretation is that the
pointer size
is up to the runtime, but one can only use the CALL instruction with larger
pointers
if the upper bits are zero so that all non-zero bits fit in imm.  It would
be helpful to
clarify either way.

The 64-bit immediate instructions section then says:

> src_reg	pseudocode		imm type	dst type
> 0x4		dst = code_addr(imm)	integer		code pointer

The use of "code pointer" rather than "code address" in the table above
to some readers may beg the question of whether a "code pointer" and an
"address" as used with the CALL instruction are the same or different.

It then goes on to say:
> code_addr(imm) gets the address of the instruction at a specified relative
offset
> in number of (64-bit) instructions

Which uses "address of the instruction", and that sounds synonymous with
"code pointer" so the reader wonders why the same term isn't used.

Is there a better way to clarify in the text what the intent is, either by
using the
same term in the table ("code address"?) or by distinguishing the
definitions
if they are different concepts?

I know in Linux the "address" of a helper function is internally implemented
as an index, but that could just be an implementation detail not worth
mentioning in the standard.

Although detailed discussion may be in a different document (e.g., the
"[PS] cross-platform helper functions" document mentioned in the charter,
or an ABI document) I'm wondering if there's some trivial wording
Improvement that should be made in the ISA draft.

Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

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

end of thread, other threads:[~2024-03-18 17:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-18 17:04 ISA: "code pointer"/"address" clarity dthaler1968
2024-03-18 17:04 ` [Bpf] " dthaler1968=40googlemail.com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).