Add section on Memory types versus Local types

[titzer]

No description provided.

[lukewagner]

lgtm. I'm guessing the purpose of having separate Int32/UInt32 memory types is looking forward to Int64 local types?

[sunfishcode]

Heap storage is not typed; loads and stores have types, but the underlying storage is just a sequence of bytes, and there's nothing requiring that stores and loads to a given memory location use the same type. What would you think about changing the opening here to say "All variables in WebAssembly are typed", and removing "the heap,"?

[jfbastien]

Seemingly silly question while we're discussing this: do loads and store need a type? Technically they can all be byte-oriented, and cast before/after. In fact, loads to need this byte-load+type-cast for IR construction (whether it be separate on folded into one IR op) but stores don't need any information at all: the byte size is implicit from the operand.

When I say loads need a type, I assume we want IR operations that produce a value, and are later consumed by other operations, to have a type.

Do we want implicit sext/zext? If we're concentrating on simple IR then we don't really want that.

[titzer]

On Fri, May 22, 2015 at 5:00 PM, JF Bastien notifications@github.com
wrote:

In AstSemantics.md
WebAssembly/spec#79 (comment):

@@ -21,6 +21,58 @@ Callstack space is limited by unspecified and dynamically varying constraints.
If program callstack usage exceeds the available callstack space at any time,
a trap occurs.

+## Local and Memory types
+
+All storage locations in WebAssembly are typed, including global
+variables, the heap, local variables, or parameters. The set of types legal for

Seemingly silly question while we're discussing this: do loads and store
need a type? Technically they can all be byte-oriented, and cast
before/after. In fact, loads to need this byte-load+type-cast for IR
construction (whether it be separate on folded into one IR op) but stores
don't need any information at all: the byte size is implicit from the
operand.

Unfortunately not, because there are no local types for bytes. So loads and
stores need to be annotated with a memory type.

—
Reply to this email directly or view it on GitHub
https://github.com/WebAssembly/spec/pull/79/files#r30902237.

[sunfishcode]

Stores do need at least a byte size attribute, because they can store fewer bytes than the operand width.

I like sext+zext being built into load, since they're common, friendly, and map directly to machine instructions. And we need to pick some extension for narrow loads, and making one kind implicit and one kind explicit would mean an annoying asymmetry. And if zext is the default and sext is we do Shl+Sar, all the more so.

[titzer]

On Fri, May 22, 2015 at 5:57 PM, Dan Gohman notifications@github.com
wrote:

In AstSemantics.md
WebAssembly/spec#79 (comment):

@@ -21,6 +21,58 @@ Callstack space is limited by unspecified and dynamically varying constraints.
If program callstack usage exceeds the available callstack space at any time,
a trap occurs.

+## Local and Memory types
+
+All storage locations in WebAssembly are typed, including global
+variables, the heap, local variables, or parameters. The set of types legal for

Stores do need at least a byte size attribute, because they can store
fewer bytes than the operand width.

I like sext+zext being built into load, since they're common, friendly,
and map directly to machine instructions. And we need to pick some
extension for narrow loads, and making one kind implicit and one kind
explicit would mean an annoying asymmetry. And if zext is the default and
sext is we do Shl+Sar, all the more so.

Yes, some kind of implicit conversion from memory to local type is
necessary if the local type set is to be smaller. Otherwise, we have memory
types running around the IR, and that's just a pain :-(

Do you agree with the current text or were you proposing something
different for stores?

—
Reply to this email directly or view it on GitHub
https://github.com/WebAssembly/spec/pull/79/files#r30907425.

[sunfishcode]

I agree with the current text.

[jfbastien]

Unfortunately not, because there are no local types for bytes. So loads and
stores need to be annotated with a memory type.

Agreed that we currently don't have a simple sized byte type, but we can add one.

Stores do need at least a byte size attribute, because they can store fewer bytes than the operand width.

Similarly, we can make that a truncation.

I like sext+zext being built into load, since they're common, friendly, and map directly to machine instructions. And we need to pick some extension for narrow loads, and making one kind implicit and one kind explicit would mean an annoying asymmetry. And if zext is the default and sext is we do Shl+Sar, all the more so.

A tend to agree that it's nice and familiar. However, the current stated goal for this format is to keep it simple, and expect the macro layer to capture redundancy. It seems like separating conversion, extension and truncation out of load/store fits the goal?

Agreed it's different, but I think worth considering.

[sunfishcode]

After thinking about this a bit, there are some interesting considerations here. I filed #81 to follow up on this.

[sunfishcode]

lgtm