You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hm...I think that the access to the call stack is important. If the stack is accessible in some general way many different features could become directly implementable on WebAssembly, instead of relaying to custom stacks. That would required instructions for iterating (instead of walking #1340) the frames, blocks and variables. Currently, the variable types are i/f 32/64 and I would imagine, that the runtime costs of storing the type of the variable are at least 1 byte. I would propose to do that:
add instructions to access the stack structures that the host provides;
allow the stack to have sub type per type, as the default remains as it is now, i/f 32/64, and to add "i/f 32/64 mark" as for example: i32_mark; That into this 1 byte (or word) bits.
all instructions remain as they are now and return i32 as requested to pop from the operand stack, no change here;
add new instructions to get/set the sub type of the value: mark; set subtype mark [i32] -> [i32_mark] for the operand stack top or set subtype 2 mark for a local variable in the call stack at index 2.
they can be predefined system sub types: mark / gc for example and even let some custom;
when you need some specific task, do iterate and do what ever you want with this sub types: get subtype 0
getting and setting local variables and moving the types around (calling functions) and so on, will keep this information without any extra work.
The text was updated successfully, but these errors were encountered:
as I'm reading around, some proposals required the i32 values to be distinguishable, as some of this values for example are pointers to objects that have to be garbage collected.
this values may be in the call stack frames as local variables, or into the operand stack.
it came to me that a tag can be added to each value.
the existing values will remain not tagged as it is now.
there can be i32_gc value, that is a i32 with a tag gc.
then this value can travel around the program (be copied freely) and at any point, all 'gc' values could be found and so garbage collected.
instructions to get and set the tags will be needed.
Hm...I think that the access to the call stack is important. If the stack is accessible in some general way many different features could become directly implementable on WebAssembly, instead of relaying to custom stacks. That would required instructions for iterating (instead of walking #1340) the frames, blocks and variables. Currently, the variable types are i/f 32/64 and I would imagine, that the runtime costs of storing the type of the variable are at least 1 byte. I would propose to do that:
mark
;set subtype mark
[i32] -> [i32_mark] for the operand stack top orset subtype 2 mark
for a local variable in the call stack at index 2.mark
/gc
for example and even let some custom;get subtype 0
The text was updated successfully, but these errors were encountered: