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

Proposal: Type Tags #1341

Closed
verbessern opened this issue May 2, 2020 · 2 comments
Closed

Proposal: Type Tags #1341

verbessern opened this issue May 2, 2020 · 2 comments

Comments

@verbessern
Copy link

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.
@binji
Copy link
Member

binji commented May 6, 2020

I'm having trouble understanding what you're proposing here, and which problem it solves. Can you elaborate a bit, perhaps with an example?

@verbessern
Copy link
Author

verbessern commented May 12, 2020

I will try to:

  • 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.

Is that better?

@verbessern verbessern changed the title Proposal: Sub Types Proposal: Type Tags May 12, 2020
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