Skip to content
This repository was archived by the owner on Apr 25, 2025. It is now read-only.

Binary format of br_on_cast #173

Closed
kripken opened this issue Jan 8, 2021 · 2 comments
Closed

Binary format of br_on_cast #173

kripken opened this issue Jan 8, 2021 · 2 comments

Comments

@kripken
Copy link
Member

kripken commented Jan 8, 2021

I am having trouble implementing it. I see the prototype doc says it has 3 immediates, the index of the block it targets, and two heap types. Given this:

(br_on_cast $out $B (ref.null $A) (rtt.canon $B))

Binaryen will emit this:

fb 42 00 02 00

fb is the GC prefix, 42 is the code for br_on_cast, and then the immediates come: 00 for the block target (it targets the block it is immediately in), then 02 for the first heap type, and then 00 for the second heap type it is trying to cast it to. But this last immediate errors in wasp with Unknown reference type: 0 and in v8 with block type index 0 is not a signature definition.

Should there be something else than a heap type for that immediate?

@jakobkummerow
Copy link
Contributor

See the comments on the prototype doc: we have implemented br_on_cast without the heap type immediates that the spec document currently demands.

The background is the discussion around dropping these immediates that can be deduced from the operand stack. In the interest of module binary size, it would be advantageous to drop them; however there were some concerns that super-simple interpreter-only implementations might benefit from having them. (Personally I think that module size for all eternity is a far stronger argument than implementation effort for super-simple (=early?) implementations; objectively speaking, the question hasn't been settled yet.) See WebAssembly/function-references#31
So in V8 we have implemented some instructions with and some without type immediates. You can see that (unfavorably) as chaos, or (favorably) as proof that both approaches are implementable :-)

@kripken
Copy link
Member Author

kripken commented Jan 8, 2021

I see, thanks @jakobkummerow ! I missed the comments and notes, sorry about that...

@kripken kripken closed this as completed Jan 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants