Re: [Bpf] Review of draft-thaler-bpf-isa-01

[Will Hawkins <[e-mail]>]

Watson, thank you!

On Fri, Aug 11, 2023 at 5:36 PM Watson Ladd <[e-mail]> wrote:
>
> Dear David,
>
> Thank you very much for your lengthy and kind email. I agree that we
> should punt on contentious points and aim to standardize what has
> already been implemented across a wide range of implementations. Most
> of my issues are with the format and presentation of the text, and I
> think the content changes it would take are pretty noncontenous. I
> don't really have any insight into what the content should be, and I'm
> sure that for those who live and breath BPF every day, much of what I
> am confused about is indeed obvious.
>
> Concretely I think the following would help improve the
> understandability of the document:
> * After the register paragraph, describe the memory. As I understand
> it it is a 64 bit, byte addressed, flat space, and maps are just
> special regions in it. Maybe I'm wrong. There's some stuff about types
> in the big space of instructions that maybe makes me think I am wrong.
> * Say this is a 2's complement architecture

I just wanted to quickly follow up on this ... I, too, believe that we
should say this in the ISA and put forward a patch with some language.
You can see the discussion about that here:
https://lore.kernel.org/bpf/20230710215818.gCPVzgaK-YEXRFNixwcVrMLKlkiM0FqkQbUytFlDTQQ@z/

Thank you, again, for the conversation!
Will


> * I finally understand why the code fields have their low nybble zero.
> We should maybe say this.
> * Explicitly call out after 5.2 that there is no memory model yet
> * Pull up section 5.3.1 to the top, or figure out some way to punt it
> to an extension. Maybe introduce maps up top then explain how they are
> indexed here.
>
> For extensions if I think I understand the conversation at IETF 117,
> it's easy to add more calls to the host system as functions. It's a
> lot more of a difficulty to add more instructions, but in the wide
> encoding space there is room. We could definitely say that. The memory
> model should only modify the behavior of environments with races, so
> if things aren't racy, nothing changes. That should work, but maybe I
> don't understand what other extensions that people would want to add.
> Verification might be an extension, but probably not in the sense we
> need to worry about it here?
>
> I hope the above is helpful: as always my ignorance can completely
> negate the value of the concrete suggestion, but I do hope it
> highlights areas that could use some TLC.
>
> Sincerely,
> Watson Ladd
>
> --
> Astra mortemque praestare gradatim
>
> --
> Bpf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bpf