https://webassembly.github.io/spec/core/

Что интересно - в основе опять стековая машина. Она не напрямую соответствует Форту, поскольку отсутствуют стековые манипуляторы (впрочем, drop присутствует в явном виде). Однако же для команд ВМ приведена непосредственно стековая нотация.

WebAssembly, согласно публикуемым материалам, не предназначена для замены существующих языков. Вместо этого многие языки транслируются в wasm, а коды выполняются браузерами. В этом смысле Форт мог бы выступать в качестве входного языка, трансляция из которого будет довольно простой.

Наверное черпали вдохновление смотря на Java byte code и CLI (C#) и фиг ещё знает что.
А, про DUP почему забыли? (и другие стэковые операторы)

корни WebAssembly, возможно, уходят ещё и к Tamarin Tracing (JS V8)

P.S. Вот когда аппаратно выведут стековую Форт архитектуру в поле массового использования тогда и можно будет что обсуждать.

И зачем вдруг такое? Для достижения пиковой производительности именно на Форте? Так она объективно не достигается, поскольку увеличение количества адресов (индексов) в команде способствует увеличению производительности. Стек - бутылочное горлышко для вычислений. С помощью процессоров с аппаратным стеком можно увеличивать производительности кода на Форте, если уж такой код откуда-то взялся по другим соображениям, но соображений брать именно Форт для высокой производительности нет.

На современном этапе производительность основана на корректном применении связки CPU/GPU/FPGA в необходимых сочетаниях. Бессмысленно даже начинать проект, который на Форте обгонит GPU в построении трехмерных изображений, однако вызывать код для GPU можно из разных языков. Фреймворки на Питоне уже достаточно распространены для самых разных платформ - просто для того, чтобы облегчить вхождение в технологию, не заставляя людей учить HDL или nvcc. Так что и фреймворк в виде DSL на базе Форта вполне представим. Делать из него непременно низкоуровневый сверхбыстрый код (а то и вообще Форт-ОС) - совершенно другая задача с крайне сомнительными перспективами, и нет смысла утыкаться в нее, игнорируя действительно перспективные подходы.

Хотя бы, в переложении кода на регистры, добавить подсказок JIT по дальнейшему использованию копий регистров из стэкового пула.

P.S. По поводу производительности стэкового кода - как его смогли ускорить в Java Jit?
А, как насчёт бутылочного горлышка x86 комманд и их постоянного ускорения?


Чем Бэйсик с этих позиций был плох?

Ничего не понял. Что писать-то на этом всем? Какие регистры, что и куда? Сегодня ситуация такая - wasm предназначен для запуска промежуточного кода, генерируемого разными языками. При чем тут отсутствие стековой архитектуры в поле массового использования?