H.J. Lu анонсирует x32-abi

>> А смысл? Ядро-то все равно обычное amd64, и для него нужна полная поддержка amd64, так что в проце ничего сократить не получится.

А ядро ты соберешь с -mx32 тоже и оно будет такое же, как эти бинарники.

То есть вы предлагаете писать целую новую архитектуру ядра? Желаю удачи в уговаривании Линуса.

Ну аналогично же :)

Отдайте оптимизатору следить за тем какие указатели можно укорачивать а какие нет.

PS: Какой профит от одного укороченного указателя на память ?

Для профита их должны быть миллионы и они должны жить в кеше :)

PPS: По диагонали просмотрел ветку на LKML. Cоздалось впечатление что аффтар просто желает создать некий несовместимый ни с чем ABI для использования на мобильных атомных девайсах :)
А упоминание аффтара на bionic как бы намекает на платформу :)

PPPS: subj «не нужен» (С) :)

Алан в данном случае выступает против введения новых сисколов которые являются one of the most security critical areas

я же говорю о потенциальных переполнениях которые могут быть с ними связаны... так понятнее ?

> Скажите, есть ли смысл (какие плюшки можно получить или гемор подцепить...) ставить ядро для x86_64 на 32х битный пингвин? Памяти 8г, перегнать саму ОС на x86_64 пока нет возможности.

Если это сервак, то работать должно быстрее, главным образом благодаря неиспользованию PAE и CONFIG_HIGHMEM(64|4)G.

Если это десктоп, то, возможно, будут проблемы между 64битным DRM и 32битными DDX и mesa. А может и не будут, хз. Вообще, теоретически наверное возможны и другие проблемы такого рода, даже и в случае сервака. Но, по крайней мере Debian включило в состав 32битного i386 64битные ядра, так что по крайней мере кто-то это использует.

Как-то так.

> Ну аналогично же :)

Отдайте оптимизатору следить за тем какие указатели можно укорачивать а какие нет.

А, то есть вы предлагаете чтобы часть указателей была 32битными, а часть 64битными? Это уже даже не новый API, это попахивает новым стандартом ISO C. :-O И, да, а какой длины у вас будет long? Как известно, когда sizeof(void *)!=sizeof(long), можно отхватить много замечательного геморроя при портировании софта.

PS: Какой профит от одного укороченного указателя на память ?

Для профита их должны быть миллионы и они должны жить в кеше :)

Я даже больше скажу, если вы не хотите изобретать новый язык вместо C, то *все* указатели должны быть укороченными.

PPS: По диагонали просмотрел ветку на LKML. Cоздалось впечатление что аффтар просто желает создать некий несовместимый ни с чем ABI для использования на мобильных атомных девайсах :) А упоминание аффтара на bionic как бы намекает на платформу :)

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

PPPS: subj «не нужен» (С) :)

Даже если он не нужен вам, не значит, что он не нужен никому.

> Алан в данном случае выступает против введения новых сисколов которые являются one of the most security critical areas

я же говорю о потенциальных переполнениях которые могут быть с ними связаны... так понятнее ?

Непонятно другое, зачем было цитировать Кокса как бы в подтверждение вашего тезиса о переполнении? Я же вам ответил, что никаких проблем с переполнением нет, а вы попытались туда Кокса притянуть. А слабо самому, без Коксовой помощи, объяснить какие конкретно проблемы могут быть с переполнением?

так было же это всё :)

В DOS указатели могли быть как длинными так и короткими (far и near)

Даже если он не нужен вам, не значит, что он не нужен никому.

Ну судя по LKML таких полтора человека пока :)

> Даже если он не нужен вам, не значит, что он не нужен никому.

А кому он может быть нужен? Мне вот приходит в голову только выпуск какой-нибудь встроеной дешевки с обрезанной шиной адреса, но пока таких планов никто не обнародовал.

Хотелось бы чего-то более общего. Типа скорости запуска фотошопа на бортовом навигаторе автомобиля :)

Узкоспецифичные штуки вроде числодробилок и разархиваторов - не то.

>Я же вам ответил, что никаких проблем с переполнением нет

Жжоте :)

[quote]
Гугл:
linux kernel overflow
Результатов: примерно 354 000
[/quote]


Пример чтобы далеко не ходить http://www.securityfocus.com/bid/33275

И лишний сискол (тем более для слабоподдерживаемого ABI) - потенциальная угроза безопасности

> так было же это всё :)

В DOS указатели могли быть как длинными так и короткими (far и near)

Нет, в DOS far и near указатели были *разными типами*, и было заранее известно, которого типа каждая переменная. А в предлагаемом вами случае, либо надо сразу объявлять значение, возвращаемое mmap длинным типом указателя, либо изобретать новый язык вместо си. В первом варианте будет аццкий геморрой с разными несовместимыми типами указателей, скорее всего больший, чем с новым ABI. И, да, введение двух разных типов указателей – это уже де-факто новый ABI, только гораздо более кривой, чем предлагаемый x32. А второй вариант я даже боюсь представлять.

Даже если он не нужен вам, не значит, что он не нужен никому.

Ну судя по LKML таких полтора человека пока :)

Я даже больше скажу, таких вообще ноль пока. Аффтары и сами не знают еще, нужен ли он им, и честно признаются в этом.

>Узкоспецифичные штуки вроде числодробилок и разархиваторов - не то.

Ну мне тоже много чего иногда хочется :)) А всё не то :)

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

Прикольно? Прикольно. Но проталкивать еще одну новую платформу сборки, без явных профитов для всех... гм...

Есть гораздо более эффективные способы оптимизации чем обрезание указателей :) Но речь шла о кеш-эффектах которых таки есть и немало.
Я просто привёл самый академический пример про который рассказывают всем студентам изучающим данную область

void *ptr = mmap(NULL, 424242, PROT_READ|PROT_WRITE,

MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);

И ядро вам раз, и возвращает, например, 0x42ffffffff.

Так, man mmap на тему MAP_32BIT :)
А между тем, Лю наконец дал чёткий ответ на вопрос «зачем»:
https://lkml.org/lkml/2011/2/13/161
Звучит ответ примерно так:
Если мы юзаем 32битное ABI, то вот вам, я его улучшил, так что
если всё равно собирались пользовать ia32 - тут вам и профит.
Если не юзаем - тогда и не надо.
То есть, это просто замена ia32, более оптимальная замена, но никак
не конкурент 64bit ABI.
Собственно, всё четко и ясно.
Кстати, мне до сих пор думается, что это позволит пользовать
32битные либы с 64битными прогами - кто опровергнет? :)

Вопрос: Что мешает оптимизирующему компилятору резать указатели если уж он умеет IPA/IPO ? :)

Ответ: Это никому не нужно, а уж новое ABI с такой фичей так это 100% :)

> Так, man mmap на тему MAP_32BIT :)

Чтоб я без вас делал... Вот только в shmat(2), например, такого флага нет. Что там прикажете делать? :-P

Кстати, мне до сих пор думается, что это позволит пользовать 32битные либы с 64битными прогами - кто опровергнет? :)

Конечно не позволит. В 64битной проге sizeof(long)==8. В x32 sizeof(long)==4. Бинарная несовместимость налицо.

>Кстати, мне до сих пор думается, что это позволит пользовать
32битные либы с 64битными прогами


Не толстоват ли будет nspluginwrapper ? :)))

> Вопрос: Что мешает оптимизирующему компилятору резать указатели если уж он умеет IPA/IPO ? :)

Таки давайте определимся как именно вы предлагаете это реализовать. Вы хотите ввести на уровне языка два класса указателей разной длины (которые будут разными типами), или нет?

Это всё хорошо (дополнительные регистры), но какой в них смысл, если предыдущие еще не осилили?

Или тогда приведите примеры ОС (именно ОС), например, 2010 года, использующей SSE, MMX и многозадачность в полном объёме.

>Таки давайте определимся как именно вы предлагаете это реализовать.

Это было в первом сообщении. С точки зрения языка нормальный такой 8-байтовый указатель а его реальная «обрезка» на уровне _оптимизации_

Но это шла речь именно о реализации данного виртуального «бонуса» :)
а по всему топику предложение было изначально «закопать» :)

Чтоб я без вас делал... Вот только в shmat(2), например, такого

флага нет. Что там прикажете делать? :-P

Не люблю SysV SHM, когда есть Posix SHM, но отвечу:
Там есть параметр shmaddr и флаг SHM_REMAP. Продолжать, или
идея ясна? :)

Конечно не позволит. В 64битной проге sizeof(long)==8. В x32

sizeof(long)==4. Бинарная несовместимость налицо.

Я имею ввиду, что 64битная прога будет собрана под psABI, в то
время как либа - ia32.

>Или тогда приведите примеры ОС (именно ОС), например, 2010 года, использующей SSE, MMX и многозадачность в полном объёме.


Вы чего там курите ? :)

>> Чтоб я без вас делал... Вот только в shmat(2), например, такого флага нет. Что там прикажете делать? :-P

Не люблю SysV SHM, когда есть Posix SHM,

А кто ж его любит...

но отвечу: Там есть параметр shmaddr и флаг SHM_REMAP. Продолжать, или идея ясна? :)

Проблема в том, что если вы запрещаете указывать NULL в shmaddr, то это уже новый API, а не POSIX. :)

Конечно не позволит. В 64битной проге sizeof(long)==8. В x32 sizeof(long)==4. Бинарная несовместимость налицо.

Я имею ввиду, что 64битная прога будет собрана под psABI, в то время как либа - ia32.

А, это интересный вопрос. Но думаю все равно не взлетит. Если замэпить ia32 бинарный код в 64битный сегмент, и запустить, то команды будут исполняться немного по другому :)

Проблема в том, что если вы запрещаете указывать NULL в shmaddr,

то это уже новый API, а не POSIX. :)

Я не запрещаю - это мог делать врапер сисколла.
В любом случае, есть персоналити ADDR_LIMIT_3GB - этого вам хватит
для счастья? :)

Если замэпить ia32 бинарный код в 64битный сегмент, и запустить,

то команды будут исполняться немного по другому :)

Я по тому и говорил, что потребуются доработки для ld.so, а именно,
он должен будет создать 2 сегмента, и отрезолвить функции на
«трамплины», которые будут делать длинный вызов, то есть с заменой CS.
Казалось бы, изменения тривиальные...

Тред не читал, спрашиваю тупой вопрос: на ядре с поддержкой этого можно запускать «нормальные» 64-битные бинарники, плюс эти, урезанные? Так?

Во блин нафлудили.

1. Эти перцы из интела замыслили коварную штуку. А конкретно они замыслили тупо вонзить в x86 архитектуру amd64 instruction set не меняя при этом более нихрена, в том числе и распиновку процессоров.

2. Интеля вывесят на каждом сортире рекламу, «упграде вашего говенного цылерона на православный 64битный процессор почти нахаляву, мамку выкидывать нинада, термопаста в подарок».

3. Лемминги начитавшись рекламы толпами пруцца в лабазы за «Ъ 64битностью нахаляву». Заяснять сколько там тру от этой 64битности никто в интеле ессно не собирается.

4. ?????

5. PROFIT

Вот и вся задумка.

Наркоман что ли?

Никто под это новых процов делать не собирается.

> угу, и linux как бесплатный полигон для очередной дури от Штеуд.))

Присоединяюсь. Пусть прекратят постоянно ломать видеодрайвера для старых чипов хотя бы.

>Не толстоват ли будет nspluginwrapper ? :)))

1) а оно вообще работает? та же ява-плагин?

2) а что делать с кодеками для мплайера?

3) а что делать с криптолибой (сошка) для банка-клиента на жабе, которая тоже сделана онли32бит?

Вот только нифига оное не заработает.

Вот только нифига оное не заработает.

И причиной тому является... ?

>2. для излечения профита из этой фичи достаточно будет с помошью модифицированного компилятора пересобрать уже заточенную под х64 программу, которую можно будет запускать под ядром с новым x32 ABI, точно также как сейчас можно запускать х86 под х64.

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

>> Проблема в том, что если вы запрещаете указывать NULL в shmaddr, то это уже новый API, а не POSIX. :)

Я не запрещаю - это мог делать врапер сисколла. В любом случае, есть персоналити ADDR_LIMIT_3GB - этого вам хватит для счастья? :)

ADDR_LIMIT_3GB или ADDR_LIMIT_32BIT?

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

Если замэпить ia32 бинарный код в 64битный сегмент, и запустить, то команды будут исполняться немного по другому :)

Я по тому и говорил, что потребуются доработки для ld.so, а именно, он должен будет создать 2 сегмента, и отрезолвить функции на «трамплины», которые будут делать длинный вызов, то есть с заменой CS. Казалось бы, изменения тривиальные...

Думаю, все равно не взлетит. Во-первых, кроме замены CS надо будет преобразовывать calling conventions, а для этого надо знать сигнатуры функций. Следующая проблема будет если длины и/или выравнивания типов будут не совпадать (правда Лю обещает, что такого не будет). А самый большой геморрой будет с разного рода callbacks. Простейший пример – atexit(3). Надежное отлавливание такого в общем случае – это AI-complete problem, IMHO.

Хотя, для некоторых частных случаев, когда заранее известны все функции, которые как-то могут участвовать в этом безобразии, может быть и реализуемо. Но скорее всего того не стоит.

ADDR_LIMIT_3GB или ADDR_LIMIT_32BIT?

Думаю, что первый больше подойдёт, так как в 32битном режиме
стандартный сплит был 3G/1G, и проги ожидают именно этого.
TASK_SIZE был задефайнен как 3Г.

В любом случае, чтобы бескосячно изменить длину некоторых

типов, надо менять ABI. Просто по определению.

Я уже не помню, что вы там с sS обсуждали, и почему надо менять
длину каких-то типов. Если есть желание - напомните. :)

Во-первых, кроме замены CS надо будет преобразовывать calling

conventions, а для этого надо знать сигнатуры функций.

В смысле? Поддержку в gcc добавляют, думаю, будет новый атрибут,
наравне с stdcall/cdecl.

А самый большой геморрой будет с разного рода callbacks.

Нда, тогда компилятору придётся помещать в начало каждой x32 функции
дальний вызов, чтобы сегмент всегда был верным. Согласен, не
слишком красиво, но 1 инструкцию добавить - мож не обломится? :)

> Я уже не помню, что вы там с sS обсуждали, и почему надо менять длину каких-то типов. Если есть желание - напомните. :)

Дело даже не в том, что мы там обсуждали, а в том, что некоторые утверждают, что если в amd64 заменить длину указателей и long с 64бит на 32, то будет выигрыш в производительности. Именно чтобы проверить этот тезис они и запиливают x32.

Во-первых, кроме замены CS надо будет преобразовывать calling conventions, а для этого надо знать сигнатуры функций.

В смысле? Поддержку в gcc добавляют, думаю, будет новый атрибут, наравне с stdcall/cdecl.

В смысле, что в i386 агрументы функций передаются через стек, если я правильно помню, а в amd64 (и в том числе и в x32) частично через регистры. Соответственно переходники должны будут перекладывать их из одного места в другое. А чтобы это правильно делать, переходник должен знать типы фактических аргументов. В случае с printf, например, это может быть непросто.

А самый большой геморрой будет с разного рода callbacks.

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

Не только, надо еще и преобразовывать calling convention, а для этого функция (ну или переходник) должна знать, откуда ее в данном случае вызвали – из родного кода, или нет.

Согласен, не слишком красиво, но 1 инструкцию добавить - мож не обломится? :)

Боюсь, не все так просто.

Дело даже не в том, что мы там обсуждали, а в том, что некоторые

утверждают, что если в amd64 заменить длину указателей и long с 64бит

на 32, то будет выигрыш в производительности. Именно чтобы проверить

этот тезис они и запиливают x32.

Это уже никто не утверждает, я выше приводил ссылку, привожу ещё раз:
https://lkml.org/lkml/2011/2/13/161
Всё, этот вопрос снят, объяснение дано, и оно убедительное.

Соответственно переходники должны будут перекладывать их из одного

места в другое.

Нет, речь идёт только о трамплинах для замены CS.
Вызывающая сторона знает, что вызываемая функция - x32 or ia32, и
аргументы подготовит соответственно. А вот CS она сама не подставит,
так как для этого ей надо точно знать, x32 это, или ia32. Для
аргументов - это не важно. А для подмены CS нужен простейший трамплин.

Не только, надо еще и преобразовывать calling convention

Это забота gcc, на _вызывающей стороне_.

откуда ее в данном случае вызвали – из родного кода, или нет.

Из родного кода её тоже будут вызывать как x32, естественно.
Так что разницы нет.

>Всё, этот вопрос снят, объяснение дано, и оно убедительное.

Там нет объяснения почему должно быть x32 а не x64 ;)

И в чём заключается «benefit of ia32» ...

а заключается сей бенифит (реально) в огромной кодовой базе для ia32 против кодовой базы x32 которая равна нулю а никак не в мифическом оверхеде x64

Там нет объяснения почему должно быть x32 а не x64 ;)

Там этого нет, по тому, что так и не должно быть.
x32 - эволюция ia32, её развитие и продолжение, и только то.
Она - не конкурент x64.

И в чём заключается «benefit of ia32» ...

Те, кто его ещё используют (если таковые имеются) - знают сами, зачем
он им. :) И вот для них дядька Лю и делает конфетку, и _только для них_.
Пользователи x64 могут не волноваться и покурить. :)

а заключается сей бенифит (реально) в огромной кодовой базе для ia32

против кодовой базы x32 которая равна нулю а никак не в мифическом

оверхеде x64

Как я понял, x32 - это drop-in replacement. То есть вся ваша гигантская
кодовая база ia32 должна просто быть перекомпилирована с другим
флажком, и продолжит работать без проблем, и даже в 1.01 раз быстрее,
вот и всё.

>То есть вся ваша гигантская
кодовая база ia32 должна просто быть перекомпилирована с другим
флажком, и продолжит работать без проблем, и даже в 1.01 раз быстрее, вот и всё.


Так полно-же всякой ia32 проприетрщины... вот тут кодеки уже вспоминали :)

Это уже никто не утверждает, я выше приводил ссылку, привожу ещё раз: https://lkml.org/lkml/2011/2/13/161 Всё, этот вопрос снят, объяснение дано, и оно убедительное.

Я тоже приводил сцылку, и тоже могу привести еще раз: «The target applications are an embedded (closed or mostly closed) environment, and the question is if the performance gain is worth it. It is an open question at this stage and we'll see what the numbers look like and, if it turns out to be worthwhile, what exactly the final implementation will look like.»

Соответственно переходники должны будут перекладывать их из одного места в другое.

Нет, речь идёт только о трамплинах для замены CS. Вызывающая сторона знает, что вызываемая функция - x32 or ia32, и аргументы подготовит соответственно. А вот CS она сама не подставит, так как для этого ей надо точно знать, x32 это, или ia32. Для аргументов - это не важно. А для подмены CS нужен простейший трамплин.

А, ну если вам интересен только этот частный случай, когда вызовы происходят только в одном направлении, из x32 программы в ia32 библиотеку, то возможно это и реализуемо. Но оно будет очень хрупким и ломаться от малейших изменений или непредвиденностей.

Не только, надо еще и преобразовывать calling convention

Это забота gcc, на _вызывающей стороне_.

О как. Ну хорошо, предположим, gcc видит такой код:

struct foo {
    int bar;
    void (*baz)();
};

int blarg(struct foo *quux) {
    quux->baz();
}

откуда ее в данном случае вызвали – из родного кода, или нет.

Из родного кода её тоже будут вызывать как x32, естественно. Так что разницы нет.

Я в данном случае говорил про callback, вызываемый из ia-32 библиотеки (например, зарегистрированный через atexit(3)). И библиотека естественно эту функцию будет вызывать по правилам ia-32, а не x32.

Так полно-же всякой ia32 проприетрщины... вот тут кодеки уже

вспоминали :)

Ну на это я пытаюсь развить дискуссию о возможности микса x32 и ia32,
и вроде всё должно работать, но от Луя такой инфы не было пока (хотя
очевидно, что инфу из него тока Алан Кокс может выдавить, и то по
капле :)

Я тоже приводил сцылку, и тоже могу привести еще раз:

А смысл? Насколько я знаю, не Анвин занимается этим ве.. этим проектом.
Я привел ссылку на господина Лю.

А, ну если вам интересен только этот частный

Ошибаетесь.

О как. Ну хорошо, предположим, gcc видит такой код:

Откуда он узнает, родная здесь вызывается функция, или нет?

- Если не указано явно, то родная. Соответственно, если он такое
объявление увидит в функции x32, то и к вашему указателю в структуре
отнесётся так же.
- Если хотите указывать явно, то что-нить вроде:
void __attribute__((x32decl)) (*baz)();
будет. Практика-то стандартная, благо, stdcall уже сто лет как есть,
и никто не жаловался.
Компилятор _обязан_ знать соглашение вызова, вне зависимости от
наличия в мире вещей типа x32. Обязан, всегда знал, и будет знать
дальше.

Я в данном случае говорил про callback, вызываемый из ia-32 библиотеки

И я вас правильно понял.

>>Или тогда приведите примеры ОС (именно ОС), например, 2010 года, использующей SSE, MMX и многозадачность в полном объёме.

Вы чего там курите ? :)

А что, linux уже можно собрать с включенной генерацией simd-интсрукций? Даже при использовании FPU нужно сохранять регистры явным образом.

>А что, linux уже можно собрать с включенной генерацией simd-интсрукций? Даже при использовании FPU нужно сохранять регистры явным образом.

У вас один поставщик травы ? :)

>> Я тоже приводил сцылку, и тоже могу привести еще раз:

А смысл? Насколько я знаю, не Анвин занимается этим ве.. этим проектом.

А насколько я понимаю, и Энвин тоже занимается этим проектом (вот он пишет: «It is an open question at this stage and *we*'ll see what the numbers look like» или «That's what we're doing, functionally.»). И он кстати тоже в интеле работает.

О как. Ну хорошо, предположим, gcc видит такой код: Откуда он узнает, родная здесь вызывается функция, или нет?

- Если не указано явно, то родная. Соответственно, если он такое объявление увидит в функции x32, то и к вашему указателю в структуре отнесётся так же.

А, то есть хотите все реально сложные в реализации вещи переложить на программера. Ну, тоже выход, конечно. Боюсь только программеры пошлют вас вместе с вашей инициативой, и предпочтут использовать нэйтивные x32 библиотеки. Тем более они еще и эффективней, чем ia-32'шные будут.

А самый большой геморрой будет с разного рода callbacks.

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

Не только, надо еще и преобразовывать calling convention, а для этого функция (ну или переходник) должна знать, откуда ее в данном случае вызвали – из родного кода, или нет.

Из родного кода её тоже будут вызывать как x32, естественно.

Я в данном случае говорил про callback, вызываемый из ia-32 библиотеки (например, зарегистрированный через atexit(3)). И библиотека естественно эту функцию будет вызывать по правилам ia-32, а не x32.

И я вас правильно понял.

O'RLY? Что же вы тогда путаетесь в показаниях и говорите, что ее вызывают как x32?

> - Если хотите указывать явно, то что-нить вроде: void __attribute__((x32decl)) (*baz)();

И, да, есть мнение, что синтаксически правильнее void (__attribute__((x32decl)) *baz)(); потому что атрибут относится к функции, а не к ее возвращаемому типу.

1) Все таже необходимость перекомпиляции.

2) все теже несовместимости в типах данных. Или инты будут 32 бита и будут несовместимы с 64 битами или 64 бита и не будут пересобираться в новой архитектуре без правки исходников.

Собственно, в плане совместимости вообще ничего не изменится.

На фоне Вашей общей олдскульной дури - даже неудивительно, что амигу обожествили аж в 80-х.

> Ага, счас. Весь софт собирается чуть больше чем одним компилятором и ассемблерные вставки в программах придётся переделывать не один день а может и год. Соберут ось с репозиторием состоящим из косынки с мозилой - пользуйтесь клиенты дорогие!

Херня полная, асм-код нагенерят из абстрактных описей за полторы секунды PT, сплошь на парсерах и перле.

Дорогой мой клиент, с пип-шоу и частниками-визуалами.