Для развиваемого проектом GNU инструментария (binutils, gcc, glibc) подготовлен (https://sourceware.org/ml/binutils/2017-03/msg00044.html) рабочий прототип бэкенда (https://github.com/pipcet/asmjs) с поддержкой новой архитектуры - WebAssembly (https://www.opennet.ru/opennews/art.shtml?num=46117). Бэкенд позволяет использовать GCC для компиляции исходных текстов на языках C/C++ в промежуточный код WebAssembly для последующего выполнения в web-браузере или JavaScript Shell. В binutils добавлена поддержка генерации модулей в формате объектных файлов WebAssembly и упаковки/обработки блоков WebAssembly в исполняемых файлах в формате ELF.Реализована поддержка трёх целевых платформ: asmjs (https://github.com/pipcet/asmjs/blob/everything/asmjs.org) (JavaScript с расширениями Asm.js), wasm32 (https://github.com/pipcet/asmjs/blob/everything/wasm32.org) (WebAssembly с 32-разрядной целочисленной арифметикой) и wasm64 (WebAssembly с 64-разрядной арифметикой с плавающей запятой). На начальной стадии разработки бэкенда были использованы некоторые наработки проекта Emscripten (https://github.com/kripken/emscripten) (компилятор биткода LLVM в JavaScript), но в текущем виде бэкенд не привязан к Emscripten, и все заимствованные из него компоненты заменены на штатные возможности GCC и glibc. В частности, компиляция осуществляется с использованием штатного фронтэнда GCC, предоставляющего все имеющиеся оптимизации, а также специально подготовленного бэкенда, транслирующего внутренний байткод GCC в промежуточный код WebAssembly.
Утилита "GNU as" может применяться для создания объектного файла в формате ELF, в который при необходимости можно поместить отладочную информацию в формате DWARF. Компоновщик "GNU ld" может быть использован для связывания объектных файлов в исполняемый ELF-файл, который при помощи утилиты wasmify-wasm32 может быть преобразован в формат модуля WebAssembly, пригодного для загрузки в браузере.
Напомним, что по своим задачам WebAssembly во многом напоминает PNaCl (Portable Native Client) и Asm.js. Основное отличие от Asm.js состоит в том, что WebAssembly является бинарным форматом, не завязанным на JavaScript и позволяющим выполнять в браузере низкоуровневый промежуточный код. В отличие от PNaCl, промежуточный код WASM не является машинным кодом и не изолирован в отдельной виртуальной машине, а выполняется с похожим на JavaScript уровнем изоляции. Среди основных задач WebAssembly выделяется обеспечение переносимости между браузерами, предсказуемость поведения и идентичности выполнения кода на разных платформах. Использование WebAssembly также позволит существенно сократить размер приложений, благодаря компактному промежуточному коду, и увеличить скорость декодирования.
URL: https://sourceware.org/ml/binutils/2017-03/msg00044.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=46136
WASM звучит ностальгически)
В Хроме-то WebAssembly от Asm.js по скорости отстаёт.
Насколько? И как насчёт скорости загрузки?
Субъективно — весь геймплей медленнее процентов на 30-40.Зайдите в демки WebAssembly и попробуйте самостоятельно.
Может мне OpneCL не хватает или еще какие особенности системы.
Поясните, теперь есть возможность собрать QML приложение?
Она и раньше была, Qt и QML уже работают в связке с Emscripten, другое дело, что если вы ожидаете, что QML будет работать "нативно", то это не так, для этого надо отдельно проделать массу работы.
Интересно средствами GCC, а не Emscripten.
Именно, ожидаю нативной работы, уж очень ненавистен мне html, поскорее бы...
Взгляните на Qt for Native Client https://www.opennet.ru/opennews/art.shtml?num=43039
Ну и Wt (https://www.webtoolkit.eu/wt/ru/) уже давно работает.
А в сокеты и треды оно умеет?
Сокеты - нет (только то API что доступно JavaScript), поддержка тредов для javascript уже есть в некоторых бразуерах, но по умолчанию отключена (смотреть дополнительно можно отсюда и по ссылкам https://kripken.github.io/emscripten-site/docs/porting/pthre...)
Если оно умеет в сокеты, тогда придётся браузер держать в отдельной зафайерволенной виртуалке, чтоб ничего кроме 80 и 443 не позволялось.
При чём тут сокеты? Сокет это просто программная абстракция.К.О.
webgl тоже программная абстракция, к вопросу "оно умеет webgl" ты тоже придерешься?
WebGL - это интферфейс вполне себе к железу, если ты не знал
Оно вполне может не уметь webgl. Это же для c++ интерфейс.
мб он про WebSockets на которые с http0.9/1.0/1.1/2.0 все никак не мигрируют пользователи и дизайнеры веб-а ? (отчасти из TCP-like первого, возможно и латентности в целом завышенной. да и масштабируемости пока неидеальной для multicore/manycore в 70% реализаций)
Я имел ввиду BSD Socket. Т.е. загрузится вместе со страничкой какая-нибудь хрень, откроет на прослушивание обычный сокет и будет ждать команд от управляющего сервера.
то, что сейчас она может это делать поллингом или (последние лет семь) через вебсокеты - вас устраивает? Или в чём разница, не пойму
> Если оно умеет в сокеты,Ты не поверишь, что умеют современные ОСи^W браузеры.
> А в сокеты и треды оно умеет?Web сокеты и Web треды :-)
Компилируя Web компилятором по Web браузер,
а пользоваться можно только Web пользоватлям
это и javascript умеет.
После добавления DOM API и других в WASM можно будет, допустим, переписать React и другие классные либы на C++ и потом также делать import этих либ в JS-коде?
Здравая мысль.
А зачем тогда вообще JS, если можно всё на C++ ?
Будут тогда беспорядки во многих городах из-за восстаний безработных JavaScript разработчиков.
А зачем вообще другие языки, если всё можно на си++?
Да бездельники напридумывали языков, вместо того чтобы работать
> Да бездельники напридумывали языков, вместо того чтобы работатьНу да лучше что бы они на JavaScript понаписали уйму сайтов продажи часов
Прокрастинация. Когда человек делает всё, что угодно, лишь бы не писать на с++, даже разрабатывает новый язык.
На Хаскеле же
Потому что писать на плюсах вместо JS - это дорого и долго для "простых вебстраничек". Для сложного софта - наоборот.
> Потому что писать на плюсах вместо JS - это дорого и долго
> для "простых вебстраничек". Для сложного софта - наоборот.это "дорого" только в плане первичных вложений, особенно стоимость Найма/Поиска сепциалиста реально Способного написать оное в формате расширения веб-сервера+udf/t-squl и подобных(те связка расширения веб-морды с логикой веб-приложения бегающего внутри SQL-сервера(или распределенной БД) а не на веб-серваке, "как обычно".).
в долгосрочной - очень себя окупает. и по деньгам и по деньгам за счет большей масштабируемости и секьюрности и надежности.
плюс если не наравится C++ можно все это собирать на Любых ОП, поддерживающих сборку оных модулей под веб-морду/сервер (ДБ сервак Сам компилит свое, обычно).
То есть вы правда считаете, что умеете считать деньги лучше всех этих корпораций, делающие свои продукты на питонах/рельсах/пхп/nodejs, а не на с++?
Корпорации поэтому и делают деньги, потому что на разработку тратят три копейки, а продают за три рубля. В отличие от продвинутого Васи++, который разрабатывает за 2 рубля, а продаёт за 2.5, чтобы хоть как-то покупали.ЗЫ. В опросе CPP vs JS отдам голос за CPP - хоть и мало довелось писать на + и относительно много на JS.
> Корпорации поэтому и делают деньги, потому что на разработку тратят три копейки,
> а продают за три рубля. В отличие от продвинутого Васи++, который
> разрабатывает за 2 рубля, а продаёт за 2.5, чтобы хоть как-то
> покупали.А что Вам не нрвиться в этих языках. Воспринимайте их как расширение для C++. Просто какой-то фреймворк на подобии apr только с поддержкой конфигов определенного синтаксиса. Я вот всегда так думаю когда пишу на языках отичных от си.
Я даже представить не могу, в каких случаях такая стрёмная архитектура может себя окупить. Осмысленный вариант делается ровно наоборот - пачка слабо связанных модулей, в каждом из которых вообще пофигу на чём написаны и где находятся все остальные, густо пересыпанная кэшами. А ты предлагаешь зачем-то даже MVC отменить и ляпать монолит.
Ваша идея кошмарна.
>писать на плюсах вместо JS - это дорого и долгопральна, надо на питоне!
>>писать на плюсах вместо JS - это дорого и долго
> пральна, надо на питоне!как там в питоне то синхронизация и гил уже разрешился
Потому что JS лучше CPP
Да, нашёл ответ. http://webassembly.org/getting-started/js-api/
можно, только в этом нет никакого смысла. Бутылочное горлышко в реактах с ангулярами - не javascript, а трансформации DOM дерева
Можно. Вообще, это уникальная возможность получить единый апи для любых библиотек написанных на любых языках. Только представьте: идеальная интероперабельность, никаких костыльных биндингов.
> Можно. Вообще, это уникальная возможность получить единый апи для любых библиотек написанных
> на любых языках. Только представьте: идеальная интероперабельность, никаких костыльных
> биндингов.Как показывает опыт последних лет 20 как-то все выходит боком. Все не совместимо и простые операции вроде линий, канвасов и т.д. не работал со звуком и сокетами, но и там я так понимаю протокола одного нет.
А фронтэнд для Rust в GCC будет?
В расте уже есть таргет wasm32-unknown-emscripten
Годнота.
Когда уж JS отомре
Даешь больше дыр в браузер!
> Даешь больше дыр в браузер!не, как раз WebAssembly - снижает эксплоитируемость "из интернета" и ощутимо.
надо туда еще помимо JS запилить бидон и перл, как самые популярные из "перманентно уязывимых" и еще какую-нить хрень "из числа модных"(лисп ? руби? и прочую хрень. хаскель, эрланг, что угодно).
Можно подробнее почему WASM безопаснее JS? Ну кроме того, что у него сейчас нет доступа ко многим API, к которым есть доступ у JS, и что, вроде как, собираются исправить.
Из Web assembly доступны все те же апи что и js, не больше, не меньше.
Так теперь emscripten не нужен, я правильно понял?
> Так теперь emscripten не нужен, я правильно понял?Будет нужен как минимум еще лет 10 для всяких там майкросовтов я думаю
Чё-то я не понял, а это как объяснить? Где тут промежуточный код WebAssembly?>The GitHub sources include support for using asm.js instead of wasm
Это вообще сбоку. Перевод - "мы умеем генерировать не только wasm, но и asm.js"
Правильный перевод - "Исходники на gihub включают поддержку использования asm.js ВМЕСТО wasm". В новости же говориться, что - "Бэкенд позволяет использовать GCC для компиляции исходных текстов на языках C/C++ в промежуточный код WebAssembly".Может кому-то всё же стоит выучить английский?
А голову включить? Речь о том, что можно (используя asmjs-virtual-asmjs-gcc) генерировать asm.js вместо wasm. А можно - взяв wasm32-virtual-wasm32-gcc - генерировать собственно wasm.
Здесь телепатов нет, написано чётко и ясно, что это бекэнд только для asm.js.Точно так же, как ты я мог утверждать, что это бекэнд для генерации webGL или для web sockets. Ну, а чё это же любому понятно хоть нигде и не написано.
> Здесь телепатов нет, написано чётко и ясно, что это бекэнд только для
> asm.js.
> написано чётко и ясно
>> The GitHub sources include support for using asm.js instead of wasЧетко и ясно тут только, что включена поддержка использования asm.js вместо wasm.
Если ты не можешь в телепатию, то читай тексты целиком, а не случайно выдранные оттуда фразы.
>>The GitHub sources include support for using asm.js instead of wasm, and some rudimentary support for simulating a 64-bit machine using wasm.
> Правильный перевод - "Исходники на gihub включают поддержку использования asm.js ВМЕСТО
> wasm". В новости же говориться, что - "Бэкенд позволяет использовать GCC
> для компиляции исходных текстов на языках C/C++ в промежуточный код WebAssembly".Рукалицо.
> Может кому-то всё же стоит выучить английский?
Разрешаю приступать.
>and some rudimentary support for simulating a 64-bit machine using wasmСлова rudimentary и simulating сам переведёшь или ссылку на гугол транслейт дать?
В новости написано - "Бэкенд позволяет использовать GCC для компиляции исходных текстов на языках C/C++ в промежуточный код WebAssembly". По факту же была представлена ЗАЧАТОЧНАЯ поддержка СИМУЛЯЦИИ 64 битной машины. Ни о какой компиляции в промежуточный код в оригинале сообщения не говорится вообще.
Ну ты хоть разок как-то вникни в вопрос прежде чем постить. Или на ключевые слова только реагируешь? Там ДВА бакэнда для wasm: 32-bit и 64-bit. О чём в новости ясно написано.32-bit поддерживаются идущим в релиз в браузерах WebAssembly и этим компилятором. 64-bit не релизится в браузерах и недопилен в этом компиляторе.
С гитхаба: "wasm64 support is severely outdated (and simulates 64-bit operations as 32-bit ones anyway; the wasm MVP will probably not contain 64-bit support)." Остальные пруфы гугли сам.
coreutils уже можно им собрать?
Это что, теперь можно сайт написать на С/С++ и бинарником послать в браузер!? Если это так, то это просто отвратительно ...
> Это что, теперь можно сайт написать на С/С++ и бинарником послать в
> браузер!? Если это так, то это просто отвратительно ...Не сильно "бинарнее", чем обфусцированный яваскрипт, в плане того, что вы сможете понять. Бинарник, да, но есессно не нативный. Декомпилироваться должен неплохо, байт-код очень высокоуровневый.
Декомпилируется он на самом деле паршиво, впрочем как и asm.js код. Информации о размерах и типах структур нет. Но есть информация по количеству параметров функций, но это не поможет отличить int32,char*,int*. Ну и при желании можно все параметры запихнуть в стек и понять можно будет лишь наличие возвращаемого значения.
Уже года три как можно в виде asm.js :-) В WebAssembly просто его косяки реализации убрали
Это вместо gcj?
Очередной маразм а-ля java applets, только теперь "не в прямоугольничке". Поиграются, потратят силы и выкинут!
Выкинуть будет очень не просто. Обычно от стандартов отказываются, когда есть лучшая альтернатива или спрос ушел в 0. Здесь ни того, ни другого не предвидится.
Нет, это то, что надо было сделать с самого начала, встроить в браузеры виртуальную машину исполняющую универсальный байткод, а не фронтенд специального языка специально для web - JavaScript.
В отличие от плагинов java и флеш, webasm использует тот же апи, что и js. Исполняется с теми же правами что и js.
> Нет, это то, что надо было сделать с самого начала, встроить в
> браузеры виртуальную машину исполняющую универсальный байткод, а не фронтенд специального
> языка специально для web - JavaScript.
> В отличие от плагинов java и флеш, webasm использует тот же апи,
> что и js. Исполняется с теми же правами что и js.Итак, изначально мы берем одного разработчика и он фигачит и на HTML и JavaScript и черт знает еще на чем PHP, SQL и т.д.
А теперь нужно заморочиться и создать проект туда нафигарить кода для сайта еще и дизайн для сайта сделать, так как элементарно нужно будет хотя бы ID как-то указывать.
То есть если раньше порог вхождения в сайты был простой, то теперь порог вхождения стал гораздо больше, а ... а результат точно такой же.
Почему результат такой же все просто код JavaScript все равно на стороне клиента будет откомпилирован в байт код. Короче говоря толку мало а возни полным полно
>[оверквотинг удален]
> т.д.
> А теперь нужно заморочиться и создать проект туда нафигарить кода для сайта
> еще и дизайн для сайта сделать, так как элементарно нужно будет
> хотя бы ID как-то указывать.
> То есть если раньше порог вхождения в сайты был простой, то теперь
> порог вхождения стал гораздо больше, а ... а результат точно такой
> же.
> Почему результат такой же все просто код JavaScript все равно на стороне
> клиента будет откомпилирован в байт код. Короче говоря толку мало а
> возни полным полноДизайн* = architecture
Я не понял, мода на javascript прошла? Возвращаемся в нативному c++? Колесо сделало очередной оборот?