WebAssembly

Полиморфизм в языках программирования

OCTAGRAM — Wed, 11 Dec 2024 16:52:55 GMT

На тему разных языков программирования написаны разные книги. И классика В.Ш. Кауфмана, и Glynn Winskel. Но если бы попросили выделить отличия языков программирования, то как бы на этот вопрос ответил автор? И автор бы начал с описания кватернионов. Что известно про комплексные и гиперкомплексные числа?

$CUT$

У вещественных чисел есть линейный порядок. У комплексных чисел линейного порядка уже нет.
Умножение комплексных чисел коммутативно. Умножение кватернионов некоммутативно.
Умножение кватернионов ассоциативно. Умножение седенионов не ассоциативно, но альтернативно.

Видно, как по мере усложнения структуры теряются свойства. Усложнение структуры можно далее называть «Синтезом», а способность алгебраической системы быть проанализированной можно назвать «Анализом». Синтез и Анализ, — альфа и омега языков программирования.

Что можно сказать про соотношение Синтеза и Анализа?

Больше Синтеза, → обычно меньше Анализа
Меньше Синтеза, → вовсе не факт, что больше Анализа
Анализ на заказ обычно просто не выполним. Интересный Анализ открывают, а не заказывают

Например, по теореме Адамса существуют только четыре расслоения Хопфа. Спорадических групп 26 (с группой Титса 27).

Если захотеть заказывать Анализ, может просто ничего не получиться. Ну захотим гиперкомплексные числа размерности три, математики разведут руками. Можно поупрямствовать. Можно каждое ненулевое тройное число разложить на радиус и направление, и определить умножение тройных чисел как умножение радиусов отдельно, а для направлений использовать правило параллелограмма на сфере. Получается алгебра без особенно интересных свойств.

Так и в устройстве языков программирования. Анализируемые свойства растут из структуры. Можно проиграть сразу на двух фронтах, и Синтез завалить, и в обмен на заваленный Синтез так и не получить никакого интересного Анализа. И ещё не получается потребовать Анализ на заказ. Как общий принцип, делается какое-то открытие анализируемой структуры, и этот Анализ цементируется в языке программирования, и исходя из зацементированного Анализа, программисту выдаётся доза Синтеза, не идущая вразрез с выбранной дозой Анализа, и потом доза Синтеза по возможности увеличивается, но пределы очерчены изначально. Увеличение Синтеза, не идущее вразрез с Анализом, — это обычно синтаксический сахар, всё больше и больше синтаксического сахара, впрочем, и сам синтаксический сахар тоже не вполне полезен для Анализа, ведь исходные тексты могут быть подвергнуты Анализу со стороны разного инструментария, и новый синтаксический сахар сразу их все ломает, если только нет общепринятого промежуточного представления.

Структуры для полиморфизма

Сделав такое введение, можно рассматривать полиморфизм в языках программирования. Всё растёт из структуры. А структуры не заказываются, структуры открываются.

Какие структуры в языке программирования могут отвечать за полиморфизм? Это:

структура ссылки
структура нечто по ссылке

Под ссылкой имеются в виду даже и такие сущности, как параметры методов. Ведь нужно же вызывать методы. У метода должен быть какой-то формальный тип параметра. А передаётся значение какого-то актуального типа. От системы типов ожидается, что значение вызывающей стороны состыкуется с ожиданиями вызываемой стороны. Возможность стыковки определяется совместимостью на двоичном уровне, а совместимость на двоичном уровне, — это уже Анализ. Тот самый Анализ, который не бывает на заказ, а бывает только как открытие, и проистекает из Синтеза структуры. Даже если язык программирования не в машинных кодах, эти принципы действуют. Не претендуя на новые открытия, перечислим варианты устройства ссылки и нечто по ссылке.

Структура ссылки

И здесь известные интересные варианты:

вообще не указатель, а непосредственно содержимое
один указатель
два указателя

В контексте полиморфизма 1, как в языке программирования Ада. generic. И generic в Delphi. И template в С++.

Один указатель, — тоже частый вариант. Можно встретить в COM, Delphi interface и Objective-C. В других языках программирования можно воплотить, но отложим это до рассмотрения структуры нечто по ссылке.

Два указателя, — вариант реже, но встречаемый. Это Rust. В других языках программирования можно это встретить для ссылки на отдельный метод. В Delphi есть синтаксис of object, объявляющий двойной указатель. В Objective-C нет явного типа, но популярна передача ссылки на объект и селектора к нему для подписки на событие.

Трудность с двумя указателями в том, что в процессорах есть инструкция DCAS, двойного сравнения и замены, и если указателей уже и так два, то весь DCAS придётся тратить на одну двойную ссылку, а две двойных ссылки не получится покрыть DCAS. Не в любом процессоре есть DCAS, но всё же часто сейчас можно ожидать, что есть. В линейке x86 инструкция cmpxchg8b появилась в Pentium, и с тех пор DCAS вроде бы как долго был доступен. Когда происходил переход с Intel x86 на AMD 64, новые процессоры ставились в старые слоты материнской платы. И тут получалось, что материнская плата, чипсет, и вот это всё, оно может только CAS для 8 байт, а для 64 битов это одиночный CAS, а не двойной, и двойного снова нет, пока не обновить материнскую плату. В 2024 можно посчитать, что трудное детство компьютеростроения всё-таки позади, и всё-таки теперь и в 64 битах есть DCAS. cmpxchg16b. Но всё ещё нет cmpxchg32b и, наверное, и не будет.

Структура нечто по указателю

Произвольная
Одиночно наследуемая VMT
Динамическое разрешение метода

Известные комбинации структуры того и другого

Ada generic, Delphi template, C++ template

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

COM interface, взгляд со стороны Delphi хакера

Ссылка из одного указателя, а сразу по указателю одиночная VMT. Отличительной особенностью является то, что на один и тот же объект могут быть разные указатели. Слабая «идентичность». Хотя, если запросить IUnknown, то обычно через любой интерфейс можно получить одну и ту же ссылку на IUnknown. Кстати, запрос интерфейса здесь работает как «динамическое разрешение метода», только запрашивается сразу пачка. Но так как это не является основным способом вызвать метод, то далее ограничения как для одиночной VMT.

Что можно делать, если VMT одиночная? Можно усекать VMT. Ссылка на интерфейсный объект двоично подходит в любое место, где хотят IUnknown. И с каким-то потомком IUnknown это тоже сработает, вот только базовый интерфейс должен быть подлинно неизменным интерфейсом (проблема хрупкого базового класса).

Ещё можно, если у какого-то интерфейса входы-выходы известны, синхронно наращивать VMT. Например, если есть воплощение IList

Ещё можно усекать VMT сквозь контейнеры (ковариантность), но Delphi тоже не способна это проверить. Инвариантный IList

Но вот ведь незадача. Если по ссылке VMT с одиночным наследованием, и порядок нужно изобрести, то нужно определиться и выбрать только один вариант. Ну и, допустим, можно как промежуточную точку выбрать IReadOnlyList

Но какому фокусу не получится научить в рамках выбранного направления, так это ковариантности за пределами одиночно наследуемая VMT. То есть, одиночно наследуемая VMT образует рельсы, по которым можно ехать к корню (IUnknown) только в одном направлении. От ISomeAnotherInterface к IUnknown ведёт конечное количество остановок, и двоичная совместимость только для них. Примечание. Нет, всё же кое-что есть за пределами. IReadOnlyList

Как бы можно было это починить? Вспоминаем про лазейку через QueryInterface. Можно изобрести нечто такое:

type ICompatible

И чтобы это говорило честное слово, что, всё, что ICompatible

А напоследок можно рассмотреть ещё такие особенности VMT COM, и именно в Delphi, а потом COM не в Delphi.

По одиночной ссылке расположено нечто, про которое вызывающей стороне известно только что сразу по этому указателю указатель на VMT. И если через VMT вызвать метод, передать в метод указатель, то вызовется вроде бы как то, что нужно. А то, что нужно, выглядит как набор прыжковых инструкций, вычитающий известное воплощению смещение между интерфейсной VMT и началом объекта, и прыжок в метод объекта.

Но это не вся история. Это так происходит, если методы не виртуальные. А если виртуальные, то из интерфейсной VMT делается прыжок по объектной VMT. А всё вместе получается два прыжка! Про COM бытует представление, что виртуальный прыжок один, но нет, их два. Потому что в общем случае невиртуальные методы неудобные. Интерфейс весь виртуальный, а в классе метод нет? Странно. Только если класс с претензией на то, чтоб быть последним. А если возможны потомки, то методы виртуальные, и у них прыжковые таблицы для интерфейсов общие, и чтобы они прыгали в разные воплощения, они прыгают тоже через VMT, но объектную VMT.

Впрочем, можно поступить иначе. В Delphi интерфейсная таблица и связанный с ней набор прыжковых инструкций генерируется каждый раз, как после базового класса написать интерфейс. И выделяется новая ячейка для VMT, которая перекрывает старую VMT, но и старая VMT для того же самого интерфейса всё ещё есть. И при таком подходе можно замену сделать невиртуальными методами. Но если замена в базовом интерфейсе, то надо ещё не забыть перечислить и все унаследованные интерфейсы, Delphi это автоматически не сделает. И если их перечислить, то виртуальный вызов получается один, но какой ценой. Ценой выделения кучи дублирующих VMT, и эта куча растёт экспоненциально.

В C++ как-то делается COM через полное сходство с устройством абстрактных классов C++. Какой там выбран подход, автор не изучал, но что ни выбрать, исходы такие же. Или двойной виртуальный прыжок, или экспоненциально растущая куча дополнительных VMT ради того, чтобы виртуальный прыжок мог быть один.

Динамическое разрешение метода

Встречается в Objective-C. Благодаря такому выбору, у объектов единственная «идентичность». То есть, все ссылки на объект являются одним и тем же указателем. Хоть протокол (аналог интерфейса), хоть надкласс, хоть через какой вид смотреть на объект, указатель одинаковый. И поэтому проще ввести ковариантность/контравариантность. Их и ввели, в виде lightweight generics.

В Objective-C одиночное наследование классов и множественные протоколы, но это ограничение Objective-C. В System Object Model множественное наследование классов. Это тот случай, когда между Анализом и Синтезом остался зазор. Когда язык программирования, будучи в чём-то простым, и не улучшил Анализ, и не улучшил Синтез. Во множественное наследование классов можно пойти, это просто разработчики Objective-C не осилили, хотя сделали многое другое.

Недостатком динамического разрешения считается долгое разрешение метода, но кое-что по этому поводу можно предпринять. Дело в том, что даже в Objective-C применяются не строки как таковые, а селекторы, которые непрозрачны для программиста. В селектор можно записать подсказки для более быстрого поиска. А в System Object Model применяются жетоны методов, и сами жетоны методов можно искать через что-то вроде VMT, быстро. И жетоны методов исполняемые на некоторых платформах (OS/2 и Win32 точно да), так что если нет множественного наследования, а далеко не всегда оно есть, то рантайм может это отследить, и получается двойной виртуальный прыжок или даже одиночный. Почти как в COM, но первая VMT ищется не внутри объекта по ссылке.

Два указателя

Для полноты указан и такой вариант.

Это применяется в Rust, и это делает ООП в Rust экзотическим. Для полноты такая возможность указана, но автору не хватает опыта, чтобы вот так же с разных сторон рассмотреть, сравнить. Это похоже на COM, но у объектов единственная идентичность?

Также ссылка состоит из двух указателей в C++, если применять не intrusive_ptr, а shared_ptr. Начинает вторым указателем тащиться уничтожитель.

Русский research про олимпиады

OCTAGRAM — Sun, 21 Jul 2024 12:52:42 GMT

Минусы школьных олимпиад хорошо известны: как с точки зрения освоения профессии, так и с точки зрения воспитания. Привожу мнение об олимпиадной математике отсюда (с небольшими сокращениями):

$CUT$

Я считаю, что олимпиадное движение развращает математиков. Они теряют способность заниматься сложными теоремами.

Представьте, что кто-то решил поставить амбициозную цель: съесть быка. Вы ж понимаете, что он за один раз быка не проглотит. И даже если будет есть большими кусками, то подавится и умрёт. Чтобы съесть быка, надо отрезать маленькие кусочки, которые легко прожевать и проглотить. И ещё нужно растянуть поедание во времени, иначе просто не справишься. А ещё надо правильно хранить быка, чтоб не испортился.

То есть, работа с амбициозными задачами — сложная, требующая высокой культуры труда. Тут нужно максимальное облегчение каждого шага, чтобы идти длинным путём к далёкой цели. Нужна романтика пути, где впереди вершина горы, а ты движешься маленькими шажками, с передышками, чтоб дотянуть до конца.

Олимпиадное движение развращает: оно совершенно ломает схему сложной работы. В олимпиадном движении нет вообще никакой далёкой цели, там вообще не нужно двигаться далеко. Просто нужно научиться глотать огромные куски за один раз. То есть, олимпиадников учат вещам, противоположным настоящей крутизне.

Их вводят в заблуждение: мол, ты решил трудную олимпиадную задачу за полчаса — и всё, ты супер-пупер крутой. Да нифига ты не крутой! Крутой тот, кто смог пройти длинный путь за десять лет, сделать что-то реально большое. Вот это настоящая крутизна!

Комментарий Русский Research:

Трудно спорить с тем, что высокие результаты в олимпиадах говорят о выдающейся сообразительности и скорости мышления. Особенно в математике, где роль заучивания и муштры минимальна. Однако, как показывает опыт, победы в школьных олимпиадах действительно слабо коррелируют с успехами в научной работе, а зачастую не гарантируют и просто успешного окончания университета.

Математические олимпиады у нас тоже были, и по физике, но наибольший упор на олимпиады по информатике. На фото ACM 2003. И был вопиющий разрыв между интересной информатикой и олимпиадной информатикой. На интересной информатике программирование EGA на Ассемблере, на олимпиадной информатике нахождение максимального потока. И не встретиться им никак. Специально для нас другую интересную информатику никто не делал.

Тёмные углы Си

OCTAGRAM — Sun, 21 Jul 2024 11:50:08 GMT

Для того, кому нужно сделать транслятор языка Си, нужно понимать не как на нём писать, а как лучше сделать его транслятор. Планируемый транслятор должен понимать реальные исходники, такие как libmysqlclient, libpq, а в них может встретиться всякое. Полезно изучать, на чём споткнулись другие.

$CUT$

В этом помогает CIL, C Intermediate Language, на который предусмотрительно сохранена документация. Там пишут:

16 Who Says C is Simple?

When I (George) started to write CIL I thought it was going to take two weeks. Exactly a year has passed since then and I am still fixing bugs in it. This gross underestimate was due to the fact that I thought parsing and making sense of C is simple. You probably think the same. What I did not expect was how many dark corners this language has, especially if you want to parse real-world programs such as those written for GCC or if you are more ambitious and you want to parse the Linux or Windows NT sources (both of these were written without any respect for the standard and with the expectation that compilers will be changed to accommodate the program).

The following examples were actually encountered either in real programs or are taken from the ISO C99 standard or from the GCC’s testcases. My first reaction when I saw these was: Is this C?. The second one was : What the hell does it mean?.

If you are contemplating doing program analysis for C on abstract-syntax trees then your analysis ought to be able to handle these things. Or, you can use CIL and let CIL translate them into clean C code.

16.1 Standard C
Why does the following code return 0 for most values of x? (This should be easy.)
 int x;
 return x == (1 && x);
See the CIL output for this code fragment
Why does the following code return 0 and not -1? (Answer: because sizeof is unsigned, thus the result of the subtraction is unsigned, thus the shift is logical.)
 return ((1 - sizeof(int)) >> 32);
See the CIL output for this code fragment
Scoping rules can be tricky. This function returns 5.
int x = 5;
int f() {
 int x = 3;
 {
 extern int x;
 return x;
 }
}
See the CIL output for this code fragment
Functions and function pointers are implicitly converted to each other.
int (*pf)(void);
int f(void) {

 pf = &f; // This looks ok
 pf = ***f; // Dereference a function?
 pf(); // Invoke a function pointer? 
 (****pf)(); // Looks strange but Ok
 (***************f)(); // Also Ok 
}
See the CIL output for this code fragment
Initializer with designators are one of the hardest parts about ISO C. Neither MSVC or GCC implement them fully. GCC comes close though. What is the final value of i.nested.y and i.nested.z? (Answer: 2 and respectively 6).
struct { 
 int x; 
 struct { 
 int y, z; 
 } nested;
} i = { .nested.y = 5, 6, .x = 1, 2 }; 
See the CIL output for this code fragment
This is from c-torture. This function returns 1.
typedef struct
{
 char *key;
 char *value;
} T1;

typedef struct
{
 long type;
 char *value;
} T3;

T1 a[] =
{
 {
 "",
 ((char *)&((T3) {1, (char *) 1}))
 }
};
int main() {
 T3 *pt3 = (T3*)a[0].value;
 return pt3->value;
}
See the CIL output for this code fragment
Another one with constructed literals. This one is legal according to the GCC documentation but somehow GCC chokes on (it works in CIL though). This code returns 2.
 return ((int []){1,2,3,4})[1];
See the CIL output for this code fragment
In the example below there is one copy of “bar” and two copies of “pbar” (static prototypes at block scope have file scope, while for all other types they have block scope).
 int foo() {
 static bar();
 static (*pbar)() = bar;

 }

 static bar() { 
 return 1;
 }

 static (*pbar)() = 0;
See the CIL output for this code fragment
Two years after heavy use of CIL, by us and others, I discovered a bug in the parser. The return value of the following function depends on what precedence you give to casts and unary minus:
 unsigned long foo() {
 return (unsigned long) - 1 / 8;
 }
See the CIL output for this code fragment
The correct interpretation is ((unsigned long) - 1) / 8, which is a relatively large number, as opposed to (unsigned long) (- 1 / 8), which is 0.
16.2 GCC ugliness
GCC has generalized lvalues. You can take the address of a lot of strange things:
 int x, y, z;
 return &(x ? y : z) - & (x++, x);
See the CIL output for this code fragment
GCC lets you omit the second component of a conditional expression.
 extern int f();
 return f() ? : -1; // Returns the result of f unless it is 0
See the CIL output for this code fragment
Computed jumps can be tricky. CIL compiles them away in a fairly clean way but you are on your own if you try to jump into another function this way.
static void *jtab[2]; // A jump table
static int doit(int x){
 
 static int jtab_init = 0;
 if(!jtab_init) { // Initialize the jump table
 jtab[0] = &&lbl1;
 jtab[1] = &&lbl2;
 jtab_init = 1;
 }
 goto *jtab[x]; // Jump through the table
lbl1:
 return 0;
lbl2:
 return 1;
}
 
int main(void){
 if (doit(0) != 0) exit(1);
 if (doit(1) != 1) exit(1);
 exit(0);
}
See the CIL output for this code fragment
A cute little example that we made up. What is the returned value? (Answer: 1);
 return ({goto L; 0;}) && ({L: 5;});
See the CIL output for this code fragment
extern inline is a strange feature of GNU C. Can you guess what the following code computes?
extern inline foo(void) { return 1; }
int firstuse(void) { return foo(); }

// A second, incompatible definition of foo
int foo(void) { return 2; }

int main() {
 return foo() + firstuse();
}
See the CIL output for this code fragment

The answer depends on whether the optimizations are turned on. If they are then the answer is 3 (the first definition is inlined at all occurrences until the second definition). If the optimizations are off, then the first definition is ignore (treated like a prototype) and the answer is 4.

CIL will misbehave on this example, if the optimizations are turned off (it always returns 3).
GCC allows you to cast an object of a type T into a union as long as the union has a field of that type:
union u { 
 int i; 
 struct s { 
 int i1, i2;
 } s;
};

union u x = (union u)6;

int main() {
 struct s y = {1, 2};
 union u z = (union u)y;
}
See the CIL output for this code fragment
GCC allows you to use the __mode__ attribute to specify the size of the integer instead of the standard char, short and so on:
int __attribute__ ((__mode__ ( __QI__ ))) i8;
int __attribute__ ((__mode__ ( __HI__ ))) i16;
int __attribute__ ((__mode__ ( __SI__ ))) i32;
int __attribute__ ((__mode__ ( __DI__ ))) i64;
See the CIL output for this code fragment
The “alias” attribute on a function declaration tells the linker to treat this declaration as another name for the specified function. CIL will replace the declaration with a trampoline function pointing to the specified target.
 static int bar(int x, char y) {
 return x + y;
 }

 //foo is considered another name for bar.
 int foo(int x, char y) __attribute__((alias("bar")));
See the CIL output for this code fragment
16.3 Microsoft VC ugliness

This compiler has few extensions, so there is not much to say here.
Why does the following code return 0 and not -1? (Answer: because of a bug in Microsoft Visual C. It thinks that the shift is unsigned just because the second operator is unsigned. CIL reproduces this bug when in MSVC mode.)
 return -3 >> (8 * sizeof(int));
Unnamed fields in a structure seem really strange at first. It seems that Microsoft Visual C introduced this extension, then GCC picked it up (but in the process implemented it wrongly: in GCC the field y overlaps with x!).
struct {
 int x;
 struct {
 int y, z;
 struct {
 int u, v;
 };
 };
} a;
return a.x + a.y + a.z + a.u + a.v;
See the CIL output for this code fragment

Летели шахматы с доски…

OCTAGRAM — Sun, 26 May 2024 22:53:26 GMT

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

$CUT$

История через призму GUI

Райские кущи Win32

В качестве точки отсчёта берём платформу Win32. Да, перед ней был DOS и ещё длинная цепочка платформ, но в DOS, например, не было динамически подключаемых библиотек. Вместо них, разве что, можно было написать TSR.

Win32 примечательна тем, что очень долго господствовала. От Windows 95 и где-то до Windows Seven (2009). Всё это время существовала массовая гомогенная среда исполнения. Один программист написал, у другого человека запустилось. У кого ни возьми, у всех запустилось. В Интернет выложил, из Интернета скачали, и запустилось. Были сайты freesoft и softportal, файлообменники. И казалось, это будет длиться вечность.

В этих райских кущах пышно расцвели самые разные языки программирования. Вообще, казалось, что Microsoft, ты давай там операционку делай, а в инструменты разработки не суйся, ты там ничего не понимаешь, только и можешь, что бейсиками своими дурацкими закармливать на все лады, то бейсик с пи-кодом, то с машинной трансляцией, то VB.NET со сборкой мусора, тьфу, нет, давайте лучше на красивом Delphi запрограммируем по заветам Вирта. О, а вот, смотрите, Ада ещё круче Delphi, а давайте с Delphi на Аду перейдём, а вместо VCL у нас будет GNAVI. Или ObjectAda+CLAW.

Первые звоночки

Нельзя сказать, что громкие звоночки, но тут в блоге всё субъективно, и первым звоночком хочется назначить переход макос 10.4 на Интел (2004). Если до этого макос был для элиты, то к хакинтошу прикоснулось немало смертных, и в их числе оказался и автор. На территории СНГ многие в те же года прикасались к Linux, и это можно ещё связать с проникновением Интернета в дома.

И тут неожиданно оказывается, что на макос и Linux нет многих полных аналогов того, что в Windows. Начинают лететь первые шахматы с доски. Жёстко привязанный к WinAPI Delphi VCL летит с доски. Delphi, портированный на Linux (Kylix), но не на макос, надолго слетел с доски, и очень нескоро вернулся.

Кроссплатформенность desktop-only

Укрепляют свои позиции так называемые кроссплатформенные графические движки. С точки зрения маковода красивее всего был XUL в основе Firefox. В современном Firefox, кажется, уже ничего не осталось от того прошлого XUL, а тогда это было перспективно. Делали кроссплатформенный плеер Songbird.

Следующей по уровню комфорта была библиотека wxWidgets. На одну ступень с wxWidgets можно поставить Java-библиотеку SWT.

Иерархия комфортности выстроена с точки зрения ощущения маковода. В Windows каждая программа норовила свои нестандартные меню отрисовать, чтобы выделиться, и это задавало тон. В Linux была солянка из Motif и других сейчас уже ничего не говорящих имён, и на фоне этой солянки ещё что-то торчащее незаметно. А в макос это было сильно не так. В макос была удобная продвинутая родная графическая библиотека Cocoa, и под неё багаж родных программ, унаследованный с PowerPC. И в макосе, если что-то топорщится, работает не как в системных программах, это ощущалось сильно заметно, и как правило, не в пользу программы. Вот XUL и wxWidgets автор ещё отнёс бы в положительную полуось комфортности.

Отрицательную полуось открывает Qt. Программ на Qt довелось использовать достаточно. Позже, когда Стив Джобс обосновывал, почему для iPhone такие жёсткие ограничения, он приводил в пример поганые кроссплатформенные программы на Qt, и что он не хотел превращать iPhone в гадюшник, и про Qt он макос он был прав, автор подтверждает это из первых рук. Там собственно отрисованное контекстное меню. Там не запускается жест переноса текста между программами, а вместо этого выделение сбрасывается и начинается с середины. И куча таких неудобств.

Про это писал Джоэл Спольски в статье «Лорд Пальмерстон в программировании»:

Я размышлял о том, как выпускать приложения для Linux, Macintosh и Windows, чтобы версии для Linux и Macintosh не оказывались неоправданно дорогими. Для этого нужна некая кроссплатформенная библиотека.

Такая попытка была сделана в Java, но Sun не удалось создать такие GUI, чтобы получаемые приложения выглядели достаточно натурально на каждой платформе. Примерно так же в «Звёздном походе» пришелец, разглядывавший землю в телескоп, точно знал, как должна выглядеть человеческая пища, но не знал, что у неё ещё должен быть какой-то вкус. У приложений Java меню находятся в правильном месте, но на клавиши они реагируют не так, как все другие приложения Windows, а диалоговые окна с закладками выглядят жутковато. И как бы вы ни старались, панели меню не будут выглядеть в точности, как панели меню Excel. Почему? Потому что Java не одобряет использование собственных средств платформы, если абстракции оказывается недостаточно. Если вы программируете в AWT, то не сможете узнать HWND окна, не сможете обращаться к Microsoft API и уж точно не сможете перехватить WM_PAINT и сделать все по-своему. И Sun достаточно хорошо разъяснила, что если вы попытаетесь это сделать, то лишитесь Чистоты. Вы Испорчены и пропадайте пропадом.

Swing и Qt работали на Windows ещё куда ни шло, но вот на макос это было постоянное расстройство.

Наконец, цепочку антилидеров замыкает Gtk+. И это ещё повезло антилидировать. Потому что VCL в это новое соревнование не попал.

Мобильные платформы

Отсчёт нового неприветливого мира можно брать примерно с iPhone (2007). Он качественно отличался от топовых моделей, например, Nokia N95 на Symbian. iPhone был уже ПК в миниатюре, а Nokia N95 ещё нет. iPhone уже отчасти был вместо ПК, а Nokia N95 ещё нет. Как уже было указано, Стив Джобс волевым решением ограничил Flash и всякие кроссплатформенные библиотеки, чтобы они не портили впечатление. Поэтому сложно сказать, так всё же с какого года следует вести эпоху нового неприветливого мира. Мира, уже ощутимо отдаляющегося от райских кущ Win32-only. По-настоящему мир стал неприветливым, когда сняли ограничение на библиотеки и языки программирования под iPhone OS, тогда она ещё так называлась. Стало можно писать не только лишь на Cocoa Touch, и не просто можно, а уже и нужно.

Как если прошлых неприятностей с кроссплатформенностью было мало, теперь ещё это. Теперь ещё так называемые мобильные платформы надо поддерживать. Сплошь и рядом в соцсетях вылезали хвастуны, которые «избавились от пылесборника». Теперь у них вместо компьютера какие-то недоразумения, на которых не работают ни Windows-программы, ни Linux-программы, ни макос-программы. Ничего не поделать. Придётся подстраиваться.

И снова полетели шахматы с доски. XUL решили похоронить и на desktop, и тем более не потащили в мобилы. Gtk+ не пережил пришествие мобил. С другой стороны, появились новые имена, такие как FireMonkey. Охватывает и desktop-, и мобильные платформы.

HTML5-апокалипсис

И снова у автора трудности с датировкой. В качестве опорной точки можно взять Gmail. Для желающих он был открыт с 2007го года, и тогда было это нечто из другого мира. Тогда ещё не было HTML5. Тогда был HTML4. Тогда не было WebSocket. Вместо них приходилось использовать кометные соединения или сокеты Flash. Тогда ещё была жива Opera 9 с собственным движком Presto. И были сильны позиции Internet Explorer. И Gmail работал ещё тогда, поверх всех этих старых технологий, кроме Internet Explorer. Для Internet Explorer был ActiveX-компонент Google Chrome Frame, а Opera какое-то время поддерживалась Gmail. Но потом поддержка Opera была прекращена.

Пока Gmail был вещью в себе, это был только зародыш грядущих изменений. Всё начало меняться, когда такие приложения нового поколения начали делать все. Трудно точно установить дату, когда стали пропадать вакансии Windows и Linux разработчиков. Кажется, в 2012 такая разработка была ещё очень даже востребована, а в 2020 уже всё заполонила вебня. В качестве точки отсчёта можно выбрать рождение HTML5, которое было в 2013-2014. Поверх старых технологий делать веб-приложения как Gmail, было утомительно, нужен был HTML5, WebSocket, CORS.

Проклятье Electron

И снова полетели шахматы с доски. Люди понапокупали себе всяких умных телевизоров, для которых вроде бы и есть SDK, но мало, кто его возьмёт. Кроме того, по принципу маркетинга каждый лишний клик уменьшает конверсию, так что даже на Windows, если надо скачать и установить программу, то это совсем не то же самое, как в браузере открыть ссылку, и уже вот оно появилось. Как если было мало проблем с кроссплатформенностью desktop+mobile, теперь стала актуальна кроссплатформенность desktop+mobile+web.

И web оказался таким тонким игольным ушком, через которое чуть менее, чем все, старые технологии, не пролезли. Новый стандарт кроссплатформенности практически всегда значит, что нужно сделать web-приложение, а потом это web-приложение заворачивается в браузер Electron, и вот это типа родное приложение теперь считается. А на так называемых мобильных платформах это был PhoneGap (Cordova). Ну, в общем, везде всё свелось к браузеру, обычному или завуалированному.

Так смешно сейчас вспоминать сравнение wxWidgets и Gtk+ на макосе. Так смешно вспоминать неудовольствие от нашествия мобильных платформ. Когда казалось, что достигли дна, снизу постучали. Вам Qt казался марсианской едой, нос воротили, не хочу, не буду, вам mobile казался новым неприветливым миром, а нате-ка попробуйте теперь draw.io на HTML5. Устанавливаем типа-родное приложение из Microsoft Store, а там опять двадцать пять приложение-в-браузере. Какую программу ни возьми, в ней нельзя открыть много окон. В Windows 10 старались, разделение экрана программировали, а в приложении-в-браузере ничего невозможно разделить, потому что тупо чаты нельзя открыть в разных окнах.

Выводы

Выражать неудовольствие неконструктивно. Ничего не поделать, надо подстраиваться. Надо философски прокачать эту тему.

Сейчас, если начинать какой-то проект, он с первого дня должен как-то поддерживать web. Можно говорить про прошлые технологии, что они оказались не готовы к таким драматичным изменениям, но, глядя на произошедшее, уж в новой-то технологии надо с первого дня закладывать поддержку web. Но, чтобы не хотелось плеваться от получающихся программ, можно заложить правильную кроссплатформенность.

Кроссплатформенность курильщика, — это сделать всё на технологиях web, а потом для desktop и mobile упаковать web в браузеры.

Кроссплатформенность здорового человека, — это сделать, чтобы в web можно было раздельно компилировать, но чтобы это не происходило в ущерб родным раздельно скомпилированными версиям программ. Через web должно быть можно подразнить и заманить в родную нормальную программу. А если не получилось заманить, то хотя бы как-то там, в web, отработать, в рамках тех ограничений, в которых существуют web-приложения.

Проект транслятора WebAssembly начался как spin-off другого проекта, Objective PE. Не вдаваясь в подробности, Objective PE про динамически загружаемые библиотеки и про переносимое GUI. Так вот, чтобы не оказаться шахматой, выброшенной с доски, потребовалось выработать какое-то решение по web, и это решение, — кроссплатформенность здорового человека. Это транслятор WebAssembly, конгруэнтный обычным платформам.

Четыре попытки асинхронизировать WebAssembly

OCTAGRAM — Wed, 24 Apr 2024 21:48:52 GMT

На многие устройства портировали NetBSD и программы для неё. На цифровом телефоне GrandStream GXV-3140 попадался портированный Pidgin. На ТВ-приставках с Venus Linux и роутерах с OpenWrt портировали много программ. WebAssembly похож на встраиваемые устройства, и всё же он остался непокорённый.

$CUT$

Корни JavaScript

Исходный текст для обычных устройств отличается от того, что требуется для WebAssembly. Когда WebAssembly работает в браузере, он подвержен всё тем же ограничениям, что и программы для браузера. Необходимо постоянно возвращать управление наружу.

Проблема двухцветности

В мире JavaScript происходила эволюция: CPS, deferred, promise, async/await. И пользоваться этим по-прежнему неудобно. async/await порождает проблему двухцветности: нужно отслеживать, какие функции могут быть асинхронные, и либо асинхронность разрастается, перекрашивает всё в свой цвет, либо асинхронность упирается в барьер синхронного интерфейса. Тяжело обращаться с двумя цветами. Также с точки зрения разных цветов есть отличия даже в стандартных классах. Например, у массива Array есть метод forEach, но он сам синхронный, и он ожидает на вход синхронную функцию. Стандартного асинхронного аналога нет. Под аналогом следует понимать метод массива, который вызовет обработку каждого элемента, дожидаясь обработки прошлого.

Странный параллельный запуск

Можно пойти другим путём. Можно запустить обработку элементов параллельно, а потом дожидаться результатов. Такого готового асинхронного метода тоже нет, а наивная попытка написать вскрывает ещё странные особенности асинхронных функций. Вызовы асинхронных функций интуитивно воспринимаются как запуск в другом потоке, но на самом деле они могут выполнить множество операций перед тем, как заснуть и вернуть обещание.

Специфика WebAssembly

В-принципе, можно пытаться повторять тот же путь, что и в JavaScript, и дойти до async/await и всех проблем с ними. Но посмотрим, что пробовали ещё.

Интерпретатор

Очень популярное решение в подобных ситуациях: заменять асинхронный участок кода интерпретируемым. В EmScripten это называлось Emterpreter. Недостаток: замедление в 10 раз и большие проблемы с двухцветностью. Сейчас эта возможность устаревшая.

WARNING: The Emterpreter was removed in emscripten 1.39.17. For details, see the changelog.

Asyncify

Другой попыткой в EmScripten был режим asyncify. Во всех возможных точках останова делались дубликаты функций, в которые можно и продолжить с этой точки. Это, по идее, должно быть максимально быстро, но это приводило к чрезмерному разрастанию кода, который можно продолжить со всех возможных точек останова. Эту возможность объявили устаревшей ещё раньше, чем Emterpreter.

ASYNCIFY has a bad worst-case of large code size: If it needs to modify many methods, it can grow code size very significantly (even 10x more was seen).

Типизированные продолжения

В 2020м было добавлено предложение добавить в WebAssembly типизированные продолжения. Пока не принято, то есть, в браузерах не доступно и, может быть, не будет доступно.

JavaScript Promise Integration (JSPI)

Другой попыткой было сохранение стека WebAssembly за кулисами при попытке взаимодействовать с асинхронным кодом JavaScript. Это было реализовано в одном из браузеров, но требует включения экспериментальных возможностей. Возможно, это так и не будет принято. Также при использовании этой возможности наложены довольно жёсткие ограничения на размер стека, который может быть сохранён на будущее.

Ещё одна попытка

Последнее слово ещё не сказано. Автор видит перспективным идти не по пути CPS и его вариаций вплоть до async/await, а по пути батутизации (trampolined style). Разница: в CPS вызов преобразуется в вызов, и возврат тоже преобразуется в вызов. При батутизации вызов превращается в возврат, и возврат тоже воплощён через возврат. Для исполнения батутизированного кода нужен рантайм, нужен батут, но вот эта комбинация из батута и батут-преобразованного кода и является, по мнению автора, лучшим решением. Автор ставит цель написать транслятор языка Си в WebAssembly с батут-преобразованием. В отличие от Asyncify, оно 1:1, и размер кода не раздувается. Батут похож на интерпретатор, но не замедлен в 10 раз. Ожидаемое замедление в 3 раза, но в обмен на это свобода писать в удобном синхронном стиле и не решать проблемы двухцветности. Такой транслятор должен быть наиболее похож на трансляторы для обычных платформ. Из одних исходников должно быть возможно компилировать для обычных платформ обычными трансляторами, и этим новым транслятором для WebAssembly, по возможности, без необходимости подстраиваться под особенности браузера.

Книга Дракона не очень?

OCTAGRAM — Mon, 08 Apr 2024 07:22:55 GMT

Редактор Софтпанорамы Н.Н. Безруков про книгу Дракона:

Compiler construction (see also my page with the collection of links) stopped to be a black art approximately after publishing of famous David Gries' book. Now it's a pretty established field but the truth is that there are few good books on the topic. Widely praised Compilers Principles, Techniques, and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman is in my opinion a weak book that stresses too much syntax parsing and more obscures then enlighten the design of compiler. In other words the Dragon Book is way overhyped. It is confusing and a complete nightmare to understand, especially for students. It actually kills interest to compiler writing instead of enhancing it. the authors have penchant to use useless formalisms ("art for the sake of the art"). It have some value for instructors but almost none for students.

А что он рекомендует для разработки трансляторов?

$CUT$

One of the most underestimated books on compliers is probably the first volume of The Art Of Computer Programming, the book that should be on the shelf of any complier writer. Algorithms described in this book, especially coroutines and those related to the trees, as well as MIX assembler are useful examples that any compiler writer can use. Generally a book with a complete code of a simple compiler is a good start as theoretical methods exposed in books like Compilers Principles, Techniques, and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman at the beginning looks incomprehensible and at end are not that practical. Paradoxically only after a while own compiler or interpreter one starts to understand how primitive thinking all those "theorists" have about this complex subject and how far detached they are from reality in their writings. In this sense, for a practitioner of the field, sound skepticism toward those "pseudo theories" make perfect sense :-).

At the same time compliers are very interesting, fascinating area, and on abstract level the methods used for their writing are essentially higher level programming paradigm which can be called language-oriented programming

Wasm, — это новый DOS

OCTAGRAM — Sun, 07 Apr 2024 23:54:15 GMT

Массовое распространение клонов IBM PC привело к резкому увеличению количества людей, активно занимающихся программированием на компьютере, а следовательно, и прослойки компьютерных "фанатов". Если раньше этот тип людей встречался в основном в университетских городках и больших вычислительных центрах, то с распространением клонов IBM PC ситуация существенно изменилась. Обладателями мощных и в то же время дешёвых компьютеров стали школьники, пенсионеры, а также другие лица, располагавшие, помимо желания попробовать свои силы в программировании, еще и значительным количеством свободного времени.

Как и в других областях человеческой деятельности, спектр отношения людей к программированию и вычислительным машинам очень широк: от ненависти, через полное безразличие до патологической привязанности или зависимости, которую можно квалифицировать как манию. Всякий работавший в вычислительном центре на больших ЭВМ и видевший, как к концу второй смены некоторые программисты наспех вносят плохо продуманные изменения в свои программы и умоляют электронщиков дать еще минутку, чтобы посмотреть, что получится, узнает сцену, описанную Ф.М.Достоевским в романе "Игрок":

$CUT$

"В одиннадцатом часу у игорных столов остаются настоящие, отчаянные игроки, для которых на водах существует только одна рулетка, которые и приехали для нее одной, которые плохо замечают, что вокруг них происходит, и ничем не интересуются весь сезон, а только играют с утра до ночи и готовы были бы играть, пожалуй, и всю ночь до рассвета, если б можно было. И всегда они с досадой расходятся, когда в двенадцать часов закрывают рулетку. И когда старший крупер перед закрытием рулетки около двенадцати часов, возглашает: "Les trois derniers coups, messieurs!" (Три последних игры (букв.: удара), господа - прим. перев.), то они готовы иногда проставить на этих трех последних ударах все, что у них есть в кармане, - и действительно тут-то наиболее и проигрываются" [Полн. собр. соч. в 30-ти томах. - Л.: Наука, т.5, 1973, c.292].

Снимок экрана из игры TIS-100 от Zachtronics. Цитата из главы 1.2.1. «Хакеры» из книги Н.Н. Безрукова «Компьютерная вирусология». Книга вышла в 1991м году и ещё передаёт дух невероятной экзальтации той эпохи. Также Н.Н. Безруков, редактор Софтпанорамы, рекомендует книгу Hard drive: Bill Gates and the making of the Microsoft empire.

Второй раз в реку

Увы, эпоха ушла. Запрещают везде доступы. Блокируют чужой код цифровой подписью. Наверное, правильно делают. Но куда теперь податься хакерам. Как войти в эту реку второй раз?

Для этого надо проанализировать, а что делало эту реку такой?

Прозрачность

DOS был примечателен тем, что не утаивал от программиста подробности реализации. Всё в системе было как на ладони. Особенно, когда появились отладчики вроде AVPUTIL. Всю память реального режима можно посмотреть. В отладчике можно по инструкциям походить, посмотреть, как это всё работает. И, посмотрев, сделать и своё.

Пространство для мастерства

Разрабатывать под DOS было непросто, но у кого получалось, те получали признание.

Например, FoxPro был движком баз данных в формате dbf, и средой разработки со своим языком программирования. Управление базами данных в DOS требовало мастерского обращения со всевозможными типами расширенной памяти (UMB, HMA, EMS, XMS) и выгрузкой на диск. Расширенная память так устроена, что в каждый момент времени программы видят не всю выделенную память, а только лишь окна. Окна можно переключать, чтоб отображали разные участки памяти. Для работы с этими сущностями в FoxPro применяются аналоги указателей, и всё это за несколько лет до того, как обобщения указателей начали появляться в C++ (перегрузка operator *).

Отдельный разговор можно посвятить тому, как управляться с видеокартой. Это касается и графических режимов, и текстовых. В текстовых режимах компьютер работал заметно побыстрее, но ведь так хотелось немного красоты. Так что программисты перепрограммировали шрифт и придавали особый вид своим программам. Это MS-DOS Shell, Norton Utilities, ASPLoader, Acronis OS Selector.

С появлением защищённого режима жизнь программистов стала проще не во всём. В DPMI (DOS Protected Mode Interface) основным режимом по-прежнему является реальный. То есть, чтобы записать на диск или прочитать с диска, или провзаимодействовать с мышью, нужно постоянно выходить из защищённого режима обратно в реальный. Для этих взаимодействий в DPMI предусмотрено API создания двусторонних переходов. Можно выделять новые заглушки. Это ресурс, а ресурсами надо управлять. Где есть выделение, там нужно и освобождение.

Широкая аудитория

И последняя вишенка на торте. То, что сделал программист, было, кому посмотреть. Ведь так-то и сейчас хватает любителей даунгрейда. Но понятно, что нас мало, и мы кто в лес, кто по дрова. Кому-то дорога эпоха DOS, у кого-то навсегда Windows 98, а у кого-то Windows XP, QIP и ICQ. В настоящую эпоху DOS ведь всё было не так. У всех было примерно одно и то же, и даже между DOS и Windows 9x разница была ещё не столь велика. В Windows 9x можно было создать такой ярлык (pif) программы, который перезагрузит компьютер в эту программу в чистом DOS. Только с Windows Millenium, 2000 и XP начал ломаться привычный мир.

То, что сделал программист, было практически единственным способом это сделать. Ну, то есть, если сейчас писать под DOSBox, то можно ведь и без DOSBox сделать то же самое, но лучше. А тогда DOS был практически всем. Практически абсолютом.

Новая река

Широкая аудитория

По указанным трём критериям на роль нового захода в реку внезапно хорошо начинает подходить WebAssembly. Среди любителей даунгрейда есть мнение, что новый DOS — это UEFI. То, что в современных компьютерах вместо BIOS. Ведь там можно запускать exe, там есть UEFI Shell. Под UEFI написали тетрис и файловый менеджер. Да, это впечатляет, но это слишком прямая аналогия. Среди проанализированных пунктов выше хромает по части «Широкая аудитория». Многие ли станут перезагружать свой компьютер в чистую среду UEFI? Да даже в виртуальную машину загрузить не хочется. Не правда ли.

В этом выгодное отличие WebAssembly. Он теперь есть в каждом браузере. Сможешь его покорить? Иди и возьми его. В маркетинге есть правило, что каждое лишнее действие уменьшает конверсию, а в WebAssembly с этим всё максимально хорошо. Поставь на любую страницу, если есть, что поставить.

Прозрачность

WebAssembly не позволяет вглядеться, что происходит в недрах браузера, но то, что происходит в самом WebAssembly, так же прозрачно, как это было в DOS. Ну, примерно. Полной аналогии, конечно, нет, но нам хватит. Больше всего не хватает, что чужие программы не в WebAssembly, они-то чаще всего в JavaScript. С другой стороны, довольно часто встроенным отладчиком браузера можно изучать и чужой JavaScript тоже.

В отличие от DOS, в WebAssembly придётся самим себя развлекать, самим наполнять и память Wasm.Memory, и другие ресурсы Wasm.

Пространство для мастерства

А вот с этим полный порядок. В DOS DPMI было управление замыканиями для перехода между реальным режимом и защищённым. В WebAssembly системному программисту полно развлечений для связи WebAssembly и JavaScript, а без JavaScript не получится взаимодействовать с браузером. JavaScript играет роль как бы реального режима в DPMI. То, куда надо выходить, чтобы взаимодействовать с окружающей действительностью.

Но особенное мастерство требуется в организации передачи управления. WebAssembly встроен в браузер и наследует его ограничения. Принципиальное ограничение, — нельзя долго исполнять код. В достаточно обозримое время нужно возвращать управление на самый верх. Управление внутрь WebAssembly попадает только из JavaScript, так что надо полностью выходить наверх из WebAssembly, и дальше выходить из JavaScript тоже, передавая управление в сам браузер.

Можно, например, отправить данные по WebSockets, но чтобы получить ответ, надо повесить обработчик событий и полностью выйти. И так много, где. Это вызов!

Это пространство для мастерства даже больше, чем в DOS. Это такое пространство для мастерства, как при разработке новой операционной системы во времена, когда люди активно экспериментировали с ними. Ещё в 2000е было нормально практиковать мультизагрузку операционных систем. Попробовать у себя Linux или другую операционную систему.

В новой операционной системе для WebAssembly вместо прерываний события браузера. Это и таймер (window.setTimer, window.setTimeout), и весь UI.

Советская Java

OCTAGRAM — Sun, 07 Apr 2024 21:11:25 GMT

Любопытные вещи можно вычитать в материалах Рабочей группы по реализации языков программирования (РГ РЯП).

Одним из основных вопросов докладов и дискуссий был вопрос уровня языка. Отмечалось, что разработка больших и сложноорганизованных программ на языках низкого уровня увеличивает возможность появления ошибок в программах и затрудняет их обнаружение и исправление. Это приводит к затяжке сроков разработки, снижению надёжности программного продукта и затрудняет его сопровождение.

…

Семинар отметил, с одной стороны, необходимость широкого внедрения существующих АРМ разработчика программного обеспечения типа АРМ2-05 с языками ассемблерного типа, кросс-систем, настраиваемых на устройства МПТ, и, с другой стороны, перспективность и необходимость расширения области применения языков типа ЯВА с заменой ими фирменных ассемблеров.

$CUT$

Звучит свежо? Свежо как свежесть 1996го года в США. Вот только действие происходит в 1983м году в СССР. Удивительно, но факт. У нас заранее случайно выбрали такое же название. В Советском Союзе это не остров, на котором выращивают кофе. В Советском Союзе это аббревиатура:

Язык Вместо Ассемблера

Кое-что про советскую Java можно найти почитать в архиве академика А.П. Ершова.

Сравнение WebAssembly и Portable Executable (dll)

OCTAGRAM — Thu, 21 Mar 2024 19:53:41 GMT

Программисты хорошо знакомы с Portable Executable, форматом исполняемых файлов для Windows. WebAssembly сулит все те же возможности, что и PE, в браузере. Но у них разный путь становления, что привело к фундаментальным различиям. Различия можно отчасти сгладить, и всё же придётся иметь их ввиду.

$CUT$

Память

Модули Portable Executable имеют доступ к единому адресному пространству процесса. Модули WebAssembly должны импортировать или экспортировать блок памяти. Впрочем, могут не пользоваться массивной памятью или же пользоваться встроенной памятью, но не экспортировать наружу. Модуль Wasm, экспортирующий блок памяти, похож на PE exe: exe является точкой роста, он определяет содержимое своей памяти, а все остальные модули (PE dll) входят в виртуальное адресное адресное пространство, определённое PE exe. В частности, это проявляется в том, что до недавних усилий по повышению безопасности многие PE exe нельзя было перебазировать из-за отсутствия релокаций.

Наиболее гибкие модули WebAssembly, импортирующие блок памяти Wasm.Memory, и они похожи на PE dll. Из-за ограничений WebAssembly имеет смысл и аналоги exe делать в виде модулей Wasm с импортом памяти. Потому что хотя exe и первый определяет виртуальную память, но запуск exe требует подключения всех dll, и только после подключения dll запускается исполнение exe, и воспроизведение такого поведения в Wasm всё же требует, чтобы Wasm.Memory импортировался.

Прямая связь модулей

Однако если можно почти любую PE dll брать и подключать в программу, объявив, конечно, внешние функции, то из-за особенностей WebAssembly нельзя того же утверждать про произвольные модули WebAssembly. В HTML5 практически сложно назвать что-то главной программой, так что там не должно быть аналогов PE exe, и всё же модули Wasm часто устроены таким способом, который не подходит для загрузки их как dll в общую память, в том числе из-за неправильного подключения Wasm.Memory. Про WebAssembly можно утверждать, что модули WebAssembly заворачиваются в интерфейс для работы с ними из JavaScript, но не гарантируется прямая связь WebAssembly-WebAssembly аналогично прямой связи dll-dll или exe-dll в Portable Executable. Без специальных усилий со стороны инструментов разработки вместо WebAssembly-WebAssembly можно получить: WebAssembly-JavaScript-WebAssembly.

Подключение модулей

Portable Executable содержит указания, по каким именам загружать dll. Такие файлы или ресурсы, как config и manifest, могут ещё немного скорректировать места поиска dll. Таким образом, запуск exe или LoadLibrary для dll позволяют загрузить программу или библиотеку со всеми их зависимостями автоматически. В среде браузера это более сложный процесс, и сложность перекладывается на плечи программиста. В частности, в обычном окружении браузера нельзя или крайне нежелательно делать синхронную загрузку файла (в WebWorker можно). Из-за этого сложность загрузки перекладывается на плечи программиста таким образом, что инстанциация модуля WebAssembly требует предоставления его подключенных библиотек в уже инстанциированном виде. А для этого нужно было библиотеки уже как-то рекурсивно найти и асинхронно загрузить. Этот дополнительный код пишется разработчиками трансляторов, и пишется по-разному.

Положительные стороны WebAssembly

В Portable Executable большую популярность получили структуры данных со ссылками на виртуальные адреса. Как само собой разумеющееся предполагается, что PE exe или dll загружен с диска в память, и тогда обходить эти структуры данных становится посильной задачей. Но менять многое невозможно надёжно, либо избыточно сложно. Например, было непросто написать такую программу, как ResHacker. У WebAssembly формат файлов лучше типизирован, с ним удобнее работать в исходном (файловом) виде.

Итог

Компилировать WebAssembly можно так, чтобы они были похожи на Portable Executable dll, но от сторонних разработчиков не приходится ожидать, чтобы они так компилировали.

WebAssembly устроен как конструктор сделай-сам. А сделать самому можно по-разному. Не каждый программист занимается таким конструированием, но разработчики разных трансляторов делают свои воплощения, отличающиеся в подходах. Компилировать WebAssembly как Portable Executable dll теоретически можно, но чужие скомпилированные wasm не работают как dll. И если какой-то новый транслятор заявляет поддержку WebAssembly, то вовсе не обязательно продукты его трансляции получится загружать и вызывать удобно как dll.

Отчасти различия в инструментариях призваны сгладить спецификации WebAssembly Tool Conventions

WebAssembly тяжелее ассемблера

OCTAGRAM — Wed, 20 Mar 2024 18:03:02 GMT

Ура, свершилось? Прямой доступ к машинным кодам прямо из браузера?

Нет, не совсем так. Простые компилируемые в машинные коды программы на таких языках, как Ada и Delphi, всё ещё остаются шустрее. И вот, почему.

$CUT$

Память

Память WebAssembly, — это массив байт ограниченного размера с возможностью роста, плюс набор переменных модулей, вклад которых незначителен. Память настоящей программы, — это виртуальная память большого размера, например, 2Гб.

Сегменты данных

Чтобы загрузить модуль WebAssembly со встроенным блоком памяти, надо скопировать все байты в массив памяти WebAssembly. Если открыть несколько вкладок одного сайта, в каждой вкладке загрузится своя копия всех блоков памяти WebAssembly (если только не прибегать к ухищрениям с opener, тянущим на кандидатскую). Чтоб загрузить исполняемый или динамический модуль обычной программы, надо спроецировать страницы памяти с диска в виртуальную память. Пока страницы памяти не потребуются, их можно даже не грузить. Можно прочитать в оперативную память и разделить между всеми экземплярами программы. Или между всеми программами, загрузившими одну и ту же динамическую библиотеку. Можно спроецировать страницы памяти в режиме только для чтения, для констант, и тогда такие страницы точно общие. Можно спроецировать страницы памяти в режиме копирования при записи. Пока ничего не изменилось, страницы памяти общие для нескольких программ. Для WebAssembly эти прелести виртуальной памяти недоступны.

Стеки

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

Исполняемый код

Модули WebAssembly на самом деле не в машинных кодах, а чтобы их перевести, требуется время при каждой загрузке. Время можно экономить, если положиться на кеширование машинных кодов, но для этого нужно загружать чётко определённым образом, и уже не все возможности WebAssembly легко доступны.

Обычные программы уже в машинных кодах, и их код проецируется страницами в виртуальную память.

Косвенные вызовы

Обычной программе почти ничего не стоит ссылаться на любые свои байты, в том числе на адреса функций. В WebAssembly каждая функция, которую можно вызвать косвенно, занимает место в массиве косвенно вызываемых функций. И, например, при загрузке динамической библиотеки требуется копировать новые функции в общий массив. Чем их больше, тем дольше обработка.

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

В некоторых компиляторах для простоты индексы общие. То есть, массивов много, но в большинстве массивов заглушка с ошибкой, и только в тех ячейках, где совпадение сигнатуры, настоящая ссылка на косвенно вызываемую функцию. Но тогда нужно обслуживать несколько преимущественно пустых массивов. Либо можно все массивы компактифицировать, но тогда весьма усложняются релокации.

Релокации

Релокация, — это загрузка модуля, обычно динамической библиотеки, по её «не основному» базовому адресу. У обычной программы это хорошо поддержанная операция. Надо производить смещение всего лишь по одному базовому адресу, ведь код и данные двигаются синхронно. В некоторых операционных системах имеется система кеширования перебазированных библиотек, так что их можно подгружать, проецируя страницы с диска.

В WebAssembly релокации производятся как минимум по двум «адресам». Это собственно адрес сегмента данных в памяти WebAssembly, и также начальный индекс косвенно вызываемых функций. А если применяется компактное выделение массивов функций разной сигнатуры, то сколько сигнатур, столько и дополнительных базовых адресов релокаций.

Многопоточность

Обычные программы достаточно непринуждённо могут запускать несколько потоков. Программы на WebAssembly для подлинной многопоточности должны использовать такой инструмент, как Worker, и передать экземплярам массив Wasm.Memory, созданный с флагом shared: true. Использование этого флага требует ограничить сверху максимально доступную память, чего не происходит в обычных программах.

Также начинаются довольно весёлые проблемы с динамической загрузкой библиотек. Разные Worker друг от друга изолированы. Да, они могут обменяться сообщениями между собой и с Window, чтобы обрести общую Wasm.Memory, но программа на этом не заканчивается. Кроме данных ещё нужен исполняемый код, а он у каждого Worker свой. Чтобы создать иллюзию обычной многопоточной программы, нужно в каждом Worker одинаковым образом грузить все модули, и чтобы у них у всех было одинаковое видение всех релокаций.

Гипотетически модули могут быть заменены на сервере прямо в тот момент, когда Worker их пытается грузить, и у Worker загрузится своя версия модуля. Чтобы с этим бороться, можно сами загруженные WebAssembly сохранять как Blob и передавать в Worker, чтобы точно загрузилось то, что нужно. Но такие усложнения часто ведут к тому, что ломается стандартное кеширование исполняемого кода. Куда ни кинь, всюду клин.

Итог

Компилировать обычные программы по-прежнему имеет смысл. Разрыв между обычными программами и WebAssembly по использованию ресурсов велик, и трудно представить, чтобы он был сокращён. Архитектуру WebAssembly ещё требуется радикально поменять, и всё равно она останется далеко позади.

Из-за сложностей поддержки динамических библиотек компиляторы часто создают замкнутые на себя статические модули, не раскрывающие потенциал ни обычных разделяемых библиотек, ни даже WebAssembly.

Тем не менее, поддержка WebAssembly имеет важный смысл. Чем меньше кликов, тем выше конверсия. WebAssembly нужен для «малокликабельных» версий программы. Для того, чтобы заманить скачать полноценную быструю версию программы.

У JavaScript-«программ» преимущества устанавливаемых версий просматриваются с большим трудом. Программы для WebAssembly можно так переносимо писать, что у них будут быстрые родные версии, не требующие встроенного браузера.