Про TRS-80 не сказана важная деталь: рынок был совершенно неясен, и первый выпуск этих машин был сделан с таким расчётом чтобы в случае неудачи использовать их для нужд самих точек RadioShack, в качестве машин для бухгалтерских расчётов. Очень дальновидное решение, которое позволило рискнуть и занять серьёзную нишу на практически пустом рынке.
EmuZWin у меня под Windows 10 работал вполне себе норм. Я под ним в прошлом году расковыривал Highway Encounter, чтобы сделать порт под УКНЦ: github.com/nzeemin/uknc-highwayencounter
Здесь речь про два разных компилятора. Тот что генерит короткую строку — это компилятор использующийся в WasmFiddle. 27 Кбайт даёт emscripten. Какой конкретно компилятор использует WasmFiddle — не знаю, не разбирался.
Моё чисто субъективное мнение по интерфейсу PVS-Studio в Visual Studio.
По сути это плагин (add-on), но он требует к себе очень много внимания. Постоянно вылезают всплывающие окошки. Прогресс работы — можно было сделать внутри обычного окна, зачем-то сделано всплывающее окно. Постоянно спрашивает про лог работы сохранить/нет, вместо того чтобы сохранять с каким-нибудь дефолтным именем. Даже при закрытии студии выводит всплывающее окно. Как минимум это неприятно.
Также интерфейс окна анализа отличается от остальной студии, не выглядит естественным дополнением, и особенно коряво выглядит окошко прогресса при запуске анализа.
Если бы я использовал ваш анализатор постоянно то я бы быстро на консольную версию перешёл, убрав его из студии насовсем.
Можно придумать класс приложений, где WebAssembly получит существенные преимущества. Пример: клиент для биржи, вывод списков/графиков на canvas/webgl, общение с сервером через websocket по бинарному протоколу (данные из websocket напрямую кидаем в WASM и расшифровываем уже там).
WASM перед исполнением сразу весь целиком преобразуется в найтивный (родной) код вашего процессора. По сравнению с JS нет стадии парсинга текста. WASM это простая стековая машина, поэтому каждая инструкция WASM преобразуется всего в несколько инструкций реального процессора. отсюда и скорость.
Честно говоря, не знаю состояние по Pascal, упомянул только для примера.
Вопрос у меня не об этом. Для C/C++ Emscripten уже предоставляет всё готовое. Но для других языков (даже если они полностью поддерживаются LLVM) видимо придётся писать свои скрипты сборки?
Потенциально, в будущем — да.
Но сейчас пока предложенная модель выполнения довольно ограничена и лучше всего подходит для C/C++. В частности, пока нет сборщика мусора, реализацию которого конечно можно затащить внутрь WASM, что несколько увеличит его объём. Я не изучал подробно что ещё из других языков есть, но по-моему, большая часть это скорее эксперименты чем что-то production ready.
1. теоретически — возможно, практически — бенчмарки показывают что результат может быть совсем другим.
2. а откуда у вас именно 10-15%? или это просто из моего же текста? я кстати взял из одного из ответов со StackOverflow — чувак там очень авторитетно говорил про 10%, без всякого подтверждения фактами конечно.
Лучше/хуже — не знаю. Почему — не знаю :)
Вот почему-то не захотелось им затаскивать Java runtime прямо в браузер.
Google предлагал ещё NaCl и PNaCl — это по сути LLVM back-end затаскивается в браузер. Mozilla тоже сказала нам так не интересно.
WASM это просто байткод для виртуальной машины. Он появляется в результате компиляции.
Из компиляторов самый продвинутый это Emscripten, он собирает WASM из C/C++. Кроме того, в Emscripten для WASM уже адаптировано много стандартных и популярных библиотек. При сборке кода в WASM происходит сборка как в варианте со «статической компиляцией» — весь используемый код всех библиотек помещается внутрь, размер WASM при этом конечно может получиться большим. Для «поддержки» работы WASM Emscripten также генерит кучу обёрток/клеевого кода на JavaScript.
Помимо WASM, в качетве альтернативы, Emscripten умеет компилить в asm.js, результат работает так же как WASM (возможно, немного медленнее) и работает на бОльшем наборе браузеров.
Есть и другие компиляторы кроме Emscripten, например, AssemblyScript компилирует в WASM из TypeScript. С деталями его работы я НЕ знаком, не приходилось использовать.
Насколько я понимаю, первоначально — через последовательный канал, «телетайп», а уже позже через сетевой интерфейс.
По сути это плагин (add-on), но он требует к себе очень много внимания. Постоянно вылезают всплывающие окошки. Прогресс работы — можно было сделать внутри обычного окна, зачем-то сделано всплывающее окно. Постоянно спрашивает про лог работы сохранить/нет, вместо того чтобы сохранять с каким-нибудь дефолтным именем. Даже при закрытии студии выводит всплывающее окно. Как минимум это неприятно.
Также интерфейс окна анализа отличается от остальной студии, не выглядит естественным дополнением, и особенно коряво выглядит окошко прогресса при запуске анализа.
Если бы я использовал ваш анализатор постоянно то я бы быстро на консольную версию перешёл, убрав его из студии насовсем.
files.viva64.com/PVS-Studio_setup.exe — даёт connection timeout
Вопрос у меня не об этом. Для C/C++ Emscripten уже предоставляет всё готовое. Но для других языков (даже если они полностью поддерживаются LLVM) видимо придётся писать свои скрипты сборки?
— вот тут вопрос допустим я хочу собирать Pascal-код, LLVM frontend давно есть, но мне же тут придётся городить свой toolchain, верно?
Но сейчас пока предложенная модель выполнения довольно ограничена и лучше всего подходит для C/C++. В частности, пока нет сборщика мусора, реализацию которого конечно можно затащить внутрь WASM, что несколько увеличит его объём. Я не изучал подробно что ещё из других языков есть, но по-моему, большая часть это скорее эксперименты чем что-то production ready.
2. а откуда у вас именно 10-15%? или это просто из моего же текста? я кстати взял из одного из ответов со StackOverflow — чувак там очень авторитетно говорил про 10%, без всякого подтверждения фактами конечно.
Вот почему-то не захотелось им затаскивать Java runtime прямо в браузер.
Google предлагал ещё NaCl и PNaCl — это по сути LLVM back-end затаскивается в браузер. Mozilla тоже сказала нам так не интересно.
Можно обращаться к DOM через JS, и это будет подтормаживать.
И это всё есть в статье :)
Из компиляторов самый продвинутый это Emscripten, он собирает WASM из C/C++. Кроме того, в Emscripten для WASM уже адаптировано много стандартных и популярных библиотек. При сборке кода в WASM происходит сборка как в варианте со «статической компиляцией» — весь используемый код всех библиотек помещается внутрь, размер WASM при этом конечно может получиться большим. Для «поддержки» работы WASM Emscripten также генерит кучу обёрток/клеевого кода на JavaScript.
Помимо WASM, в качетве альтернативы, Emscripten умеет компилить в asm.js, результат работает так же как WASM (возможно, немного медленнее) и работает на бОльшем наборе браузеров.
Есть и другие компиляторы кроме Emscripten, например, AssemblyScript компилирует в WASM из TypeScript. С деталями его работы я НЕ знаком, не приходилось использовать.