Еще раз о пользе от ассемблера

[Dmitriy40]

A_I в сообщении #1626738 писал(а):

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

Низкоуровневое программирование не означает прям непременно на ассемблере. Тот же С вполне справляется. Да и некоторые другие ЯВУ. Добавить при необходимости средства работы с физическими адресами, с битами, прерывания, исключения, разные типы/классы памяти (собственно что и сделано в компиляторах под любой МК) - и вперёд. И пока скорость такой работы устраивает - нет проблем. Пишут же под МК и на бейсике, и на паскале, и на питоне (или руби?), и ещё много на чём и ничего, работает, в том числе и весьма низкоуровневые вещи. ИМХО Вы по прежнему упираетесь не в тот критерий необходимости асма.
Вы знали что не под все архитектуры есть трансляторы ассемблера? Бывает только С и выше, ничего более низкого. Ну или массив кодов конечно можно в .c запихнуть если осциллографом восстановите коды команд (потому что документации тоже разумеется нет). Один из известных примеров - GPU. Раньше асм был и доки по командам были, но уже с десятилетие как отрезало. CUDA, OpenCL, OpenGL, что там ещё, а асма под новые видюхи нет. Разумеется это забота о юзерах и/или об акционерах (сколько труда по написанию публичных док оплачивать), как же иначе.

А специалистов таких да, много не надо, никто и не спорит. Уже лет 40 как. Споры же до сих пор вспыхивают.

[EUgeneUS]

Это смутно мне напоминает
Индо-пакистанский инцидент
историю из середины 90-х годов.

Выпускник мехмата устраивается в контору, которая делает спутники, и получает первое задание: написать программку, которая читает датчик, и в зависимости от показаний выдает команду на исполнительный механизм.
Делов-то. "Три часа на фоксе". Вечером новый работник приносит программу на C.
Руководитель говорит "Хорошо. А теперь у тебя восемь байт памяти на переменные, 20 байт на код (конкретные цифры, понятно, за давностью лет не помню) и требования на время реакции".
И ушел инженер учить асм.

[Dmitriy40]

Ну да.
Хотя космос дело такое, не все к нему допущены, хотя сейчас и полегче (за бугром).
А вот МК - ширпотреб, суют везде. И очень нередко давятся ценой до рублей (даже при тысячных тиражах, про миллионы не будем). Вот такие жлобские заказчики. И поневоле не то что асм, Форт вспомнишь с его косвенным кодированием. А если ещё и от мелкой батарейки питается и должно жить подольше пары часов ... Да, ниша не сказать чтобы широкая (хотя разнообразная), но уж поширше космоса.

[talash]

Dmitriy40 в сообщении #1626707 писал(а):

Но когда я вижу (да и пишу) код на том же С для замены команды rcl/rcr (сдвиг через перенос) - у меня волосы дыбом. Адекватной замены командам adc/sbb/mul/div (c xDX) в языках семейства C тоже нет - а это базовые операции с длинной арифметикой! popcnt, bsf/bsr, pdep/pext - да полно команд, на С выглядящих как куча непонятного кода, а уж во что превращающихся в машинном коде ... лучше и не знать, спать спокойнее.

А можете дать пример проблемного кода на Си?

[Dmitriy40]

Не уверен что вспомню где видел, сам к счастью не писал.
Про замену popcnt на 5 сдвигов и 5 and и 5 сложений (вычитаний) много где описано, в коде ещё 5 mov будут (все сдвиги одноадресные), порядка 20 команд. Не так страшно, что написали, примерно то и скомпилилось.

Сам попал лишь на комбинацию

Используется синтаксис ASM

        mov     EDX,1
.l:     ;тут код вычисления следующего бита в C
        rcl     EDX,1
        jnc     .l

Очень удобный цикл вычисления (или получения откуда-то) битов, не нужен лишний регистр под счётчик.
На С мало того что нет бита C, так ещё и последние две команды ну никак совместно не реализуются. Сдвинуть можно, бит всунуть в младший можно, перейти по старшему можно, а вот сначала всунуть, а потом перейти - вах. Только лишняя переменная, или для счётчика циклов, или для старшего бита. На компе пофиг, в МК - когда как, бывает и жалко.

adc/sbb, ну вот как их на С закодировать? Единственный более-менее приемлемый способ без ввода расширенных типов данных - сравнивать результат сложения с операндом и если меньше, то писать в отдельную переменную перенос: z=a+b+c; if(z<a || (c && z==a)) c=1; else c=0; (надеюсь не наврал, из головы же) - представляете во что это выльется в коде?

Как закодировать на C команду mul и тем более div с 128-битным результатом (аргументом) я даже думать не буду, не знаю. Все делают inline asm и не парятся.

pdep/pext вообще попадаем на цикл с 4 переменными (счётчик, результат, исходное число, маска) с условным переходом в нём и парой сдвигов (один условно). Даже не буду С код писать, и так понятно что команд 8-10 в асме и 32 итерации, мрак.

-- 21.01.2024, 23:39 --

Кстати, вот выше в офтопе был выложен длиннющий код на C с функцией ValidateAuxData, проверяющей какие-то 64шт 16-битных полей. А при наличии AVX грузим всю структуру в 4 регистра, константу в 5-й регистр (а можно и в памяти оставить, на скорость не влияет), сравниваем командой vpcmpeqw, вываливаем старшие биты в РОН (vpmovmskb), там делаем and и если вдруг, то return. Без циклов. Фактически получается развёрнутый цикл на 4 итерации, но всё уложится команд в 20-25, причём времени займёт я бы так сказал тактов 12 в худшем случае. На 64 сравнения 16-битных полей! По 0.2 такта на поле. Скомпилите кто желает ту тучу циклов и посмотрите сколько будет и команд, и времени на них (тоже в худшем случае). Что будет короче или не сильно длиннее поверю, все циклы простые, что быстрее - нет, 0.2 такта на поле без векторизации никак не получить. А теперь вопрос: ну и какой компилятор додумается до такой векториазции?! Ну-ну. Можно и без AVX, грузить по 4 поля в регистр, xor, иногда and, jz, итого 3.3*16=53 с небольшим команд, думаю хватит тоже тактов 12. Додумается компилятор С до такого? Сомневаюсь.
Разумеется это полностью надуманный пример: товарища скорость С вполне устраивает и париться нет причин. Я и не предлагаю. Просто реальный пример "умности" компиляторов.

[A_I]

Dmitriy40 в сообщении #1626762 писал(а):

Все делают inline asm и не парятся.

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

А дальше - общение на уровне интерфейса (в данном случае i2c).
Как говорится, зачем мне мучаться и общаться жестами, когда есть нормальная "человеческая" речь?

[Dmitriy40]

Видеопоток через I2C?!
Не знаю (да и не хочу) как здесь, но обычно скорость I2C не превышает 400КГц, при 16Гц кадровой это максимум 52х52 пикселя по 8 бит каждый. Даже для предельных для I2C 1МГц и 64Гц кадровой это максимум 41х41 пиксель. Или там без градаций яркости?! Тогда 150х150 или 120х120, уже хоть что-то, но без полутонов ...

A_I в сообщении #1626776 писал(а):

и на этом этапе абсолютно оправдано низкоуровневое программирование:

Но асм тут не нужен, даже 1Мбит/с любой комп легко примет и на С даже полностью программно. Вот успеет ли подёргать биты с точностью порядка 100нс - вопрос, как именно организован вывод-вывод, т.е. ограничение вовсе не от С берётся, а от скорости доступа и реакции аппаратного ввода-вывода.
Низкоуровневое - да, разумеется. Асм - совсем не обязательно. Повторю, это не синонимы. Низкоуровневые вещи можно и на бейсике писать и почти на чём угодно.

[EUgeneUS]

Dmitriy40
FGJ про I2C.

Цитата:

В стандарте версии 2.0 (1998 год) представлены высокоскоростной режим работы 3,4 Мбит/с (High-speed mode, Hs) и требования пониженного энергопотребления. Незначительно доработан в версии 2.1 (2000 год).

В версии 3 (2007 год) добавлен режим 1 Мбит/с (Fast-mode plus, Fm+) и механизм идентификации устройств (ID).

В версии 4 (2012 год) появился однонаправленный режим 5 Мбит/с (Ultra Fast-mode, UFm) с использованием двухтактной логики без подтягивающих резисторов, добавлена таблица предустановленных идентификаторов.

[Dmitriy40]

Спасибо, про 5Мбит/с (и про 10Кбит/с) не знал.
Но, добавлены то они добавлены, а вот аппаратно поддерживаются очень редко. Даже 1Мбит/с нечасто увидишь. Хотя многие всё же работают на частотах выше документированной, но что там с гарантированными интервалами (а они меняются от скорости к скорости даже в процентах! так что простое задирание частоты не поможет) я не смотрел.

-- 22.01.2024, 14:45 --

А, посмотрел по названию, там жалкие 32х24 точки. Тогда 400КГц I2C почти хватает на 64Гц кадровой. А, они и 1Мбит/с поддерживают, только не понял как стандарт или как разгон 400Кбит/с.
Здесь вообще на питоне пишут и ничего, работает. Правда как там реализован I2C смотреть не стал (не люблю библиотеки adafruit, насмотрелся на ихние либы для tft дисплеев, бррр).

[A_I]

Dmitriy40 в сообщении #1626802 писал(а):

Спасибо, про 5Мбит/с не знал.

(Оффтоп)

А что, так можно было ?..
(утверждать одно на голубом глазу, а потом "изящно" переобуться)

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

[bondkim137]

Dmitriy40 в сообщении #1626707 писал(а):

Адекватной замены командам adc/sbb/mul/div (c xDX) в языках семейства C тоже нет - а это базовые операции с длинной арифметикой! popcnt, bsf/bsr, pdep/pext - да полно команд, на С выглядящих как куча непонятного кода, а уж во что превращающихся в машинном коде ... лучше и не знать, спать спокойнее

А как вы относитесь к использованию Intrinsic-функций в Си?

[Dmitriy40]

bondkim137 в сообщении #1662238 писал(а):

А как вы относитесь к использованию Intrinsic-функций в Си?

Положительно. Это почти асм, только без заморочек с регистрами. Есть лишь пара но:
1. Это вот "почти" может несколько загубить скорость выполнения, из-за лишних пересылок (да, я не верю что компиляторы настолько хорошо оптимизируют код).
2. Не всё можно сделать макросами (а это фактически они), скажем вернуть два регистра (после div RCX) они вроде не могут (возврат результата в параметрах по ссылке - извращение). Как не могут и перенос учесть и вернуть, привёл же пример выше.
3. Есть ли интринсики для команд cmov? А это ведь сокращение условных переходов, основной беды высокой скорости.
4. А ещё я нередко пользуюсь тем что lea не меняет флаги и пишу код типа sub, lea, cmovc (или jc) - такие интринсики тоже есть?!
Так что вещь хорошая, но полностью асм в вычислительных задачах не заменяет. Хотя если только про SSE/AVX, для чего они и были придуманы, то да, удобно.

[bondkim137]

Dmitriy40, глубоко не вник, но навскидку:
- условное присвоение cmov и без интринсиков используется C-компиляторами
- деление и остаток от деления тоже
- lea компиляторы тоже давно используют в полную силу, безотносительно интринсиков

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

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

dec dword [rbx]

вместо

mov eax, [rbx]
dec eax
mov [rbx], eax

При использовании из C в 64-битном коде под Windows. Inline, без вызова внешней подпрограммы, скомпилированной сторонним yasm, например.

[Dmitriy40]

bondkim137 в сообщении #1662298 писал(а):

условное присвоение cmov и без интринсиков используется C-компиляторами

А может и не использоваться и остаться условный переход, Вы этим не рулите, как компилятору вздумается так и сделает. А ещё вот буквально на днях написал код, в котором две подряд разных (с разными не противоположными условиями) cmov (тройной выбор) и потом сразу же условный переход, потому что так удобнее. Уверены что компилятор такое удумает? Ну-ну.

bondkim137 в сообщении #1662298 писал(а):

деление и остаток от деления тоже

Одновременно? Сомневаюсь. Впрочем, могут, наверное. Но вот будут ли использовать - вопрос! И как это записать в С коде понятно компилятору (чтобы таки использовал) - тоже вопрос. Мне малоинтересный, я предпочитаю асм везде где требуется скорость.

bondkim137 в сообщении #1662298 писал(а):

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

Между командой сравнения и условным переходом (или cmov) по ней? Сомневаюсь. Я использовал для получения конструкции (a-b) mod p при условии что и a и b меньше p, тогда достаточно их вычесть, добавить p в другом регистре без изменения флагов (и lea тут экономит и mov и главное не трогает флаги) и сделать cmovc от результата вычитания.

bondkim137 в сообщении #1662298 писал(а):

как попросить компилятор гарантированно сделать

Я не знаю.
И собственно зачем? Таких конструкций что, много в коде (скажем хотя бы треть команд), в нагруженном месте? Иначе оно не медленнее dec (порты чтения часто достаточно свободны, записи простаивает реже, но тоже весьма часто). Или код не лезет в L1 или внутренний цикл в L0 (uop cache) или ROB с шедулером? Тогда да, код лучше сократить.
Отдельно умиляет когда такие конструкции повторяются для одной и той же переменной, т.е. сохранили в память, потом следующей же командой снова оттуда читаем для следующей операции. И не для volatile переменных, где это необходимо. У меня Delphi5 любит такие штуки, я как гляну в код, волосы дыбом. И всё что требует скорости пишу на асм (инлайн или внешнем).

[bondkim137]

Dmitriy40 в сообщении #1662373 писал(а):

И собственно зачем? Таких конструкций что, много в коде (скажем хотя бы треть команд), в нагруженном месте?

Не треть, конечно, но в определенных местах очень много. Это счетчик ссылок на объект. Нужно именно что б атомарно в одну инструкцию делалось, потому именно dec/inc ptr [rbx]. Для того, что б вытесняющая многозадачность не могла ничего испортить, при этом не используя интерлоки. Для x86 можно вставить ассемблерную inline-вставку, а для x64 майкрософтовский компилятор их делать не позволяет. Пришлось сделать внешнюю функцию с одной командой, что довольно костляво. С линуксом (а точнее gcc) все лучше - там есть inline-вставки. Вот я подумал, может вы пробовали под windows другие компиляторы, позволяющие inline для x64 или знаете какой-нить трюк, запрещающий оптимизацию одной C-команды. Различными подсказками компилятору, вроде volatile, (*p)-- и т.д. победить не получилось. volatile тоже не дает гарантии.

Dmitriy40 в сообщении #1662373 писал(а):

У меня Delphi5 любит такие штуки, я как гляну в код, волосы дыбом

Переходите на C, выбросьте уже этого динозавра