Design: Уточнение извлечения стека для условных переходов

Созданный на 27 мар. 2017 · 5Комментарии · Источник: WebAssembly/design

Я занимаюсь написанием компилятора WebAssembly. Я смотрю тест https://github.com/WebAssembly/spec/blob/634f0d9009404f498ef8d8bd510bd6f0941219cc/test/core/br_if.wast#L272, который выглядит немного расширенным:

(module
    (func
      $type-arg-void-vs-num-nested
      (result i32)

      block i32
        (i32.const 0)
        block
          (i32.const 1)
          (br_if 1)
        end
      end
    )
)

Я получаю следующую ошибку:

Error: check failed:
test.wast:10:12
type stack size too small at br_if value. got 0, expected at least 1
          (br_if 1)
           ^^^^^^^

Я бы подумал, что размер стека, когда он достигает br_if равен 2, что означает, что он выдает 1 для условного выражения, а затем имеет один остаток для удовлетворения внешнего блока. Я предположил, что (i32.const 0) попадет во вложенный блок. Какая часть мне не хватает? Заранее спасибо.

Источник

cretz

Самый полезный комментарий

Означает ли это, что каждый блок получает свой стек?
Я бы не сказал, что у них есть свои стеки, просто есть лимит
к чему можно выскочить. Собственно так это и реализовано в wabt, там
представляет собой стек значений и стек «меток». На каждой этикетке хранится «лимит», который
размер стека значений при нажатии метки. Тогда всякий раз, когда вы
pop, вы проверяете лимит верхнего лейбла.

Оба являются действительными взглядами. Семантически представление "блочно-локальный стек" имеет
преимущество в том, что он не требует дополнительных инвариантов. С «одинарным стеком»
необходимы дополнительные предположения о правильности, такие как все ограничения
происходящие в стеке меток должны находиться в границах текущего стека операндов
по высоте, они должны располагаться (не обязательно строго) в порядке возрастания, и
стопка этикеток никогда не должна быть пустой.

rossberg 28 мар. 2017

👍2

Все 5 Комментарий

Да, здесь можно улучшить отчеты об ошибках wabt. Несмотря на то, что в стеке есть два i32 s, операторы никогда не выскакивают за начало блока, поэтому фактически есть только один.

binji 28 мар. 2017

Означает ли это, что каждый блок получает свой стек? Меня смутило следующее утверждение в документации по семантике:

Выполнение инструкции блока или цикла не влияет на стек значений.

Может быть, это должно измениться на:

Выполнение инструкции блока или цикла не влияет на стек значений, но все значения стека вне исполняемого блока недоступны.

Или я недопонимаю?

cretz 28 мар. 2017

Означает ли это, что каждый блок получает свой стек?

Я бы не сказал, что у них есть свои собственные стеки, просто есть предел тому, что можно вытащить. На самом деле так это реализовано в wabt, есть стек значений и стек «меток». Каждая метка хранит «предел», который представляет собой размер стека значений при нажатии метки. Затем всякий раз, когда вы попадаете, вы проверяете верхний предел метки.

Выполнение инструкции блока или цикла не влияет на стек значений.
Может быть, это должно измениться на:
Выполнение инструкции блока или цикла не влияет на стек значений, но все значения стека за пределами блока выполнения блока недоступны.
Или я недопонимаю?

Да, наверное, стоит упомянуть что-то подобное на Semantics.md. Хотя я должен упомянуть, что есть работа и над формальной спецификацией прозы.

binji 28 мар. 2017

👍1

Означает ли это, что каждый блок получает свой стек?
Я бы не сказал, что у них есть свои стеки, просто есть лимит
к чему можно выскочить. Собственно так это и реализовано в wabt, там
представляет собой стек значений и стек «меток». На каждой этикетке хранится «лимит», который
размер стека значений при нажатии метки. Тогда всякий раз, когда вы
pop, вы проверяете лимит верхнего лейбла.

rossberg 28 мар. 2017

👍2

Спасибо за информацию. Я закрываю это, так как из этого не следует ничего действенного, и появляются более формальные спецификации, чтобы разъяснить это.

cretz 6 апр. 2017

Была ли эта страница полезной?

0 / 5 - 0 рейтинги