Data section offsets
See original GitHub issueProblem
There are currently two methods of encoding a Data Section entry into the binary. These are
const hello: i32 = 'Hello World!';
- static stringsconst array: i32[] = [1, 2, 3, 4];
- static array/raw data regions
In both cases the data is encoded into the data section such that it’ll take up the first available offset in memory.
The data sections in the WASM spec allow for an explicit offset. An example of this can be seen in the reference spec tests for data section here.
Goal
Define and implement a syntax for allowing an explicit offset to be defined when defining data sections in Walt.
Possible syntax:
A pseudo function call
const memory: Memory = { initial: 1 };
const string: i32 = memory.data(1024 /* offset */, 'Hello World!' /* value */);
This would require for altering the grammar to allow for top-level function calls, as well as some guards on calling non memory.data()
function calls.
A static object
const string: i32 = { offset: 1024, value: 'Hello World!' };
This would work great for strings but not so well for static arrays. Also, having an object property(offset
) not be part of the object is very odd.
???
Maybe there is an additional way to define this which would make sense, but it does seem like having the memory
involved in some way makes the most sense. Especially since in the future it will be possible to have N > 1 memories in a single binary.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:11 (5 by maintainers)
Top GitHub Comments
And here’s another suggestion…
Yup, the compiler already supports extensions. All of the current features are written as internal (enabled by default) language extensions and grammar. There is a reference implementation of closures as a plugin to demonstrate how a complex extension could be made and injected into a compiler.
I’ll probably make a package (similar to babel presents) for all
experimental-*
features for these type of changes.