Comments (12)
My opinion is that it's simpler to have one index space (shared by paramters/locals) and one set of ops for reading/writing since, other than how they are initialized, locals/params aren't different. There may also be a size win from having less ops competing for the 1-byte space (which normally I wouldn't attempt to argue, but local access is ~40% of bytes in polyfill-prototype-1 output, so the difference might "show through" even with layer 1/2 compression).
from spec.
I was thinking about going with separate index spaces, and start functions with (setlocal @0 param @0)
and so on. That's kind-of what I have in LLVM now (of course we can change it).
It seems easier than having params factor into the coloring of locals?
But yeah I think space usage is what matters most here, so data would win.
from spec.
@jfbastien Would we require param
nodes to appear only in the entry block? And would we prohibit any other code from appearing before them? If we don't, then wasm implementations will have to manage lifetimes for incoming parameters anyway. If we do, then these nodes are just boilerplate in every function that has parameters. I think a single index space makes sense.
from spec.
Would params occupy the lower-numbers automatically, in this One Single Space?
from spec.
It wouldn't be hard to define a mechanism to put the params at a different place in the index space, to reserve the low indices for more commonly used variables. However, I suspect that params that aren't used frequently will usually be easy to color with other things, so it doesn't seem likely to be enough of a win to justify the extra complexity.
from spec.
I don't think we need to worry about local index space order here:
We've already mostly agreed we won't have immediates-folded-into-ops at layer 0, which means that, at layer 0, get_local
will be 2 bytes (one for op, one for immediate) for locals [0 - 128], depending on encoding scheme. IIRC, 99% of functions in Unity/Epic asm.js have <64 locals. But 2 bytes per get/set local is terrible for the by-far hottest opcodes and to do better, we'd want to lean on the macro layer to fold get_local
and set_local
with the hottest immediates into a single byte (I described a sketch in #58). Once we do this, though, the actual index doesn't matter.
from spec.
On 17 August 2015 at 23:11, Luke Wagner [email protected] wrote:
A recent commit
b223caf
separated out parameters from locals, giving the two overlapping index
spaces. This is fairly different than what's in the design repo (only
locals
https://github.com/WebAssembly/design/blob/master/AstSemantics.md#local-variables)
but not a huge fundamental design difference (both work), so I thought we
should discuss it here.
I would argue that this is an encoding concern. In terms of semantics,
parameters and locals are somewhat different, and tend to generate
different code as well. That doesn't preclude that a binary encoding could
overlay them into one opcode, by shifting the index space appropriately. I
would consider that a separate concern, though.
That was the thinking behind the commit, anyway (besides making the s-expr
code more readable and less brittle, given that it doesn't support names
yet).
/Andreas
from spec.
It's quite convenient to have parameters and locals in the same index space
(and parameters at the beginning) in the decoder, because then the
environments carried for SSA renaming are just a simple array of the
current value of each local/param.
On Tue, Aug 18, 2015 at 9:05 AM, rossberg-chromium <[email protected]
wrote:
On 17 August 2015 at 23:11, Luke Wagner [email protected] wrote:
A recent commit
<
b223cafseparated out parameters from locals, giving the two overlapping index
spaces. This is fairly different than what's in the design repo (only
locals
<
https://github.com/WebAssembly/design/blob/master/AstSemantics.md#local-variables
)
but not a huge fundamental design difference (both work), so I thought we
should discuss it here.I would argue that this is an encoding concern. In terms of semantics,
parameters and locals are somewhat different, and tend to generate
different code as well. That doesn't preclude that a binary encoding could
overlay them into one opcode, by shifting the index space appropriately. I
would consider that a separate concern, though.That was the thinking behind the commit, anyway (besides making the s-expr
code more readable and less brittle, given that it doesn't support names
yet)./Andreas
—
Reply to this email directly or view it on GitHub
#8 (comment).
from spec.
@rossberg-chromium I realize we're in pretty subjective territory here but, from discussions above, at least from a low-level perspective (which is generally the perspective we're taking with wasm ops), the only semantic difference between params/locals is how they are initialized which was more aptly captured by eval_func
before GetParam
was added. Also, the readonly GetParam
that can be read anywhere in the body doesn't seem to capture anything essential.
from spec.
It's quite convenient to have parameters and locals in the same index space (and parameters at the beginning) in the decoder, because then the environments carried for SSA renaming are just a simple array of the current value of each local/param.
That's a pretty convincing argument, I'm sold.
from spec.
@rossberg-chromium Sound good to go back to only locals?
from spec.
Done. I still find it a bit unfortunate, e.g. it loses the 1-to-1 mapping between declaration forms and access forms.
from spec.
Related Issues (20)
- Missing `id?` in func specification. HOT 1
- [spec] `type` field of element instance seems unnecessary HOT 4
- Shared memory? HOT 2
- [Spec] Please do not use MathML for non-mathematical items HOT 6
- Questions on oopsla2019.pdf HOT 9
- stack size mismatch error messages are unclear
- build system/interpreter: `make test` isn't parallel anymore HOT 2
- `make test` does not work ~on linux~ with CDPATH HOT 6
- Documentation does not mention how to install ocamlbuild HOT 1
- build.py doesn't build tests in subdirectories HOT 5
- [Question] Why we have to push a dummy frame when invoking a function? HOT 5
- Activation frames: where's the return arity? HOT 1
- There is something wrong HOT 3
- [JS Generator] Add scope for each wasm instance HOT 1
- Improve SIMD test diversity HOT 1
- web
- Is it different to compile codes from `neon` or `x86` SIMD? HOT 1
- The definition of validation of br_table is inadequate HOT 3
- Question about validation of {element, data} segments HOT 1
- Wrong test cases in memory_init.wast HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spec.