Arrays are supported?

[AchalaSB]

Hi,

I have few questions. Are these data types supported? (code written in any of these lang C/C++/Rust )

1. Arrays
2. Strings
3. Bytes

When I say Arrays/Strings its basic type. Not as passing as pointer( serializing it into memory) If not supported, when can we expect this feature?

Thanks

CC : @binji @rossberg @dtig

[binji]

WebAssembly (at least in the first version) itself doesn't have support for any value types other than i32, i64, f32, and f64; that is, 32-bit and 64-bit integer and floating point types. To represent any other complex values you have to use linear memory. C/C++ and Rust all lower arrays and strings to memory accesses. It's not serialization, since this is the actual in-memory representation of the object.

[AchalaSB]

@binji Thanks for reverting.

Does that mean Webassembly will support these complex values directly in future release? If yes When?

[binji]

Yes, though it depends on how you want to use them. The gc proposal allows you to create array objects. The interface types proposal allows you to express an array in linear memory (the way C++/Rust etc. already do it) as an array type to external modules. But neither of these proposals is available yet, and it's not clear when they will be. Currently, your only option is to use linear memory directly.

[gullahoo]

It is not "serialization", so to speak, then what may I ask is the mechanism it uses- are these read/write barriers that it is in effect using?
Perhaps I need to read more of the specs themselves, but I am also wondering about its potential future implementation of bitvector.h.. Thanks for reading!

[binji]

@gullahoo The mechanism used is loading/storing from memory addresses. Wasm works more like an assembly language in this way; there are (currently) no other types than numeric types. You definitely can implement something like a bitvector, but Wasm provides no mechanism for you to create this abstraction yourself. Generally you'll use a source programming language for this; C++, Rust, Zig, etc.

[gullahoo]

Is there a way to bypass loading and-or storing, i.e. with a specific type of memory register in a network or computing grid?? In other words, is there a way to implement some alternative "on the fly" pragma directive to redirect your web assembly to repeatedly read bits rather than load with mov?? Perhaps inline some 'w'asm statements inside some pragma directive block?

In this way, the assembly avoids the need altogether for the bitvector or array class?? Thanks again for reading!

[gullahoo]

Perhaps a simpler and more relevant question is if there are plans with the new array implementation to support any generic arch representation, such as hwtypes.h?? Are implementation specific optimization settings being worked out with Clang group ... Any other group working in cohort, say, grid computing giants such as IBM??

As you might tell I am trying to contribute, if that sort of thing isn't frowned on

[conrad-watt]

Assuming you're referring to the GC proposal's array, its representation is opaque to the WebAssembly abstract machine; it's much more like a Java array than a C array. It's not intended for use in compiling C/C++/Rust. For the GC proposal especially, we assume WebAssembly is embedded inside a "host" which manages the representation/allocation/lifetime of such objects.

Most of the things you're describing don't seem like they'd be the responsibility of WebAssembly to make decisions on at the ISA/language/spec level, but would instead be decisions/optimisations/representation choices made either by the toolchain when compiling to WebAssembly, or by the host/VM when implementing WebAssembly.

[gullahoo]

Okay! I forgot about the Java static array approach-. But only perhaps because Java vm's make me complacent about the whole memory MGMT(gc, whatever) process

That approach does make more sense, in light of keeping memory leaks out. In the meantime I see your team has some work going on with the clang llvm group.
I know d along with automated GCC is insanely maddening these days

[rossberg]

I believe this has been answered.