×

Какую инструкцию нужно выбрать при вычитании в микропрограммировании?

Добрый день!
Одним из составляющих курса введения в техническую информатику у нас является микропрограммирование (используем для этого Am2901, Am2904, Am2910), в котором мы простейшую макроинструкцию из ассемблера (например ADD RA, RB) раскладываем на микроинструкции, в каждой из которых есть следующие поля (разумеется в реальности их больше — каждая микроинструкция занимает 80 бит, но мы рассматриваем не все) :

У нас есть доступ к мануалу AMD (название — «The AM2900 Family Data Book with related support circuits»), в первом разделе которого и описывается такое «разложение», но ответа на свой вопрос я там не нашёл, разве что вот такую подсказку :

Кроме того, у нас есть несколько примеров таких «разложений», в том числе и для вычитания.

В связи с этим у меня несколько вопросов:

1. Почему для первого вычитания используется SUBS, а для второго — SUBR?

2. Можете ли Вы посоветовать что-то по этой теме, но более простое и понятное (плейлист или блог, например)? Мануал практически нечитаем :(

К сожалению, я не могу задать вопрос на форуме предмета (препод даст ответ, который еще больше запутает), а все знакомые ответы на эти вопросы не знают :(

Прошу прощения, если фотки в посте мыльные и на коленке отформатированные : они изначально такие + из-за копирайта замазал всё, что может под определение копирайта попадать.

Комменты уровня «купи предмет» не подходят — хочу разобраться в микропрограммировании.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

gofile.io/d/OtLn1V

Не благодари

Это по секционникам от Intel — серия 3000 (содрана СССР как 589)
Сама книжка бестолковая, но идеи, почерпнутые из нее, меня в начале 90-х изрядно удивили

Так это — азбука. Без нее дальше тяжело идти, так что придется читать.

Только понял что это за дичь вообще.
1) Есть C++ который был языком общего назначения 20 лет назад, и на нем писали почти все, но лет 10 назад он устарел, а недавно его вытесняли даже из геймдева. И теперь это такой очень узко специализированный язык для встроенных систем.
2) До него был С который был языком общего назначения, но который устарел 25 лет назад, и сейчас на чистый C нет позиций вообще.
3) До C был был ассемблер, который устарел в 1960 наверно.
4) И до ассемблера шпарили машинные коды эти.
Я тут всем рассказываю что Java устаревает и ее не надо учить, а про то что C++ не надо вайтишникам учить, я говорил давно, а люди учат то, прав-правнуки чего уже устарели.

Напиши что неправильно, в геймдеве даже на ААА проектах .NET уже давно. Понятно что остались движки на C++ но большая часть позиций .NET

на ААА проектах .NET уже давно

Lua, lol.

Ты всё ещё не понял. :)
Пункты 1 и 2 — херня.
Пункт 4 — херня тоже.
По пункту 3 — ассемблер всё ещё актуален. Но на нём сейчас да, не пишут.
А здесь гутарят про микрокоманды. Это то, на чём реализован ассемблер/машинный код.

Пишут, если припирает.

Я писал о профдеятельности — а не o школьных лабораторках, да прочих наколенных хобби-поделках.

Логично, что ты считаешь аудио-видео кодеки поделками, либы для ЦОС и ML, оси и я понимаю, почему ты так считаешь. Типичного гребца из совка к подобным задачам просто не подпупустят.

Держи исходник популярного видео-кодека. И найди здесь ассемблер. :)

code.videolan.org/...​x264/-/blob/master/x264.c

Все таки для тебя нет разницы между «пишут всегда» и «пишут, если припирает».

Это я тебе ещё пример хорошего кодека привёл. В основном, их пишут на «плюсах». :)

Но ты продолжай свои наколенные поделки на ассемблере. Только не предлагай их никому — побьют-с...

О, а что с плюсами не так теперь?

С «плюсами» основная проблема та, что в лоу-лэвел они не нужны.
Потому как 1) зачем «плюсы», если естъ «си»? 2) «плюсы» непортабельны.
Собственно, те же проблемы и с ассемблером.

Вот это гигансткая концентрация бреда от тебя в одном посте.

Вижу, ты вообще не понимаешь в теме, о которой пытаешься спорить. :)

Бывает. При этом, приходится писать эти базовые реализации — отдельно, для каждой архитектуры.

(в данном случае, x86, PowerPC, arm 32/64, mips — и куча архитектур осталась непокрыта)

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

Какая куча? KozakCPU? x86 и ARM покрывает 99.9% всего железа где нужно запускать x264. Всё остальное — это just for fun и не несет никакой практической ценности. И да, для этого железа всегда есть C-шные fallbacks.

Обойдутся ASCII-Art’ом %)

Обойдутся ASCII-Art’ом %)

В далеком 2005 году у меня, тогда ещё студента, державшего FreeBSD дома, случился рецидив красноглазия — смотрел фильмы в консоли с помощью mplayer и выводом в ASCII

Я думаю, что идею матрицы придумали братья Larry и Andy Wachowskis, ooops! сорри, сёстры Lilly и Lana Wachowskis глядя на таких студентов %)

Я думаю, что идею матрицы придумали братья Larry и Andy Wachowskis, ooops! сорри, сёстры Lilly и Lana Wachowskis глядя на таких студентов %)

Мне давно говорили что я муза ))

Мне давно говорили что я муза

скоріше музик

Вообще-то они её не придумали а «творчески переосмыслили». А идея эта кочевала из одного Сай-ФАй произведения в другое начиная аж с Нейромантика в далеком 1984. И это мы ещё не вспоминали про пещеру Платона.

ЗЫ: Даже зеленые буквы пришли из далекого «Призрака в доспехах» 1995 года.

вы все завидуете просто!

Где оно в жизни? Пока я вижу всё на уровне ARC процессоров — микроконтроллеры и вспомогательные процессоры (сопроцессоры) к основным. Зачем там x264? Всё что более менее производительное — это SiFive, которые не продают девборды, а продают IP cores, и Alibaba с процессорами, которых никто не видил. Если им надо x264 — пусть делают, это даже не одна десятитысячная процента рынка.

Я диванный аналитик, но по моему скромному мнению RISC-V это next big thing. Нужно время, чтоб появилось достаточно adoption. Когда появится — будут кейсы для x264.

Всё что более менее производительное — это SiFive, которые не продают девборды

А это не девборд? www.sifive.com/boards/hifive-unmatched

Alibaba с процессорами, которых никто не видил

Угу, но кодирование видео в облаке — это серьезный кейс.

Я диванный аналитик, но по моему скромному мнению RISC-V это next big thing.

В мире существует огромное кладбище next big things. Например, как работаем мы в таких случаях — приходит кастомер и говорит, нам нужна поддержка RISC-V, по самым скромным подсчётам ему это станет в несколько миллионов долларов, если таких кастомеров будет много, все расходы по поддержке будет распределена между ними. Как правило на этом этапе всё желание использовать RISC-V пропадает, вот если бы было готовое, тогда может быть мы будет использовать, бла-бла-бла. В прошлом такое мы проходили с другими next big things: PowerPC, MIPS, SuperH процессорами — кастомер около нуля. Почему RISC-V должен стать исключением?

А это не девборд? www.sifive.com/boards/hifive-unmatched

You can pre-order the Unmatched board from the following suppliers. В общем когда-нибудь её сделают, когда HiFive насобирает 10К-100К заказов и запустит линию по производству процессоров, не раньше.

Угу, но кодирование видео в облаке — это серьезный кейс.

Ну пусть пишут на асме для своего процессора. Но энтузиасты без бесплатных бордов это делать не будут.

Почему RISC-V должен стать исключением?

Может дело не в самом RISC-V, а в состоянии индустрии.

Недавно AWS выкатил Graviton 2 (ARM), который по спекам рвет Xeon при этом стоит дешевле (я не проводил никаких тестов, только смотрел спеки).
Alibaba заявляет о выпуске процессора на базе RISC-V, тоже угражает порвать Xeon в дата-центра (не точно).
Дальше Apple M1/M2, которые уже вытеснили

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

Когда цена входа пробьет какое-то дно, то стоимость лицензийц и IP начнет играть роль — смысл платить деньги ARM, когда можно бесплатно юзать RISC-V?

Может дело не в самом RISC-V, а в состоянии индустрии.

А какую проблему индустрии решают RISC-V?

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

Amazon купила израильскую Annapurna Labs, которая делала Graviton2 на новейшем на тот момент Neoverse ядре, не Cortex.

Когда цена входа пробьет какое-то дно, то стоимость лицензийц и IP начнет играть роль — смысл платить деньги ARM, когда можно бесплатно юзать RISC-V?

Практически все именитые вендоры имеют свои IP core и только используют ARM ISA фронтенд,
there is no license fee for the ISA. nVidia, AMD, Samsung, QualComm используют свои IP Core, а это больше половины рынка.

Ну и не забывай, что под AARCH64 (ARMv8) уже написано и оптимизировано практически всё. Даже если процессор RISC-V будет немного дешевле и равный по скорости, то затраты на софт с лихвой перекроют экономию на железе. А это реально десяток лет заняло для ARMv8.

there is no license fee for the ISA.

Сенкс, не знал этого. Покопаю еще в чем преимущество RISC-V при этом условии.

Я вот полез в детали и детали не очень радужные:

Anyone who wants to consume a RISC-V core can do so freely—there are no licensing fees to use the RISC-V ISA. For example, many soft RISC-V cores can be freely downloaded from the Microsemi GitHub site or others. For commercial end products, usage of the RISC-V trademark or the RISC-V logo is only permitted under the license granted within the RISC-V Foundation Membership Agreement. The key point is that the ISA has a permissive license.

Т.е. вендор всё равно мне продаст процессор с наценкой за членство вендора в RISC-V.

Ну и вот интересную новость откопал за 2019, где ARM говорит: Take a RISC, not a RISC-V и убрала плату за лицензирование ядер ARM, в микроконтроллерной нише, где есть присутствие RISC-V.
www.theregister.com/...​/16/arm_licensing_change

ARM: Flexible Access will cost $75,000 per year with one annual tape-out, or $200,000 per year with unlimited tape-outs.
RISC-V: $250k Annual membership fee

Даже тут бесплатность RISC-V становится не такой уж бесплатной.

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

Anyone who wants to consume a RISC-V core can do so freely—there are no licensing fees to use the RISC-V ISA. For example, many soft RISC-V cores can be freely downloaded from the Microsemi GitHub site or others. For commercial end products, usage of the RISC-V trademark or the RISC-V logo is only permitted under the license granted within the RISC-V Foundation Membership Agreement. The key point is that the ISA has a permissive license.

Т.е. вендор всё равно мне продаст процессор с наценкой за членство вендора в RISC-V.

Я так понимаю, это значит, что вендор не может наклеить наклейку «IntelRISC-V inside», без наклейки членство не нужно. Надо только какое-то ключевое слово вместо «RISC-V» придумать, чтоб те, кто в теме, знали что там внутри.

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

Эти байки про высокий TOC Linux MS пускает уже давно, но, например, факт — в облаке винды почти не осталось, бесплатность Линукса один из ключевых факторов его популярности. Винда в облаке там, где не осилили как юзать SSH, или там где приходится крутить какой-то легаси софт, который только под виндой работате.

Я так понимаю, это значит, что вендор не может наклеить наклейку «RISC-V inside», без наклейки членство не нужно. Надо только какое-то ключевое слово вместо «RISC-V» придумать, чтоб те, кто в теме, знали что там внутри.

Ну по крайней мере кастомер, который дружит с головой не купит RISC-V совместимый процессор, который не прошёл сертификацию на совместимость. Публично заявлять что процессор имеет RISC-V инструкции (ISA) тоже нельзя, можно только их бесплатно использовать.

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

Эти байки про высокий TOC Linux MS пускает уже давно, но, например, факт — в облаке винды почти не осталось, бесплатность Линукса один из ключевых факторов его популярности. Винда в облаке там, где не осилили как юзать SSH, или там где приходится крутить какой-то легаси софт, который только под виндой работате.

Дело не только в МС. С нами та же ситуация. В облаке может быть — там очень маленький сабсет приложений крутится и аппаратура используется далеко не вся. А вот в embedded стоимость решения на полноценных SoC ничем не отличается по стоимости от QNX.

Ну по крайней мере кастомер, который дружит с головой не купит RISC-V совместимый процессор, который не прошёл сертификацию на совместимость. Публично заявлять что процессор имеет RISC-V инструкции (ISA) тоже нельзя, можно только их бесплатно использовать.

RISC-V контора никакой сертификации не делает, как я понимаю. Они собирают бабки за ремонт провала право юзать официальное лого.

Есть полу-рабочий сырой test suite, которые лежит на гитхабе. Его можно форкнуть и вперед делать свою сертификацию.

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

ИМХО совсем другой случай — интеловский ISA не бесплатный с самого начала, так что не удвивительно что пришлось платить.

RISC-V контора никакой сертификации не делает, как я понимаю. Они собирают бабки за ремонт провала право юзать официальное лого.

Они продают тестовые наборы. Например Khronos даёт бесплатные conformance tests для Vulkan, OpenGL ES, OpenCL, etc. Но они не дают тебе право вешать лого, а тот же самый код, только более старый, но пропущенный через кабеля из структурированного золота они продают за бабки и результат этого теста даёт право вешать лого.

Есть полу-рабочий сырой test suite, которые лежит на гитхабе. Его можно форкнуть и вперед делать свою сертификацию.

Это всё равно не даст право вешать лого.

there is no license fee for the ISA

Вообще где это написано? Я не могу найти подтверждения

Ладно, притворимся, что я этого не писал, тяжело фильтровать паблик/не паблик информацию.

ARM предлагает такие лицензии:
www.arm.com/...​y-arm/how-licensing-works

Есть так называемая «ARM Architecture License», которая продаётся из под полы за договорную цену. Которая даёт право использовать ARM ISA. Там фигня по-ходу такая же как и с RISC-V — копируй ISA на здоровье, но не называй это ARM. Если назвал — покупай «ARM Architecture License».

Лажа!
Там вызывается x264_encoder_encode(), который и делает работу. А то, что ты прислал — это обертка для работы с метаданными)))

x264_encoder_encode(), который и делает работу.

x264_encoder_encode() тоже на “си”:

code.videolan.org/...​/master/encoder/encoder.c

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

Кста давеча я видел код какого-то кодека из популярных, когда авторы бахвалились подъемом производительности после перехода на асм с С. Перевели тупо в лоб, только с векторизацией. То же самое, но на С с векторными интринсиками было бы читабельнее и не медленнее.

Перевели тупо в лоб, только с векторизацией. То же самое, но на С с векторными интринсиками было бы читабельнее и не медленнее.

Относительно скорости, вопрос сложный. Хороший компилятор — сделает из С кода лучший ассемблер, чем напишет сpедний ассемблерщик.
Но хороший ассемблерщик — напишет код лучше, чем сгенерит хороший компилятор. Другое дело, что таких ассемблерщиков — единицы в мире.

Сооtветственно, код совсем необязательно будет медленнее — но намного читабельнее.

Вот эти единицы обычно и пишут кодеки)

Вот эти единицы обычно и пишут кодеки)

Подавляющее болъшинство кодеков — написаны хипстерами на «плюсах». Какие там ассемблеро-единицы. :)

И какие это кодеки написаны на плюсах?
Вот даже твой «на С» оказался на деле ассемблерным.

Вот даже твой «на С» оказался на деле ассемблерным.

Я привёл пример хорошего кодека. А чаще — такие: hg.videolan.org/...​/file/tip/source/x265.cpp

Например, kernels для Intel’овских аппаратных кодеков, операции в которых не поддерживаются аппаратно пишутся вообще на GPU ассемблере вчистую:

github.com/...​/mc/interpolate_Y_8×8.asm

Вот где крышу сносит, а обычный процессорный асм после GPU’шного — как на английском читаешь.

А так да, та же Intel MediaSDK написана на плюсах, главное не лезть внутрь дальше определённой глубины :D github.com/Intel-Media-SDK/MediaSDK , но если полезть, то обнаруживается, что используется VAAPI, а что в VAAPI я как раз выше привёл.

O_O
шейдерный язык вообще становится проще паренной репы.

Кодерок, видишь как получилось, говорил что cognitive decline у байдена, а лажаешь сам.

Это ссылка на обвязку к CLI, а не реализация кодека. Зачем там ассемблер?

Вот тебе ассемблер в самом кодеке: code.videolan.org/...​mon/arm/bitstream-a.S#L28

Пишут, если припирает.

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

DO NOT CHECK OUT THESE FILES FROM GITHUB UNLESS YOU KNOW WHAT YOU ARE DOING.
Если за вашей ссылкой кроектся какой-то остроумный ответ, то было бы неплохо его продублировать словами.

github.com/FFTW/fftw3

Тут, вроде, код на матлабе — из которого сгенерирован «си». Где ты там высмотрел ассемблер?

Тут, вроде, код на матлабе — из которого сгенерирован «си»

ocaml
якби ж ще його творці хоч трохи приложили руку до його юзабельності...

А чого не позорились?
На гітхабі є статистика по мовах у даному проекті, у порядку спадання: c, ocaml, makefile, m4, c++, perl, other.

Плюс, про те, що там ocaml, який описує ці всі перетворення, який потім конвертується у c, вже співано-переспівано, як одне з найвдаліших застосувань ocaml у «не наукових» проектах.

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

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

и сейчас на чистый C

позиций чуть ли не больше чем на С++ вообще-то.

Угомонись и учи JavaScript, тебе шашачки или ехать? Хочешь потратить 2к часов на обучение, и получать 4-5к$ набивая транслейшены? или трахать себе мозг этим 10к часов и потом не получить оффер на 300$ как я в свое время?

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

Я бы посоветовал тебе уходить с универа, я в топовом универе, на топовом факультете по CS 6 лет всякую фигную учил, а потом не мог оффер на 300$ получить, и то у нас такое ереси не было как у тебя. Нам в 2009 уже перподы говорили что ассемблер давно устарел, не ебите себе мозг. Можно реально 6 лет фигней прозаниматься, а в ИТ с нуля за эти 6 лет можно стать минимум лидом если не архитектом. А диплом потом купишь с 0.25 своей месячной ЗП если надо будет ехать куда-то. А если не планируешь валить, то он тебе и не нужен вообше. Если бы меня в прошлое вернули бы, сам бы так сделал бы.

Я уже свалил, это за бугром такое говно толкают на первом семестре (остальные предметы правда (почти) идеальны)

Это в какой стране? И какая это специальность у тебя?

Германия, CS
Универ указать не могу — могу по шапке за такие вопросы получить, поэтому и шифруюсь так сильно

Та универ и не надо, для чистого CS это какая-то древняя магия даже по украинским меркам.

У нас и не такой некромантией увлекаются — весь сок появляется на практике, которая обязательна и которую ведёт эта же кафедра

Это видать 1-2-й курс, все нормально. 2. Как самому придется писать свой Node что делать будеш ? 2.

и учи JavaScript

даеш по Фленагану при всех прочих равных.

Зачем для node знать микрокоманды? Пусть те кто пилит для плюсов компиляторы этим занимаются.

Пусть те кто пилит для плюсов компиляторы этим занимаются.

Им это тоже не нужно.

Нужно.

Нужно.

Микрокоманды? Сомневаюсь. Описания ассемблерных команд — должно быть достаточно.

Почитай что такое суперскалярность и как она работает.

что такое суперскалярность и как она работает.

«предсказатель переходов», «кэш», «конвейер» , итп — это всё вещи, на которые можно (или нельзя) влиять командами ассемблера. И хороший компилятор может генерить хороший ассемблерный код.

Но при чём тут микрокоманды?

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

Например INC будет использовать обращение к памяти два раза: для чтения и записи и один раз ALU.
INC RDX сделает икремент RDX регистра используя только ALU.

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

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

Например INC будет использовать обращение к памяти два раза: для чтения и записи и один раз ALU.
INC RDX сделает икремент RDX регистра используя только ALU.

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

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

Вся эта информация — есть в описаниях ассемблерных команд. Лезть в код микрокоманд (даже если таковой доступен) — повода нет.

Команды тут не причём, они себя могут вести по разному в зависимости от окружающих их команд. Уже последние лет 15 нет фиксированного поведения.

Страница 264, skylake-x, x86-64
www.agner.org/...​ze/instruction_tables.pdf

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

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

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

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

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

Компилятор один для всего как правило, но target опции могут быть под разные CPU. Посмотри только зоопарк оптимизаций для x86:

gcc.gnu.org/...​docs/gcc/x86-Options.html

А так да, как правило компиляция идёт под target платформу, особенно в embedded, нет смысла генерировать стандартный обычный код, совместимый со всеми x86 и от того неоптимальный.

Хорошо, допустим наш студент через 10 лет будет архитектом в Google, и будет писать убийцу Node. Ты же понимаешь что он за 10 лет это все по 0 забудет?
Ему надо учить то, что поможет ему найти работу джуном как можно быстрее. А вот через 10 лет, будет учить, то, что надо для написания убийцы Node.

Если идти не джуном девелопером, а мануал КУА, то учить еще меньше. А если идти уборщиком в айти, то вообще ничего учить не надо

Звучит как — зачем учить таблицу умножения если есть калькулятор в телефоне. С точки зрения умного мозга который бережёт ресурсы организма от энерго-затратной деятельности — очень даже логично. 2. Найти работу джуном как можно быстрее — это реалии другой страны, он в Германии.

Звучит как — зачем учить таблицу умножения если есть калькулятор в телефоне.

Таблица умножения — вещь полезная. Микрокоманды чел забудет через месяц, после сдачи. И правильно сделает.

Микрокоманды чел забудет через месяц, после сдачи.

Да, реально же забудет все, зачем зачем зря себя мучать, и учить не релевантные вещи для своего уровня. И это не надо знать, что бы понять «как комп работет».

Да, реально же забудет все, зачем зачем зря себя мучать, и учить не релевантные вещи для своего уровня.

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

И это не надо знать, что бы понять «как комп работет».

Есть люди, котоыре удовлетворяются простым объяснением на вопрос «как комп работает» — нажимаешь кнопочку, там загораются лампочки и начинает внутри что-то гудеть. Есть люди, которые доставляет удовольствие понимать немного больше.

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

Комменты уровня «купи предмет» не подходят — хочу разобраться в микропрограммировании.

Зачем тебе в этом разбираться?

99.99% кодерков (включая эмбедов) — с микрокодом в своей работе никогда даже близко не столкнутся. Ты, скорее всего, никогда не столкнёшься тоже. Соответственно, купи предмет и забудь.

Если понадобится — тогда и освоишь.

Купить влом, а тема интересная, да никто помочь не может (поэтому вопрос и закинул сюда)

Купить влом,

Не ленись. Купи, а освободившееся время потрать на C/C++

C у нас отдельным предметом (основы ОС) идёт, там все ок

Зачем тебе в этом разбираться?

Я тебя лично вычеслю по айпи и побью за такое отношение. Гребанный культ невежества.

Я тебя лично вычеслю по айпи и побью за такое отношение. Гребанный культ невежества.

С микрокомандами уже разобрался? Молодец. Теперь займись реализацией микрокоманд, на уровне схемотехники.

Иначе ведь «гребанный культ невежества» ©

Теперь займись реализацией микрокоманд, на уровне схемотехники

Это деловое предложение или просто потрындеть? 115$/h, ТЗ кидай в личку

115$/h, ТЗ кидай в личку

«гребанный культ невежества» ©

Если я идеально задрочу AWS и все патерны микросрвисов, то смогу стать архитектом.
А если эту парашу выучу, то только коллег повеселю.
Я то как раз знаю как комп работает, и пару раз на интервью спросил про размер шины процессора, в контексте атомарной записи за одну команду, без интелкоа, там на меня наругались и коллеги и соискатели, типа зачем такое в 2к20 бекендеру знать?
P.S. Техлиду бекендеров.

А можно в принципе объяснить, ЗАЧЕМ это нужно учить? В микрокоманды имеет смысл вникать, если на них есть что писать ПРЯМО СЕЙЧАС, и прямо сейчас есть устройства, которые действительно будут работать быстрее за счёт оптимизации, и есть доступ конкретных обучаемых людей к применению этих навыков в деле.

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

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

именно, если бы не препод\предмет, я бы давно уже укатился в сторону С

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

нет, но он хотя бы читабельный + я не только С учу

Харькив

Это о селении в Конго ? Или тебя резать надо ?

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

Причем тут язык программирования вообще ? Это к любому языку программирования надо.

Так так блин пишешь, как будто чистый C это оружие будушего какое-то.

С «си» всё достаточно просто:
— умеешь в «си» — сможешь в любой другой язык/фреймворк, в течении недели
— не умеешь в «си» — ИТ-инвалид

Так же даже классов нет, не говоря уже про лямбды и ORM-ы. После него долго переучиваться придаться на что-то другое.

Так же даже классов нет, не говоря уже про лямбды и ORM-ы.

«си» ценят за указатели. Когда умеешъ в них — лямбды с классами и прочая хипстерщина, это детсад.

П.С. Впрочем, и лямбды, и классы в «cи» есть. Если в него умеешь.

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

я его запомнил как самый деревянный язык.

Это не баг, а фича. :)

указатель на функцию, чем тебе не лямбда? С захватом переменных, правда, сложнее

макросы для захвата

та ну. когда куча одинаковой работы — почему нет?
например, самый легковесный вариант распарсить конфиг

READ_ARRAY_FIELD_INT(sip.lines, lock_codec);
READ_ARRAY_FIELD_INT(sip.lines, port);
READ_ARRAY_FIELD_INT(sip.lines, qos.sip.dscp_val);
READ_ARRAY_FIELD_INT(sip.lines, qos.sip.so_prio);
READ_ARRAY_FIELD_INT(sip.lines, qos.rtp.dscp_val);
READ_ARRAY_FIELD_INT(sip.lines, qos.rtp.so_prio);
#define READ_ARRAY_FIELD_INT(arr, field)			\
	if(arr_name == #arr && arr_field == #field) {	\
		if(index >= LENGTHOF(arr))					\
			goto out_of_range;						\
		if(!value.IsDigits())						\
			goto not_a_number; 						\
		(arr)[index].field = value.ToNumber();		\
		continue;									\
	}

или заполнение сообщений для железа в читаемом виде

FMAIL_CREATE(ApiFpMmSetRegistrationModeReqType, API_FP_MM_SET_REGISTRATION_MODE_REQ);
FMAIL_PUT(RegistrationEnabled, enabled ? MM_REGISTRATION_MODE_SINGLE : MM_REGISTRATION_MODE_DISABLED);
FMAIL_PUT(DeleteLastHandset, false);
FMAIL_SEND();
В Украине уже на C вакансий не осталось

Морозные былины, братишка

Ну вот смотри, я ввожу в поиске вакансий JavaScript — и мне ни одной С вакансии не выдало — С умер!

О как А это тогда что такое ? jobs.dou.ua/...​ies/142481/?from=list_hot или вот это jobs.dou.ua/...​tellias/vacancies/142648 Хотя конечно С/С++ вакансий 130 jobs.dou.ua/vacancies/?category=C+ против 700-та jobs.dou.ua/...​ncies/?category=Front End Но в общем так уже довольно давно, вебмастеров конечно на украинском рынке нужно сильно больше потому что через интернет сильно проще найти проект как на фриланс так и разным шхунам на 20-100 человек. А ЗП сровнялась уже, еще в году 7-12 С/C++ платили сильно меньше чем например Java, хотя языки близко-родственные. 2. ИМХО наша система разделения инженеров по языку программирования — бред! По области задачи автоматизации (business aria) можно делить, а так — большинство программистов и авто-тестеров которых я знаю владеет 3-мя 4-мя языками минимум.

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

ИМХО наша система разделения инженеров по языку программирования — бред! По области задачи автоматизации (business aria)

Это тоже бред.
Как по мне есть всего 4 области:
Общая разработка (веб, бекенд для мобил, облака, фронтед)
Фронтенд Мобил.
Геймдев.
Встроенные системы.

Общая разработка (веб, бекенд для мобил, облака, фронтед)
Фронтенд Мобил.

Это вообще не программирование.

Ну как раз на это 90% позиций сейчас, то есть легче найти работу, легче пойти на +500, легче найти горячую вакансию, быстрее стать синьором, легче выйти на 300к.

егче пойти на +500, легче найти горячую вакансию, быстрее стать синьором, легче выйти на 300к.

300к в веб-хипстерщине? Забудь.

Так сейчас вся общая разработка это «веб» Web API для UWP, WPF, Qt, Atom, андройда, iOS, и Angular/React одно и то-же или практически одинаковое, а помимо этого только геймдев где мало платят, и ваши встроенные системы и драйвера, где платят столько же, но вакансий очень мало.

В Украине есть вакансии по ядру Линукса. И свои 5к там можно взять. И там чистый С.

3 вакансии на всю страну небось? С 1-й выгнали, на 2-ю не взяли, и сидишь на 3-й без повишения ЗП до конца жизни. А на чем то посовом по 200 вакансий только в Киеве и + 200 на удаленке.

Как минимум, тут Mellanox и Ubiquity.

А можно в принципе объяснить, ЗАЧЕМ это нужно учить?

Именно что для понимания принципов. Конкретно изучаемая система не нужна, но это — пример для понимания базовых вещей. И микропрограммное управление собственно с тех пор не поменялось. Конечно, наивно думать что человек придет на работу и ему дадут разработку микрокода для системы на Am2900. Но вполне возможен вариант что придется делать какой-то автомат состояний, и микропрограммное решение может прийтись «в тему». Поэтому знать что оно бывает, как принципиально работает и какой возможный маршрут разработки — для настоящего инженера полезно.

Для общего ознакомления и понимания как вообще работает компьютер. Без этого понимания ИМХО вместо программиста имеем формошлепа. Инструкции и так «прошиты в железе». Но есть два способа комплексный набор инструкций и рациональный. В первом случае имеем большой набор (400-500) разнообразных сложных команд наподобие stosq, в современных CISC (Intel,AMD) их внутри железа принято рассказывать на набор рациональных. Это усложняет схему процессора, и соответвено энергопотребление. RISC (ARM,Power,Spark) — случай большой набор команд «по проще», более простое логическое устройство камня и меньшее энергопотребление. Если тебе вдруг надо написать свой ассемблер, или генератор машинного кода к компилятору или виртуальную машину — то надо знать как устроены команды и микрокод. Изучив одну архитектуру в принципе по аналогии можно уже быстрее изучить любую другую. Ну и в целом если знаеш как процессор определенной архитектуры работает эффективнее — можешь в том числе и на ЯВУ писать код который будет на порядки оптимальнее поделок азиатских коллег и формошлепов.

Ну и в целом если знаеш как процессор определенной архитектуры работает эффективнее — можешь в том числе и на ЯВУ писать код который будет на порядки оптимальнее поделок азиатских коллег и формошлепов.

Нет, микропрограммирование тут не поможет, тем более на порядки.

Ок, допустим инструкция целочисленного деления и получения остатка от него выполняются в архитектуре x86 за 4-ре такта CPU, а ARM около 12. Как более иффективно реализовать atoi для этих архитектур ? Простой пример надо записать скажем: SVG,COLLADA или GLTF файл, операция преобразования числа в строку будет вызвана пару миллионов раз.

Как более иффективно реализовать atoi для этих архитектур ?

За собственную реализацию atoi на проекте/в продукте — тебя побьют палками и выгонят на мороз.
И правильно сделают.

Естесвенно — а потом догонят и еще раз палками. В реальности мне и AVL интервал деревья пириходилось писать и компиляторы из XML шаблонов в XSD и много чего такого разного чего я никогда не думал что придется писать, однако пришлось. Пока оно работает — и причем так как надо, менеджменту всеравно как оно внутри сделано вообще, лиш бы тикет закрыл желательно позавчера. А перед коллегами — сможешь доказать что твоя реализация в контексте эфективнее — например показать результаты профайлинга и перформанс тестов, никто возражать не станет. 2. Конечно собсвенную реализацию пишут уже после того когда выяснилость что универстальная не показывает нужный результат.

Даже если тебе позволят реализовывать свой атyи и прочий «велосипед» — знание микрокоманд тебе не понадобится.
Достаточно знания команд ассемблера (включая, длину команд).

Сочувствую, как будешь работу менять, и у тебя спросят с пристрастием вот это:
dou.ua/forums/topic/32328
То ты пожалеешь что писал

компиляторы из XML шаблонов в XSD

Да я 10-ть лет назад уже ушел от DDD CQRS ников в весельное плавание :) Тогда они правда за JSF топили. Возможно это новость — но при смене работы я буду искать только то что мне интересно, проще говоря искать задачу для ее решения — а не технологии ради технологий или что нибудь чтобы были деньги заплатить комуналку (надеюсь ибо с текущими реалиями не зарекайся). А «компилятор» нам с Вовой (моим напарником по pair programming) пришлось писать чтобы руками не делать XSD в течении пары месяцев (а мы сумели подсчитать что руками возится нам придется долго). Поскольку важная для нас информация была набита в качестве некоей формальной грамматики в комментариях — мы собразили что можно использовать DOM парсер для разбора + и натравить Regex на комментарии с грамматикой. Дальше сформировали AST и набросали простой генератор XSD. В общем обошлось без байсонов, антлров спиритов, бинютилсов и т.п. Справились за 6-ть дней, и потом раздали софтину всем желающим кого заставляли делать эту же рутину. 2. Книгу дракона всем советую почитать для ознакомления — может пригодится.

В atoi слишком много ньюансов, чтобы его пере-реализовывать.
Скорее речь о чем-то вроде Fast inverse square root

Вообще за использование atoi бьют палками и выгоняют на мороз. У нас точно. strtoul или своя реализация если правда вызывается миллионы раз.

Ок, допустим инструкция целочисленного деления и получения остатка от него выполняются в архитектуре x86 за 4-ре такта CPU, а ARM около 12. Как более иффективно реализовать atoi для этих архитектур ?

LOL. Вы бы подумали хоть пару минут над своим примером...

1. atoi (конверсия строковой записи в число в памяти) требует умножения, а не деления. Деление нужно для перевода из родной в неродную систему счисления (для компа — из двоичной в десятичную), то есть это было бы itoa/*print/to_string/etc.
Куда вы собрались вводить деление в atoi — моя не понимать.

Что имелось в виду на самом деле — деление с itoa или умножение с atoi?

2. Деление на неизвестное целое число у всех долгое (в зависимости от длины, но инструкции Intel по x86 дают 30-40 тактов на 32-битное деление и 50-90 на 64-битное). А вот деление на константу компиляторы уже лет 20 как преобразуют в обратное ему умножение. Почитайте например эту статью по принципам такого деления.
Но на уровне компиляторов эта задача скорее сведётся к тому, как лучше делать, из вариантов: в цикле выдавать по одной цифре, деля на 10, или сразу по две, деля на 100. Второй требует меньше циклов, но больше памяти для представления пар цифр.

Но итого оба варианта сводятся к умножению, которое, по общему принципу для современных процессоров, следует считать по длительности за два сложения (слава матрицам и параллельным сумматорам). Древний ARM с Booth или аналогичными подходами не рассматриваем.

3. В реальности, для современных процессоров будут играть роль не мифические микрокоманды, которые вы всё равно не узнаете — конкретная структура микрокоманды для каждой модели процессора это жесточайший промышленный секрет, за активную попытку выведать который могут и убить — а значительно более банальные, но обычно публикуемые (тот же Intel их печатает) рассказы про количество исполнительных блоков, их возможности и специфику; длину внутреннего конвейера, количество физических регистров после переименования, варианты склейки (fusion) разных микрокоманд и т.д. — знания, которые с программированием какого-нибудь 2900 соотносятся примерно как в этой картинке.

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

Я промазал :) имелось в виду функция преобразования целочисленного двоичного в десятичную строку. В стандарте это вообще делается через snprintf. При вызове библиотечной функции, когда компилятор не сумел подставить интрисик с imul-ом, оптимизация не сработает получите операцию деления и получения остатка от деления сразу. 2. Мерять и профайлить конечно нужно — тут мы обсуждаем вопрос что на меряют ребята которые понятия не имеют как это вообще работает. Как видим многих это не смущает совсем.

Я промазал :) имелось в виду функция преобразования целочисленного двоичного в десятичную строку.

Ну да, тогда деление. Но — на константу.

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

Почему не сработает?
Хм, ну если кто-то напишет универсальную функцию преобразования в текст по любому основанию и будет вызывать её для 10 при %d и 16 при %x... ну да, может быть и такое. Но скорее всего ему достаточно быстро объяснят, что так делать не надо. (В крайнем случае есть libdivide от автора той ссылки про обратное умножение: создаётся контекст «делитель» с заранее вычисленными коэффициентами и потом он быстро-быстро получает результат через умножения.)

получите операцию деления и получения остатка от деления сразу.

Это на x86. На ARM такой операции нет, там только получение частного. Но есть также fused multiply-add для целых(!), через которую обычно получается остаток от деления, имея уже частное. Для RISC-V операция остатка есть, но её надо явно спаривать с получением частного, если они выполняются вместе.

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

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

Гораздо хуже случай типа такого. Тут никакие библиотеки не помогут.

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

Дело даже не в том, что большинству программистов не понадобится знание машинного кода. Дело в том, что за машинный код они изучают. За свою жизнь я слышал о разных экзотических процессорах, но о семействе AMD Am2900 не слышал.

Am2900 is a family of integrated circuits (ICs) created in 1975 by Advanced Micro Devices (AMD). They were constructed with bipolar devices, in a bit-slice topology, and were designed to be used as modular components each representing a different aspect of a computer control unit (CCU). By using the bit slicing technique, Am2900 family was able to implement a CCU with data, addresses, and instructions to be any multiple of 4 bits by multiplying the number of ICs. One major problem with this modular technique was that it required a larger number of ICs to implement what could be done on a single CPU IC.

Цифровая электроника на биполярных транзисторах. Процессор из нескольких микросхем. Литература 1980-х годов. Это ужас, господа.

Не надо говорить, что это нужно для понимания общих принципов. Для понимания общих принципов годится любой процессор. Почему бы не изучать MIPS, который описан в куче учебников, который знает куча людей, который применяется? Почему не изучать реализацию параллелизма и кэш-памяти, учитывая, что сейчас это единственный способ увеличить производительность компьютеров? Есть много полезных тем, почему именно AMD Am2900? Преподаватель хоть как-то обосновал свой выбор, Hippity Hoppity? Если вы платите за учёбу, вы имеет право требовать объяснений. Если выбор не обоснован, надо не покупать зачёт, а бежать из вуза. Что-то я сомневаюсь, что остальные учебные курсы там идеальны. На курсе по ОС начнут грузить каким-нибудь Мультиксом. :-) На Западе тоже бывает плохое образование. Один преподаватель в курсе по япам мучит студентов dynamic scoping и deep/shallow binding, другой заставляет изучать metacircular evaluator из книги Абельсона и Сассмана, третий рассказывает shunting-yard algorithm.

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

Микрокоманды — это не машинный код.

Команды машинного кода — реализованы микрокомандами.

Цифровая электроника на биполярных транзисторах. Процессор из нескольких микросхем. Литература 1980-х годов. Это ужас, господа.

Э-э-э-э... А при чем здесь элементная база? Я вон спокойно, чисто для фана, засунул процессор на Am2900 в FPGA. Где тут 80-ые и биполярные транзисторы? А принципы микропрограммного управления на сегодня остались абсолютно те же. Новейшие процессоры аппаратно реализуют только простые инструкции. Все более сложные действия (хотя бы вход в исключение) выполняются под управлением микропрограммы. Впрочем, для формошлепства, тема действительно ненужная.

Почему не выбрать более современный процессор?

Потому что собственно принципы желательно изучать на как можно более простой системе, не затененные кучей деталей. Если понял принцип — дальше уже неважно какая система и на чем построена. Am2900 как раз очень неплохое учебное пособие — есть литература, инструментарий и примеры реализованных проектов.

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

MIPS/x86/ARM/etc — это другой архитектурный уровень. Секционники Am2900 (или Intel 3000, или какие другие) — оно совершенно про иное.

И там в первой инструкции SUBS ничего в регистры не коммитится — NOP указан. Там видиться AB — возможно результат вычитания это адрес, выставляемый на шину.

Можно книжки порекомендовать:

Bit-Slice Design: Controllers and ALUs by Donnamaie E. White:
www10.edacafe.com/...​cle=BITSLICE/bitslcP.html

Bit-Slice Microprocessor Design by J. Mick and J. Brick:
bitsavers.informatik.uni-stuttgart.de/...​processor_Design_1980.pdf

И недавно закончил пет-проект на Am2900: github.com/...​BM1/cpu11/tree/master/am4
Там же есть мета-ассемблер для Am2900 на Питоне наваянный.

1. Почему для первого вычитания используется SUBS, а для второго — SUBR?

А как без хрустального шара увидеть что такое первое вычитание и что такое второе?

Я так понимаю из мнемоники S — source, R — result, SUBR vs SUBS просто своп операндов уменьшаемого и вычитаемого.

Mnemonic	I5	I4	I3	Function	Computation
SUBR	0	0	1	S Minus R	R' ⊕ S ⊕ Carry
SUBS	0	1	0	R Minus S	R ⊕ S' ⊕ Carry
2. Можете ли Вы посоветовать что-то по этой теме, но более простое и понятное (плейлист или блог, например)? Мануал практически нечитаем :(

По сравнению с процессорами в 2021, манул 1975 года читается как стихи %)

Спробуй ось ці доки покурити:
www.ecs.csun.edu/...​es/20-Microprogrammed.pdf
faculty.tarleton.edu/...​2_MARIE_after_midterm.pdf

Якщо правильно розумію,

SUBS, а для второго — SUBR

Це скорочення від
subroutine
substitution

Це скорочення від
subroutine
substitution

цеж ассемблер, які subroutine?
це різновиди інструкцій віднімання, там он вище @Mike Gorchak відповів
в x86 також є 2 інструкції — SUB та SBB

SBB только учитывает бит переноса, а не меняет операнды местами

Підписатись на коментарі