sunfishcode
commented
2 years ago In the present "preview1" system, the answer is that at the time a module's (start) runs, the module's own exports are not yet available to the outside world. The current generation of WASI relies on a module exporting its linear memory so that it can pass pointers out to the outside world and have the outside world be able to dereference them in the memory. If we ran the main program from the (start) function, it would call out, but the exports wouldn't be ready yet, so the outside world wouldn't be able to dereference pointers. Even a simple hello world wouldn't be able to work, because it depends on passing a pointer to a buffer in linear memory to the outside world.
However, in the upcoming Preview2 system that the WASI Subgroup is now developing, this will change, in two phases. I'll describe the second phase first: with components, we'll no longer need to export linear memory to the outside world, and we will indeed use the (start) function as the mechanism for running the main function of a command.
The full component model is still in development, so the first phase is that WASI will use the Canonical ABI for components. This is a lowering of components into a core-wasm ABI that doesn't require any new language support in engines. In this lowering, there is a conceptual (start) function that gets called, though the lowering into core wasm uses a regular function export, because at the core-wasm level, we again run into the problem of the exports not being available until the core-wasm (start) function completes.
So long story short, there are technical reasons why we aren't using (start) today (it isn't an an oversight and it doesn't predate (start)), and we are already working towards being able to use (start) in the future :-).
wmstack
sbc100
I noticed that assembly script binaries that are compiled without WASI end up using the
(start)section as an entrypoint, while if the assemblyscript module is compiled with WASI support, that the entrypoint becomes a global export called "_start", which I feel is ad-hoc and unnecessary.Feature
Instead of using a global export "_start" as the ad-hoc starting point of a module, which I see that it is used as
Instead of that, I suggest that the webassembly specification-defined
(start)section is used instead as the entrypoint:Is that something proposed? I don't see any reason why we should have to diverging ways to do essentially the same thing. I also can't find any documentation on WASI ( I admit that I only had a cursory glance at the proposals). Until I can, I am afraid I am going to have to keep going here to ask questions . I am supposing that the
(start)section was introduced after WASI had standardized on the global export "_start" as the entrypoint?Benefit
Standardization. Simply put, the ad-hoc rules for the entrypoint for WASI are not ideal. Now the browser supports
(start)as the entrypoint, while WASI uses a global export.Implementation
Deprecate "_start" as export that indicates the entrypoint of the module, and instead utilize the section start as the indicator of the entrypoint of a module
(start $entry)Alternatives
The alternative is to continue using "_start" and diverge from webassembly for the web. In which case the ad-hoc rules would quickly pile up and we would have a nodejs like programming language, which is not very ideal.