Старое обсуждение:Ассемблер

---

Внимание! Это старая дискуссия, которая некогда велась на сайте Луркоморье. Пожалуйста, для продолжения обратитесь к актуальной: Обсуждение:Ассемблер, которая проводится в стиле пленарного заседания.

---

Программы на ассемблере

В статью добавлять не буду - русского языка на знаю, будет смешно. Но вот некоторые живые проекты только на ассемблере:

http://fresh.flatassembler.net - IDE для написания больших проектов на ассемблере. Само IDE на ассемблере и CMS сайта на ассемблере. Хостинг на web сервер RWASA, которой также написан на ассемблере: https://2ton.com.au/rwasa/ http://board.asm32.info - Форум софт на ассемблере. С FastCGI и SQLite.

Self-descriptive

「SELF-DESCRIPTIVE」(自己記述的)にしなければなりません。 Статью надо сделать Self-descriptive, как про Питон и другие языки.

DO IT FAGGOT!

8051

Попрошу упомянуть в вашем высере коллега о следующей удне: была у меня задача, накорябать на ассемблере прогу управления свистелкой построенной на основе былинного 8051-го процика. До этого ни с первым не со вторым не сталкивался, писал на ANSI C и в уд не дул, думал какнить разберусь - ибо времяни было отведено не много ни мало полтора года блиать. И что вы думаете ? Таки все полтора года сурово на эту удню и угрохал, верхом всего было вот что: как оказалось в последствии на ассемблере для 8051 нет операции ВЫЧИТАНИЯ !!! Не какого-то там лобачевского вычитания а самого что нинаесть обыкновенного двоичного хотя-бы, я уж не говорю о десятеричном или ещё каком (hex)! Нету блѣть вообще в принципе такого понятия для 8051 ! Три месяца изобретал велосипед сам. Потом методом тыка и "ебоной матери" допёр до вычитания прибавлением комплимента (комплимент: инверт двоичного регистра) - но три месяца долботни !!! Что самое обломное, знаешь-же сука что если есть проц то есть и вычитание полюбому как ни вертись есть, должно быть - не могут-же люди только прибавлять. Уд: оказалось могут. Такие дела.

Что ты гонишь ? У 8051 есть вычитание с заемом - subb. Ты за 3 месяца не догадался, что чтобы проделать на 8051 вычитание всего навсего надо очистить флаг переноса clr c, а потом вычесть с заемом subb a,... ? Ну ты и тормоз. Это один способ. Но есть и другой. Ибо в АЛУ любого процессора есть сумматор, но нету вычитателя. Потому-что команду вычитания процессор исполняет именно сложением в этом сумматоре. Вот так : A-B=A+(-B)=A+((~B)+1)=A+(~B)+1 То есть любое вычитание можно проделать сложением (то до чего ты доходил три месяца). Надо просто сообразить, что вычесть - это прибавить с измененным знаком, и знать, что чтобы изменить знак надо инвертировать, а затем прибавить единицу. По моему этому должны учить в любом ВУЗе на первом курсе - как представляются отрицательные числа в ЭВМ в виде дополенения до двух (см. сюда http://ru.wikipedia.org/wiki/Дополнительный_код_(представление_числа) ).

В целом он прав. Некоторые ассемблеры для 8051 действительно не принимали команды вычитания, либо требовали целенаправленного указание целевой платформы для этого. Это прямое следствие ущербности предыдущих поколений процессоров типа 8048, 8039 и.т.п. В каких-то из них или во всех не было вычитания.

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

Я тоже нихуя не понял

Можно поподробнее про то как ассемблер используется в шатлах?

.kkrieger

.kkrieger написан на c++ с использованием асма, втыкать интревью. Полемику по поводу этой игры выпиливаю.

Какой-то неименованный тред про то, как страшно жить

БЛДЖАД,аффтар, твоя статья ЧУТЬ МЕНЕЕ ЧЕМ ВСЯ. Ты просто заебал со своими «чуть менее» чуть менее, чем вообще. Подбери уже какой-нибудь другой эпитет, блѣть. Русский язык на лохоморских мемах не заканчивается, прикинь!

fail

FAIL

Трижды фейл. Переписать и добавить про эмбеддед.

Весь эмбеддед пишется на няшной сишке уже лет эдак пять. А ВСЛ туда вообще форт запихивает. Эрго: ассемблеристы должны сделать сеппуку книжкой Зубкова.

Да, науд такую удоту вообще и проходят. Заебали по ней даже и задачки задавать!

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

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

Я пишу эмбеддед на няшной сишке и на ассемблере. Вопросы?

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

Дыранись! Да ты хоть одну «разную» архитектуру видел? Мнемоники у него, понимаешь, копирайтом закрыты, и в этом все дело.

>В целом история языков программирования протекает в направлении от программирования на языке компьютера до манипуляции абстракциями вроде Послать. Лесом(всех(кому не нравится эта статья))[1]. На языке ассемблера этот код занял бы более 9000 КБ.

ну да, а когда ваш любимый компилер таки скомпилит эту абстракцию, у него получится 900000кб. И что?

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

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

асмовое быдло детектед. Хороший, годный компилятор генерирует код лучше, чем ты когда-то напишешь. С всякими там бранч предикшенами и прочими разбросами мозгами по пайплайнам. Алсо, «больше инструкций» давно перестало значить «медленнее». Асмоблѣдки даже этого не знают про свой любимый задроченный асм.

пруфец? Так и не будет пруфа про невъебенность компиляторов?

автоматика невъёбней человека в промышленном производстве. кустари от асма не нужны.

Это все бла-бла-бла. А что нибудь конкретное в качестве подтверждения большей эффективности высокоуровневых компиляторов будет ?

Компилятор быть может и генерирует хороший код, но порой ассемблерная вставочка в нужном месте позволяет ускорить выполнение раза в 2. Например, компилятору далеко не всегда очевидно, что в некотором месте программы можно использовать какое-нибудь расширение типа SSE. Или, что манипуляции с отдельными битами, порядком байт и т. п. можно делать безо всяких сдвигов и наложений масок, а более простыми инструкциями.

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

высокоуровневым дрочерам — дрочить дальше. Да, на асме ОЧЕНЬ трудно, долго и долбаторно сделать хоть что-то, а крупный проект так вообще нириально, процессор устареет и отправится на свалку истории раньше чем хоть что-то напишут. Но на этих ваших, особенно обьектных и мышкой, езыгах — очень трудно сделать нормально. Получить бегамайтного размера хелло ворлд — нивапрос, раз и все, получить глюкалу которая и на двд-то не помещается — еще проще, посадил тыщу индусов, дал пинка, и напейсали. Вот только при этом результат удручает, ну то есть свистоперделок все больше а работает все хуже и медленнее. И пра ашипки, то же самое — найти ашипку (особенно динамическую, приводящую к неработоспособности управляемого обьекта при реальном включении и тп, а не тупой наеб в формуле отлавливаемый примитивным тестом) среди мышой навазюканного, среди бегамайтов напложденного всякими трансглюкаторами, гораздо менее вероятно чем в асмовой глюкале которая будет выполнять ту же простенькую но критически важную задачу. Ибо эта глюкала будет меньше и проще на порядки, и главное — над ней кто-то думал а не только по кнопкам стучал. Повторюсь, да, разумеется, это самое «думал» в современном мире залог проигрыша и слива, ибо 95% вообще думать не в состоянии. Ну так это проблемы не асма а глобуса.

бла-бла-бла. «на асме ОЧЕНЬ трудно» — «на обьектных очень трудно», страдаю от безысходности, ибо нет пути. «Ибо эта глюкала будет меньше и проще на порядки» — вся история софтверной индустрии тому пример, ага.

>найти ашипку (особенно динамическую, приводящую к неработоспособности управляемого обьекта при реальном включении — это называется Run time error[[Участник: —Кенгуру 03:00, 9 марта 2011 (MSK)]]

Это по английски. А по русски ? Или термин "динамическая ошибка" не годится ?

Щитаю

что необходимо сказать об асме, как о языке "намба уан" для любых профессоров. Ибо это и есть его суть - делать всё максимально быстро для конкретного камня. Тут был срач "asm vs компиляторы". Упомяните же, что компиляторы на асме и пишутся. Не все, но те, которые не по 3 минуты High-Level-программу собирают.

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

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

и как быстро он компилил? Да и языки на месте не сидят, да. Если один только фронтенд весит 2 метра на плюсах, то страшно представить, что там будет на асме. И шо это тут вообще за асмоёбство такое?

На вскидку. Классический компилятор FIG Forth в исходниках на ассемблере : http://www.forth.org/fig-forth/fig-forth_8086-8088_ver_10.pdf

Ящитаю, надо запилить ссылку на эту статью: [1] — душераздирающая история. Кстати, те, кто песдят, что код для embedded-систем давно пишется на C, явно не знают сути вопроса. Да, он пишется на C, но и на ассемблере он тоже пишется, ещё как! Особенно правится.

гы-гы. Смерть задрота :) Хотя грешно: сам ведь байтовые джампы тасовал, а на один забил.

Я нихуя не понял

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

Ассемблерный код заменяют на С? После доводки мартышками? Я правильно понял? Первый раз про такое слышу.

Драйверы не пишутся на ассемблере!

Последние драйвера написанные на ассемблере были VXD под Вынь3.1х/95. А до того были только под ДОС. Во всех остальных ОСах драйверы написаны на АСМе чуть менее чем 0 строк (за исключением может эмбэддэд системок с 64К памяти, где нет ОС и драйверы тоже не отделяются). Дело в том, что код в драйверах выполняет три задачи: 1) инициализирует устройство и структуры / процедуры уведомления, специфические для ОС (1 раз); 2) программирует запрос на устройство (когда клиент просит); 3) опрашивает устройство о данных/статусе с задержками или при получении прерывания. Во всех случаях ни более быстрый, ни более компактный код ассемблера нихуя не улучшает. А вот непереносимость будет неизлечимой (попробуй провести такой драйвер в ядро Линукса…)

Учим матчасть, срочно

> Драйверы не пишутся на ассемблере! Это тебе надо учить матчасть. Пишутся еще и как. Причем даже эти ваши wdm. При этом не обязательно наличие DDK (ныне WDK), так как в случае masm'a ml.exe идет в комплекте.

Компиляторный код быстрее, чем ручной

Посмотрите, к примеру, интеловские руководства по оптимизации. Вы собираетесь запоминать все pairing'и, рекомендации и прочее? Ассемблер сейчас разве что для эмбеддед, и то, там где ещё остались жёсткие ограничения по размеру. Да видали мы "оптимизированный" компилятором код. Всегда можно его ещё оптимизировать руками, и ведь дохуя и больше остаётся разжолья для творчества, ибо нет предела совершенству. Но это уже для задротов.

Именно все рекомендации. Именно все сочетания команд и их суммарную потактную эффективность. И плюс априорное знание входных данных типа "тут можно опустить очистку, потому что тут всегда ноль, а тут можно сортировать по двордам, потому что в данных всегда есть жёсткая корреляция" — именно оно даёт 80% всей оптимизации, а не сам перевод команд си в машинные команды. И ни хрена это не сложно, потому что такая технология распространяется на крошечное ядрышко, делающее всю мякотку, а всякие фронтэнды, занимающие десятки метров и занимающиеся исключительно комфортабельной для пользователя подгрузкой задач этому ядрышку, мы тупо пишем на С++ и не паримся с оптимизацией. Так было, так есть и так будет всегда. Это тот подход, который сделал Кармака тем, кто он есть, и, как мы по нему видим — этот подход продолжает работать. Этот подход превратил Линух из доморощенной поделки в конкурента мастдая (там, правда, выдроченное ядрышко и фронтэнд обычно разнесены по разным пакетам). Этот подход породил Симбиан. Этот подход позволил шейдерам (да-да, они прогались именно как это ядрышко) захватить рынок.

+1 А еще компилятор резервирует чуть меньше чем все регистры для своих компилястских нужд. Ассемблерист от этого свободен и может использовать все архитектурные регистры (сохранив компилястские) для оптимальной обработки потока данных

Ассемблер под не-эмбедед таки используется

• в рантайм библиотеках С в функциях типа memcpy. Т.к. используется чуть менее чем во всех программах оптимизация не разу не преждевременна. Особенно характерно для Дефли - обусловлено весьма посредственной отимизацией с одной стороны и поддежкой исключительно х86 с другой.
• злобными хакерами для написания специфичного кода.

А нафига здесь вообще эта статья?Она же уныла чуть более,чем само программирование! Эта статья подошла бы больше для Педивикии.

Статья хорошая, годная чуть менее, чем наполовину, но повесьте же кто-нибудь на неё плашку {{Ссылкота}}! Кенгуру 22:15, 10 января 2010 (MSK)

ЭТО ПОЛНЫЙ БРЕД! Ни одна программа, написанная на высокоуровневом языке, не будет быстрее таковой по скорости исполнения (разумеется, если она не привязана к быстродействию внешних устройств и характеризуется только скоростью вычислительных действий), написанной на АССЕМБЛЕРЕ, разумеется, под совместимую (соответствующую платформу). Оптимизация кода, сиречь выкидывание ненужных диагностических кусков кода, кои зачастую бывают даже чуть более чем наполовину бОльшими, чем сам код, дает нехилую прибавку к быстродействию. Разность в быстродействии связана также с разницой в объеме кода. Например, всем известная ВИН ХР могла бы иметь раз в 40 меньше объема, и, раз в 80 большее быстродействие, будь она написана на ассемблере. Это не фантазии, я сам писал, как на асме Z80 (спектрум), так и на Х86(в частности на 486й платформе, в т.ч. программировал FPU (математический сопроцессор)).

Итого, по итогам "сухого остатка" моих излияний могу сказать, что:

1) "ценность", вес, строки высокоуровневого языка превышает "ценность" ассемблерной строки (команды) по "обще-программной ценности" совсем ненамного. Примерно на 1,0-1,2 раза. Соответственно, те программные продукты, которые пишутся на С, на Паскалях, и т.п., весьма успешно могли бы писаться на АССЕМБЛЕРАХ, и разница в труде программистов (человеко-часах) составляла бы около тех же 20-30 %.

2) ОШИБКИ, ран-тайм эрроры и пр. неприятности, возникающие в конечном программном продукте (например, в WINDOWS), совершенно не случайны. Сама возможность их возникновения обусловлена именно принципом НЕ-ассемблерного написания этих продуктов. Иными словами, чем больше "выскокоуровневость" языка, тем больше недокументированных (непонятных) действий может иметь одна отдельно взятая строка кода, и тем больше потенциальная вероятность ошибки.

Если же, писать на ассемблере, то программист волей-неволей должен САМ проработать ВСЕ возможные (и в т.ч. ошибочные) варианты "развития событий" выполнения кода. Даже пресловутое "деление на ноль" в некоторых программах вызывает "зависание", притом что совершенно аналогичная ситуация в случае прямого (на ассемблере) программирования математического сопроцессора вызывает всего лишь безобидный ответ от него в стиле "ничего не получилось".

3) Я сам этим занимался, мой дипломный проект (институт МАИ) был написан на гибриде из Турбо-Паскаля и ассемблерных вставок. Я уже начинал просто "чувствовать" Борланд Паскаль, зная наверняка какие регистры после каких команд у него какие значения имеют.

Проект был легок и беспечен, ни о каких "Run-time error" даже и речи быть не могло.

4) Конечно же, быстрота и безошибочность кода сами-знаете-какой современной операционки была принесена в жертву как можно бОльшей скорости эволюции интерфейсов, совместимости приложений и стандартизации драйверов. Отсюда куча зависаний, багов и прочей удыты, т.к. сама суть языка АССЕМБЛЕР такова, что пишущий на нем программист ДОЛЖЕН предусмотерть ВСЕ варианты развития событий. За все приходится платить. Предусматривать все и вся было неохота, и разработчики пошли по пути наименьшего сопротивления. Результат налицо.

Как-то так! Так-то :)

«Ни одна программа, написанная на высокоуровневом языке, не будет быстрее таковой по скорости исполнения»

Серьезно?) А как же Си? Неужели код на Си без RTL будет такой уж медленный по сравнению с Асмом? да нихуя подобного, он если и отставать будет, то на несколько тактов/мс. Кому это заметно и актуально сейчас? Встречал недавно троян на С, всего 5кб,есть все необходимые функции. И кто тут хвалился, что Асм супер быстрый/минимальный по объему язык? Разве что по сравнению с делфи/вб..

Лол, ЦЕЛЫХ 5кб? Nuff said.

блѣдь, а на Асме сколько сделаешь? четыре с половиной? На Масме минимальный ехе под венду весит 2.5 кб. Это минимум, в котором есть только пустое окно! а тут в 5кб - целый качественный трой.

Лол, зачем окно? И да, масм эта бугога)))

Трижды лол. У меня минимальный .exe на масме вышел 705 байт. Вообще оытный демосценер в 4кб запихнет 3D графику и музыку, убив у быдлокодера всяческой желание жить. Недавно проскакивала новая вишня на ассемблере в 2.5 кб(это без сжатия, пропусти сие чудо через FSG, будет вообще смещно)

Пффф.. забудь ты про СИ, %username% забудь о его кажущемся превосходстве также, как о превосходстве в оптимальности ЛЮБОГО высокоуровневого языка программирования над низким. Просто - забудь. Ассемблер - это лом, против которого нет приема.

Я (автор сего абзаца) писал практически мини-операционку, "укладывая" ее в .COM файл (макс размер 64 кб, сегмент кода, данных и стека в "одном флаконе", компилятор - TASM под DOS). С искусственным отслеживанием мыши, эникеями, алгоритмами обсчета обхода препятствий, подгрузкой данных из внешнего файла со своим собственным форматом, обработкой пользовательских эрроров и т.п. В нонешних реалиях exeшник этого твоего СИ размером в 64к в лучшем случае напишет "HELLO WORLD".

Нахуя вы срётесь и меряетсь хуями у кого уд длиннее на 500 байт, когда сидите на говносемёрке занимающей гигабайты говнокода с папками быдлокодерского дотнета по гигабайту размером C:\WINDOWS\assembly и C:\WINDOWS\Microsoft.NET

Тем временем в параллельной вселенной

Разработчик под ARM рыдает кровавыми слезами от умиления. Так, к слову: ARM — это 95 % хоть что-то умеющих мобильников, Nintendo DS, эти ваши айфоны, а также ожидающийся массовый наплыв ARM-нетбуков, работающих по 20+ часов от аккумулятора. Торвальдс вообще прогнозирует скорую победу ARM над x86 по причине разницы в энергопотреблении на 1-2 порядка.

Так вот, картина следующая — ещё несколько лет назад ARM по большому счёту не вылазил за пределы мобильных телефонов, урча маянезиком гонял себе тормозные Java-игрушки, и всем было хорошо. Работает и работает. А потом ВНЕЗАПНО подкрался взрыв популярности в более требовательном к производительности сегменте. Результат такой: хитровывернутая и непривычная платформа есть, необходимость кодить есть, заказы на супер-мега-оптимизированный нативный код (то есть не Java) есть (пока большей частью игрушки, но с первыми ARM-нетбуками ситуация изменится), а все компиляторы — полнейшее, невообразимо блевотное говно динозавра, которое никто никогда не пытался совершенствовать и допиливать. Нет, правда. Что CodeWarrior, что GCC генерят какую-то эмуляцию x86, по-другому этот ужас не назвать. Внезапно выяснилось, что некоторые критические куски хорошего, годного кода на Си, переписанные руками на ассемблере, дают буст производительности в 60-80 раз. При этом не надо использовать никаких хитрых битхаков, достаточно лишь использовать все регистры и ARM-специфические инструкции, да не генерировать страницы (не утрирую, реально страницы) какого-то невообразимого клаттер-кода, гоняющего регистры туда-сюда без видимого эффекта. Такого ужаса в компиляторах под x86 в моей фирме не застал никто.

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

• Чет фигня какая-то. ARM-ы продаются лярдами - их в 5-6 раз больше x86. Разрабатывались с нуля как микропроцессор, а не как чип для калькулятора а-ля x86. Вы попробуйте нормальные компиляторы - GCC это северный лис, страх и ужас нарушающий все возможные стандарты. ARM C генерит оченя хорошо.

• Дыробольство. Все ARM девайсы так или иначе полагаются на ядро, скомпилированное компилятором C. Например, на linux, скомпилированный gcc. Интересно было бы посмотреть каким-таким образом вы намеряли 60-80 раз преимущество в скорости выполнения.

Быдлокодерам

Попробуйте-ка ответить на следующие троллевопросы. Сможете ли вы на языке высокого уровня:

а)Открыть\закрыть вентили процессора(например A20),

б)Перевести процессор в защищенный или реальный режим,

в)Изменять содержимое регистров CR,

г)Узнать информацию о процессоре исполнив только свой код безо всяких там API и драйверов(аналог инструкции CPUID),

д)При таких-же условиях узнать количество миллисекунд с момента запуска процессора(RDTSC),

е)Вызывать прерывания, запрещать, разрешать их.

Например, написание загрузчика ОС требует знания ответов на большую часть этих вопросов.

• Школьника видно издалека. Не хотел лезть, но ты был последней каплей: я тоже задрачивал божественный FASM и горя не знал. "ЕБАТЬ Я КРУТОЙ, МОЙ ХЕЛЛОУВОРЛД ВЕСИТ 1КБ, А СИШНЫЙ — 5КБ". А что сейчас? А сейчас я понимаю, что программирование на ассемблере — занятие мудаков, которым просто не хватает поводов для повышения ЧСВ. "КО-КО-КО МОЖНО ЛИ ВЫЙТИ В ЗАЩИЩЕННЫЙ РЕЖИМ КУДАХ-КУДАХ" — дебил, на разных архитектурах ты будешь писать разные реализации всех этих мэдскиллзов. Задача высокоуровневых языков — ускорить разработку и обеспечить кросспалформенность. Понимаешь? Вряд ли тебе понадобятся столь необходимые штуки для написания своего говна под ЖНУЛИНУКС/Windows, но если такая необходимость возникнет, то можно делать ассемблерные вставки, учитывая тонкости каждой платформы, но, пойми, не надо изобретать велосипед — уже есть куча готовых решений под разные платформы. Я рад, что вылез из всей этой низкоуровневой трясины и взглянул на все это глазами нормального человека.

• Та шо ви гаварите! Следуя этой логике, НЕшкольникам, видимо, производительности неоптимизированного софта сегодня хватает за глаза. Апгрейдят технику они из-за избытка денег, а занимаются разгоном от избытка свободного времени.

«Также может использоваться задротами для написания очень компактных программ. Пример: клиент для аськи, занимающий в скомпилированном виде 34 КБ. Другой пример: тоже IM-клиент Faim 0.21 — 12.61 КБ»

И как их использовать, без допиливания? В 0.21 в принятых сообщениях вместо кириллических букв крякозябры, а вместо всего остального пустая строка. Или среди асма-задротов тоже есть быдлокодеры?

SIMD

Чо, реальное преимущество. Одна лишь pcmpxstrx вызывает лютый фап и безграничную любовь: 16 байт или 8 слов - и поиск сразу по нескольким диапазонам, поиск соответсвий, масок, результат ввиде маски, можно индекса, причем ещё выбор с какого конца и ваще к черту реверс результатов. А если искать в пачке 32-битных хешей нужный, то pcmpeqd дает чето типа 1.5-1.7 раза скорости. Решение о выпиле из последнего vs __asm под x64 было воистину феерическим. Впрочем, там его изначально не было, но я ж д'/Артаньян.