--- title: Описание текстового формата WebAssembly slug: WebAssembly/Understanding_the_text_format translation_of: WebAssembly/Understanding_the_text_format ---
Чтобы люди могли читать и редактировать код WebAssembly, существует текстовое представление двоичного формата wasm. Это промежуточная форма, предназначенная для отображения в текстовых редакторах, средствах разработки браузеров и т. д. В этой статье объясняется, как работает этот текстовый формат с точки зрения синтаксиса, как он связан с байт-кодом, который он представляет и оболочками объектов wasm в JavaScript.
Примечание: Ознакомление с данной статьей может оказаться излишним, если вы веб-разработчик, который просто хочет загрузить модуль wasm на страницу и использовать его в своем коде (см. Использование WebAssembly JavaScript API). Эта статья будет наиболее полезной, если вы хотите написать несколько модулей wasm для оптимизации производительности вашей библиотеки JavaScript или создать свой собственный компилятор WebAssembly.
Как в двоичном, так и в текстовом форматах основным блоком кода в WebAssembly является модуль. В текстовом формате модуль представлен как одно большое S-выражение. S-выражения - это очень старый и очень простой текстовый формат для представления деревьев. И поэтому мы можем думать о модуле как о дереве узлов, которые описывают структуру модуля и его код. В отличие от абстрактного синтаксического дерева в языке программирования, дерево WebAssembly довольно плоское и состоит в основном из списков инструкций.
Во-первых, давайте посмотрим, как выглядит S-выражение. Каждый узел дерева входит в пару круглых скобок - ( ... )
. Первая метка в скобках сообщает вам, какой это тип узла, за ним следует разделенный пробелами список атрибутов или дочерних узлов. Давайте рассмотрим, что означает следующее S-выражение WebAssembly:
(module (memory 1) (func))
Это выражение представляет дерево с корневым узлом «module» и двумя дочерними узлами - узлом «memory» с атрибутом «1» и узлом «func». Мы вскоре увидим, что на самом деле означают эти узлы.
Давайте начнем с самого простого модуля wasm.
(module)
Этот модуль полностью пуст, но является допустимым.
Если мы сейчас преобразуем наш модуль в двоичный формат (см. Перевод текстового формата WebAssembly в wasm), мы увидим только 8-байтовый заголовок модуля, описанный в двоичном формате:
0000000: 0061 736d ; WASM_BINARY_MAGIC 0000004: 0100 0000 ; WASM_BINARY_VERSION
Хорошо, это не очень интересно, давайте добавим немного исполняемого кода в этот модуль.
Весь код в модуле сгруппирован в функции, которые имеют следующую структуру псевдокода:
( func <signature> <locals> <body> )
Несмотря на то, что это S-выражение, оно очень напоминает функцию в других языках.
Сигнатура - это последовательность объявлений типов параметров, за которыми следует список объявлений возвращаемых типов. Здесь стоит отметить, что:
Отсутствие возвращаемого типа (result)
означает, что функция ничего не возвращает.
В текущей версии WebAssembly может быть не более 1 возвращаемого типа, но позже это значение будет изменено на любое число.
Каждый параметр имеет явно объявленный тип; у wasm в настоящее время есть четыре доступных типа:
i32
: 32-разрядное целое числоi64
: 64-разрядное целое числоf32
: 32-разрядное число с плавающей точкойf64
: 64-разрядное число с плавающей точкойОдин параметр можно записать как (param i32)
, а тип возвращаемого значения как (result i32)
. Двоичная функция, которая принимает два 32-разрядных целых числа и возвращает 64-разрядное число с плавающей запятой, будет записана следующим образом:
(func (param i32) (param i32) (result f64) ... )
После сигнатуры перечисляются локальные переменные с указанием типа, например (local i32)
. Параметры в сигнатуре приравниваются к локальным переменным, которые инициализируются значением соответствующего аргумента, переданного вызывающей стороной.
И параметры и локальные переменные могут быть прочитаны и записаны в теле функции с помощью инструкций get_local
и set_local
.
Инструкции get_local
и set_local
ссылаются по индексу на параметр, который должен быть получен или установлен: сначала считаются параметры, а затем локальные переменные в порядке их объявления. Объясним это на примере следующей функции:
(func (param i32) (param f32) (local f64) get_local 0 get_local 1 get_local 2)
Инструкция get_local 0
получит параметр i32, get_local 1
получит параметр f32, а get_local 2 получит локальную переменную local f64.
Использование числовых индексов для ссылки на элементы может сбивать с толку и раздражать, поэтому текстовый формат позволяет присваивать имена параметрам, локальным переменным и большинству других элементов. Для этого нужно просто добавить имя с префиксом символа доллара ($
) непосредственно перед объявлением типа.
Таким образом, можно переписать нашу сигнатуру так:
(func (param $p1 i32) (param $p2 f32) (local $loc f64) …)
После чего можно было бы написать инструкцию получения get_local $p1
вместо get_local 0
и т.д. (Обратите внимание, что, когда этот текст преобразуется в двоичный файл, двоичный файл будет содержать только индексы.)
Прежде чем мы сможем написать тело функции, мы должны поговорить еще о стековых машинах. Хотя браузер компилирует wasm-код во что-то более эффективное, выполнение его определяется в терминах стековой машины, где основная идея заключается в том, что каждый тип инструкции получает или помещает определенное количество значений i32
/ i64
/ f32
/ f64
в стек или из стека.
Например, инструкция get_local
предназначена для помещения значения локальной переменной, которое она считала, в стек. А инструкция i32.add
получает два значения i32
(неявно получает два предыдущих значения, помещенных в стек), вычисляет их сумму и помещает назад в стек результат вычисления i32
.
Когда вызывается функция, для нее выделяется пустой стек, который постепенно заполняется и очищается при выполнении инструкций в теле функции. Так, например, после выполнения следующей функции:
(func (param $p i32) get_local $p get_local $p i32.add)
Стек будет содержать ровно одно значение i32
- результат выполнения выражения ($p + $p), которое обработалось инструкцией i32.add
. Возвращаемое значение функции - это последнее значение, оставленное в стеке.
Правила валидации WebAssembly гарантируют, выполнение следующего: если вы объявляете тип возвращаемого значения функции как (result f32)
, то стек должен содержать ровно одно значение типа f32
в конце. Если тип результата отсутствует, стек должен быть пустым.
Как упоминалось ранее, тело функции - это просто список инструкций, которые выполняются при вызове функции. Объединяя это с тем, что мы уже изучили, мы можем наконец определить модуль, содержащий простую функцию:
(module (func (param $lhs i32) (param $rhs i32) (result i32) get_local $lhs get_local $rhs i32.add))
Эта функция получает два параметра, складывает их вместе и возвращает результат.
Есть еще много инструкций, которые можно поместить в тело функции. Сейчас мы начнем с простых, а далее вы увидите гораздо больше примеров по мере продвижения. Полный список доступных инструкций смотрите в справочнике по семантике webassembly.org.
Определение нашей функции само по себе почти ничего не делает - теперь нам нужно её вызвать. Как мы это сделаем? Как и в модуле ES2015, функции wasm должны быть явно экспортированы инструкцией export
внутри модуля.
Как и локальные переменные, функции идентифицируются индексом по умолчанию, но для удобства им можно присвоить имя. Давайте это сделаем: сначала добавим имя, которому предшествует знак доллара, сразу после ключевого слова func
:
(func $add … )
Теперь нам нужно добавить объявление экспорта:
(export "add" (func $add))
Здесь add
- это имя, по которому функция будет идентифицироваться в коде JavaScript, а $add
определяет, какая функция внутри модуля WebAssembly будет экспортироваться.
Итак, наш последний вариант модуля (на данный момент) выглядит так:
(module (func $add (param $lhs i32) (param $rhs i32) (result i32) get_local $lhs get_local $rhs i32.add) (export "add" (func $add)) )
Если вы хотите собственноручно скомпилировать пример, сохраните ранее написанный модуль в файле с именем add.wat
, а затем преобразуйте его в двоичный файл с именем add.wasm
, используя wabt (подробности смотрите в разделе Перевод текстового формата WebAssembly в wasm).
Затем мы загрузим наш двоичный файл, скомпилируем, создадим его экземпляр и выполним нашу функцию add
в коде JavaScript (теперь нам доступна функция add()
в свойстве exports
экземпляра модуля):
WebAssembly.instantiateStreaming(fetch('add.wasm')) .then(obj => { console.log(obj.instance.exports.add(1, 2)); // "3" });
Примечание: Вы можете найти этот пример на GitHub в файле add.html (смотрите также это вживую). Также смотрите {{jsxref("WebAssembly.instantiateStreaming()")}} для получения более подробной информации о функции создания экземпляра модуля.
Теперь, когда мы рассмотрели простейшие примеры, давайте перейдем к рассмотрению некоторых более сложных возможностей.
Для вызова функци по индексу или имени используется инструкция call
. Например, следующий модуль содержит две функции - первая просто возвращает значение 42
, вторая возвращает сумму результата вызова первой функции и единицы:
(module (func $getAnswer (result i32) i32.const 42) (func (export "getAnswerPlus1") (result i32) call $getAnswer i32.const 1 i32.add))
Примечание: Инструкция i32.const
создает 32-разрядное целое число и помещает его в стек. Вы можете поменять i32
на любой другой доступный тип данных и изменить значение на любое другое (здесь мы установили значение 42
).
В этом примере обратите внимание на секцию объявления экспорта (export “getAnswerPlus1”)
, которая находится сразу после объявления второй функции func
. Это сокращенный способ объявления, совмещенный с именем функции, которую мы хотим экспортировать.
Функционально это эквивалентно включению отдельного объявления экспорта функции без функции, в любом месте модуля, например:
(export "getAnswerPlus1" (func $functionName))
Код JavaScript для вызова экспортируемой функции из нашего модуля выглядит так:
WebAssembly.instantiateStreaming(fetch('call.wasm')) .then(obj => { console.log(obj.instance.exports.getAnswerPlus1()); // "43" });
Примечание: Вы можете найти этот пример на GitHub как call.html (смотрите также вживую). Еще посмотрите wasm-utils.js для метода fetchAndInstantiate()
.
Мы уже видели JavaScript, вызывающий экспортируемые функции модуля WebAssembly, но как насчет WebAssembly модуля, вызывающего функции JavaScript? WebAssembly не имеет каких либо знаний о внешнем коде JavaScript, но у него есть способ импорта, который может принимать функции из JavaScript или wasm. Давайте посмотрим на пример:
(module (import "console" "log" (func $log (param i32))) (func (export "logIt") i32.const 13 call $log))
В инструкции импорта в модуль WebAssembly определено двухуровневое пространство имен, в котором мы указали импортировать функцию log
из модуля console
. Вы также можете видеть, что экспортируемая функция logIt
вызывает импортированную функцию, используя инструкцию call
, о которой мы говорили ранее.
Импортируемые функции аналогичны обычным функциям: они имеют сигнатуру, которую WebAssembly проверяет статически, им присваивается индекс (в место которого можно присвоить имя) и их можно вызвать обычным способом.
Функции JavaScript не имеют понятия сигнатуры, поэтому любую функцию JavaScript можно передать независимо от объявленной сигнатуры импорта. Если модуль объявляет импорт, вызывающая сторона (например метод {{jsxref("WebAssembly.instantiate()")}}) должна передать объект импорта, который должен иметь соответствующее свойство.
Для иллюстрации вышесказанного нам нужен объект (назовем его importObject
), в котором конечное свойство importObject.console.log
должно содержать функцию JavaScript.
Код будет выглядеть следующим образом:
var importObject = { console: { log: function(arg) { console.log(arg); } } }; WebAssembly.instantiateStreaming(fetch('logger.wasm'), importObject) .then(obj => { obj.instance.exports.logIt(); });
Примечание: Этот пример можно найти на GitHub в файле logger.html (смотрите также вживую).
WebAssembly имеет возможность создавать экземпляры глобальных переменных. Они доступны как в коде JavaScript, так и через импорт / экспорт для одиного и более экземпляров {{jsxref("WebAssembly.Module")}}. Это очень полезная возможность в плане динамического связывания нескольких модулей.
В текстовом формате WebAssembly это выглядит примерно так (смотрите файл global.html в нашем репозитории на GitHub; смотрите также вживую):
(module (global $g (import "js" "global") (mut i32)) (func (export "getGlobal") (result i32) (get_global $g)) (func (export "incGlobal") (set_global $g (i32.add (get_global $g) (i32.const 1)))) )
Это похоже на то, что мы делали раньше, за исключением того, что мы указываем глобальную переменную с помощью ключевого слова global
. Также мы указываем ключевое слово mut
вместе с типом данных значения (если хотим, чтобы глобальная переменная была изменяемой).
Чтобы создать эквивалентный код с помощью JavaScript, вы должны использовать конструктор {{jsxref("WebAssembly.Global()")}}:
const global = new WebAssembly.Global({value:'i32', mutable:true}, 0);
Приведенный выше пример - довольно ужасная функция ведения журнала: она печатает только одно целое число! Что если мы хотим записать текстовую строку? Для работы со строками и другими более сложными типами данных WebAssembly предоставляет линейную память. Согласно технологии WebAssembly, линейная память - это просто большой массив байтов, который со временем может увеличиваться. WebAssembly код содержит ряд инструкций, наподобие i32.load
и i32.store
для чтения и записи значений из линейной памяти.
Со стороны JavaScript, линейная память как будто находится внутри одного большого (расширяющегося) объекта {{domxref("ArrayBuffer")}}.
Таким образом, строка - это просто последовательность байтов где-то внутри этой линейной памяти. Давайте предположим, что мы записали нужную строку байтов в память; как мы передадим эту строку в JavaScript?
Ключевым моментом является то, что JavaScript может создавать экземпляры(объекты) линейной памяти WebAssembly через конструктор {{jsxref("WebAssembly.Memory()")}} и получать доступ к существующему экземпляру памяти (в настоящее время вы можете иметь только один экземпляр памяти на экземпляр модуля), используя соответствующие методы экземпляра модуля. Экземпляр памяти имеет свойство buffer
, которое возвращает объект ArrayBuffer
, предоставляя всю линейную память модуля.
Объекты памяти могут расширятся с помощью метода Memory.grow()
из JavaScript. Когда происходит расширение, текущий объект ArrayBuffer
не может изменить размер и он отсоединяется. Вместо него создается новый объект ArrayBuffer
, указывающий на новую, увеличенную память. Пользуясь этими возможностями можно передать строку в JavaScript, её начальный индекс и её длину в линейной памяти.
Хотя есть много разных способов кодировать длину строки в самой строке (например, как в строках в C); для простоты здесь мы просто передаем смещение и длину в качестве параметров:
(import "console" "log" (func $log (param i32) (param i32)))
На стороне JavaScript, мы можем использовать TextDecoder API, чтобы легко декодировать наши байты в строку JavaScript. (Мы указываем кодировку utf8, хотя поддерживаются и другие кодировки.)
function consoleLogString(offset, length) { var bytes = new Uint8Array(memory.buffer, offset, length); var string = new TextDecoder('utf8').decode(bytes); console.log(string); }
Последний недостающий фрагмент головоломки - это место, где функция consoleLogString
получает доступ к памяти (memory
) WebAssembly. WebAssembly дает нам здесь много гибкости: либо мы можем создать объект Memory
в коде JavaScript и импортировать его в модуль WebAssembly, или мы можем создать его в модуле WebAssembly и затем экспортировать в JavaScript.
Для простоты, давайте создадим объект памяти в JavaScript и импортируем его в WebAssembly модуль. Напишем следующее объявление импорта (import
):
(import "js" "mem" (memory 1))
Число 1
указывает, что импортируемая память должна иметь по крайней мере 1 страницу памяти (WebAssembly определяет страницу как фиксированный блок памяти в 64КБ.)
Давайте взглянем на наш последний вариант модуля, который выводит слово “Hi”. В обычной C программе, мы бы вызывали функцию для выделения памяти для строки. Но так как мы пишем собственную сборку и у нас есть собственная импортируемая память, то мы просто пишем содержание строки в линейную память, используя секцию data
. Data-секция во время создания записывает строку байт, начиная с указанного отступа. И она действует также как и .data
секция в “родных” форматах для исполнения.
Наш последний вариант модуля выглядит так:
(module (import "console" "log" (func $log (param i32 i32))) (import "js" "mem" (memory 1)) (data (i32.const 0) "Hi") (func (export "writeHi") i32.const 0 ;; pass offset 0 to log i32.const 2 ;; pass length 2 to log call $log))
Примечание: Обратите внимание, что двойная точка с запятой (;;
) позволяет оставлять комментарии в файлах WebAssembly.
Теперь из JavaScript мы можем создать и передать объект памяти размером в 1 страницу. Результатом работы этого кода будет вывод “Hi” в консоль:
var memory = new WebAssembly.Memory({initial:1}); var importObject = { console: { log: consoleLogString }, js: { mem: memory } }; WebAssembly.instantiateStreaming(fetch('logger2.wasm'), importObject) .then(obj => { obj.instance.exports.writeHi(); });
Примечание: Вы можете найти полный исходный код на GitHub в файле logger2.html (также смотрите это вживую).
Чтобы завершить обзор текстового формата WebAssembly, давайте рассмотрим самую сложную и запутанную часть WebAssembly - таблицы. Таблицы - это массивы ссылок изменяемого размера, доступ к которым можно получить по индексу из кода WebAssembly.
Чтобы понять, зачем нужны таблицы, нам нужно сначала обратить внимание, что инструкция call
, которую мы видели ранее (см. {{anch("Вызов функций из других функций в том же модуле")}}), принимает статический индекс функции и может вызывать только определенную функцию. Но что, если вызываемый элемент будет значением, установленным во время выполнения?
Для того чтобы сделать это в WebAssembly нужен был отдельный тип инструкции вызова. Поэтому мы создали инструкцию call_indirect
, которая принимает операнд динамической функции. Проблема в том, что типы данных, которые мы должны использовать в операндах в WebAssembly, в настоящее время такие: i32
/ i64
/ f32
/ f64
.
Для WebAssembly можно было бы создать тип инструкции вызова anyfunc
(«любой», потому что эта инструкция смогла вызвать функции любой сигнатуры), но, к сожалению, операнд этого типа не может быть сохранен в линейной памяти по соображениям безопасности. Линейная память представляет содержимое хранимых значений в виде незащищенных байтов, и это позволяет содержимому wasm произвольно читать и изменять незащищенные адреса функций, что недопустимо для веб.
Решением стало следующее. Хранить ссылки на функции в таблице и передавать вместо них индексы таблицы, которые являются просто значениями i32
. Поэтому операндом инструкции call_indirect
может выступить простое значение индекса i32
.
Так как же разместить функции wasm в нашей таблице? Подобно тому, как секции data
могут использоваться для инициализации областей линейной памяти байтами, секции elem
могут использоваться для инициализации областей таблиц с функциями:
(module (table 2 anyfunc) (elem (i32.const 0) $f1 $f2) (func $f1 (result i32) i32.const 42) (func $f2 (result i32) i32.const 13) ... )
В (table 2 anyfunc)
, 2 - это начальный размер таблицы (это означает, что она будет хранить две ссылки), а объявление anyfunc
означает, что типом элемента этих ссылок является «функция с любой сигнатурой». В текущей версии WebAssembly, это единственный допустимый тип атрибута, но в будущем будет добавлено больше.
Секции функций (func)
- это обычные объявления функций модуля wasm. Это те функции, на которые мы будем ссылаться в нашей таблице (каждая из них просто возвращает постоянное значение). Обратите внимание, что порядок объявления секций не имеет значения - вы можете объявить свои функции где угодно и по-прежнему ссылаться на них в секции elem
.
Секция elem
- это список функций, на которые ссылается таблица, в том порядке, в котором они указаны. Здесь можно перечислить любое количество функций, включая их дубликаты.
Значение (i32.const 0)
внутри секции elem
является смещением - его необходимо объявить в начале секции и указать, по какому индексу в таблице ссылок начинают заполняться ссылки на функции. Здесь мы указали 0, а размер таблицы указали как 2 (см. выше), поэтому мы можем заполнить две ссылки на индексы 0 и 1. Если бы мы захотели записать наши ссылки со смещением в 1, то нам нужно было бы написать (i32.const 1)
, а размер таблицы должен был быть равен 3.
Примечание: Неинициализированным элементам присваивается значение вызова по умолчанию.
В JavaScript эквивалентный код для создания такого экземпляра таблицы ссылок будет выглядеть примерно так:
function() { // table section var tbl = new WebAssembly.Table({initial:2, element:"anyfunc"}); // function sections: var f1 = function() { … } var f2 = function() { … } // elem section tbl.set(0, f1); tbl.set(1, f2); };
Мы определили таблицу, которую нам нужно как-то использовать. Для этого добавим следующую секцию кода:
(type $return_i32 (func (result i32))) ;; if this was f32, type checking would fail (func (export "callByIndex") (param $i i32) (result i32) get_local $i call_indirect (type $return_i32))
(type $return_i32 (func (result i32)))
определяет тип с заданным именем $return_i32
. Этот тип используется при выполнении проверки сигнатуры функции в таблице функций. Здесь мы указываем, что ссылки должны быть функциями, возвращаемое значение которых должно быть с типом i32
.callByIndex
. Для единственного параметра функции задан тип i32
, которому присвоено имя $i
.$i
экспортируемой функции.call_indirect
для вызова функции из таблицы - она неявно получает значение $i
из стека. Конечным результатом будет вызов функции из таблицы с индексом, указанным в $i
.Вы также можете объявить параметр call_indirect
явно во время вызова инструкции, а не до него (неявным получением из стека), например так:
(call_indirect (type $return_i32) (get_local $i))
На языке высокого уровня, таком как JavaScript эти же действия вы можете представить в виде манипуляций с массивом (или, скорее, с объектом), содержащим функции. Псевдокод будет выглядеть примерно так: tbl[i]()
.
Итак, вернемся к проверке типов. Так как в коде WebAssembly проверяются типы, а атрибут anyfunc
означает “сигнатура любой функции", мы должны предоставить предполагаемую сигнатуру в месте вызова, поэтому мы включаем тип с именем $return_i32
, чтобы сообщить программе, что ожидается функция, возвращающая значение с типом i32
. Если вызываемая функция не имеет соответствующей сигнатуры (скажем, вместо нее возвращается f32
), выбросится исключение {{jsxref("WebAssembly.RuntimeError")}}.
Так как инструкция call_indirect
связывается с таблицей, с которой мы вызываем функцию? Ответ заключается в том, что на данный момент для каждого экземпляра модуля разрешена только одна таблица. Поэтому инструкция call_indirect
выполняет неявный вызов именно из этой таблицы. В будущем, когда будет разрешено использование нескольких таблиц, нам нужно будет указать идентификатор таблицы, например так:
call_indirect $my_spicy_table (type $i32_to_void)
Весь модуль в целом выглядит следующим образом и может быть найден в нашем примере файла wasm-table.wat:
(module (table 2 anyfunc) (func $f1 (result i32) i32.const 42) (func $f2 (result i32) i32.const 13) (elem (i32.const 0) $f1 $f2) (type $return_i32 (func (result i32))) (func (export "callByIndex") (param $i i32) (result i32) get_local $i call_indirect (type $return_i32)) )
Загрузка модуля и использование экспортируемой функции в коде JavaScript будет выглядеть так:
WebAssembly.instantiateStreaming(fetch('wasm-table.wasm')) .then(obj => { console.log(obj.instance.exports.callByIndex(0)); // returns 42 console.log(obj.instance.exports.callByIndex(1)); // returns 13 console.log(obj.instance.exports.callByIndex(2)); // returns an error, because there is no index position 2 in the table });
Примечание: Этот пример можно найти на GitHub в файле wasm-table.html (смотрите это также вживую)
Примечание: Как и в случае с памятью, таблицы также можно создавать из кода JavaScript (см. WebAssembly.Table()
).
Поскольку JavaScript имеет полный доступ к ссылкам на функции, объект таблицы может быть изменен из кода JavaScript с помощью методов grow()
, get()
и set()
. Когда WebAssembly получит ссылочные типы, код WebAssembly сможет изменять таблицы самостоятельно с помощью инструкций get_elem
/ set_elem
.
Поскольку таблицы являются изменяемыми, их можно использовать для реализации сложных схем динамического связывания во время загрузки и во время выполнения. Когда программа динамически связана, несколько экземпляров могут совместно использовать линейную память и таблицу ссылок. Это похоже на поведение в обычном приложении где несколько скомпилированных .dll
совместно используют адресное пространство одного процесса.
Чтобы увидеть это в действии, мы создадим один объект импорта, содержащий объект памяти и объект таблицы. Далее мы передадим этот объект импорта при создании нескольких модулей с помощью метода instantiate()
.
Наши примеры файлов .wat
выглядят так:
shared0.wat
:
(module (import "js" "memory" (memory 1)) (import "js" "table" (table 1 anyfunc)) (elem (i32.const 0) $shared0func) (func $shared0func (result i32) i32.const 0 i32.load) )
shared1.wat
:
(module (import "js" "memory" (memory 1)) (import "js" "table" (table 1 anyfunc)) (type $void_to_i32 (func (result i32))) (func (export "doIt") (result i32) i32.const 0 i32.const 42 i32.store ;; store 42 at address 0 i32.const 0 call_indirect (type $void_to_i32)) )
Они работают следующим образом:
shared0func
определена в shared0.wat
и сохраняется в нашей импортированной таблице.0
, затем инструкция i32.load
получает значение из импортированной памяти по предоставленному константой индексу. Предоставленный индекс равен 0
. Как и другие подобные инструкции, i32.load
неявно получает предоставленное значение из стека. Итак, shared0func
загружает и возвращает значение, хранящееся в индексе памяти 0
.shared1.wat
мы экспортируем функцию с именем doIt
- эта функция размещает в стеке две константы, содержащие значения 0
и 42
. Затем она вызывает инструкцию i32.store
для сохранения предоставленного значения по предоставленному индексу в импортированной памяти. Опять же, инструкция неявно получает эти значения из стека. Поэтому в результате doIt
сохраняет значение 42
в индексе памяти 0
.0
, затем вызывается функция с этим индексом (0
) из таблицы. Это будет функция shared0func
модуля shared0.wat
, которая ранее была размещена там с помощью секции elem
.42
, которые мы сохранили в памяти, с помощью ранее указанной инструкции i32.store
в модуле shared1.wat
.Примечание: Вышеприведенные выражения неявно извлекают значения из стека, но вместо этого вы можете объявить их явно в вызовах инструкций, например:
(i32.store (i32.const 0) (i32.const 42)) (call_indirect (type $void_to_i32) (i32.const 0))
После преобразования текста в модули мы используем файлы shared0.wasm
и shared1.wasm
в JavaScript с помощью следующего кода:
var importObj = { js: { memory : new WebAssembly.Memory({ initial: 1 }), table : new WebAssembly.Table({ initial: 1, element: "anyfunc" }) } }; Promise.all([ WebAssembly.instantiateStreaming(fetch('shared0.wasm'), importObj), WebAssembly.instantiateStreaming(fetch('shared1.wasm'), importObj) ]).then(function(results) { console.log(results[1].instance.exports.doIt()); // prints 42 });
Каждый из компилируемых модулей может импортировать общие объекты памяти и таблицы. Таким образом, они могут совместно использовать одну и ту же линейную память и таблицу ссылок.
Примечание: Этот пример можно найти на GitHub в файле shared-address-space.html (смотрите это также вживую).
На этом мы завершаем обзор основных компонентов текстового формата WebAssembly и того, как они отображены в WebAssembly JS API.