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

Refactor future features #125

Merged
merged 8 commits into from
Jun 9, 2015
Merged

Refactor future features #125

merged 8 commits into from
Jun 9, 2015

Conversation

jfbastien
Copy link
Member

This refactoring clarifies points made in #53, #99, #81, #49, and overall tries to make the text more self-consistent, less bullet-pointy.

This refactoring clarifies points made in #53, #99, #81, and overall tries to make the text more self-coherent, less bullet-pointy.
@jfbastien jfbastien added this to the Public Announcement milestone Jun 9, 2015
all loaded modules have their own [separate heaps](MVP.md#heap) and cannot share
[function pointers](MVP.md#function-pointers). Dynamic linking will allow
developers to share heaps and function pointers between WebAssembly modules, but
requires an implementation which properly handle ABI compatibility.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The end of this sentence is confusing to me. I assume "implementation" means "WebAssembly implementation", but it doesn't care about ABI, that's a user-/compiler-level concept. Or are you talking about the previous idea that wasm modules declare their ABI (as some opaque number) and the wasm engine provides early error checking by throwing if the numbers don't match?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I meant user-side implementation. I dropped this part of the paragraph: it's hard to explain concisely. At some point I think dynamic linking will move to its own document, and then we can explain how ABIs work, why they're a user-side thing, etc.


On a 32-bit system, heaps must still be smaller than 4GiB. All 64-bit pointer
arithmetic arithmetic (which will be much slower than 32-bit arithmetic) will be
therefore unnecessary.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This para is a bit awkward and could be misread (if you don't catch "pointer") as saying 32-bit doesn't need 64-bit arith. Also "arithmetic" is repeated twice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bad copy/pasta. Fixed.

* Call patching to chain JIT-compiled functions together;
* Temporary halt-insertion within functions, to trap if a function start
executing while a JIT-compiler's runtime is performing operations
dangerous to that function.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indentation

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The diff renders weird, but I think the indentation is what I want (it's a sub-list of the above bullet).

@jfbastien
Copy link
Member Author

Got an IRC "THEN FIRE ZE MISILES" from @lukewagner, which is French for "lgtm".

jfbastien added a commit that referenced this pull request Jun 9, 2015
@jfbastien jfbastien merged commit e1a343c into master Jun 9, 2015
@jfbastien jfbastien deleted the refactor-future-features branch June 9, 2015 21:24
jfbastien added a commit that referenced this pull request Jun 10, 2015
jfbastien added a commit that referenced this pull request Jun 10, 2015
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

Successfully merging this pull request may close these issues.

2 participants