Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bytecode Format Megathread #6

Open
icculus opened this issue Sep 7, 2022 · 1 comment
Open

Bytecode Format Megathread #6

icculus opened this issue Sep 7, 2022 · 1 comment
Assignees

Comments

@icculus
Copy link
Collaborator

icculus commented Sep 7, 2022

Work has started on defining the bytecode format, and is ongoing:

https://github.com/icculus/SDL_shader_tools/blob/main/docs/README-bytecode-format.md

You can see a lot of these things aren't filled in yet, but that's mostly laziness on my part, and they will come with time. But there's enough there to let people sound alarms on crucial design choices.

@Akaricchi
Copy link

struct String {
    Uint32 num_words;  // number of 32-bit words this struct uses.
    Uint32 data[]; // num_words*4 of UTF-8 string data, NULL-terminated. Padded with zeroes to end on 32-bit boundary.
};

Why number of words instead of number of actually meaningful bytes?

struct Instruction {
    Uint32 opcode;   // each instruction type has a unique value.
    Uint32 num_words;  // number of 32-bit words this struct uses.
    Uint32 operands[];  // instructions are variable size
};

I'm not sure variable-sized instructions are a good idea. I can imagine cases where one would like to quickly parse all the instructions into an array before interpreting them. How much overhead do you expect from rounding everything up to the same size?

Also, are there any instructions where num_words is variable? If not, you could remove that field and provide an opcode -> size translation table as part of the spec instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants