Я не найду с ходу ссылки, но делались расширения рантайма, который это проверял именно на основании описанных типов (вставлял assertʼы в рекомендованных местах). Встроиться в систему импорта в Python достаточно легко.
Но и описание для чекеров это уже неплохо, чтобы вылавливать самые грубые ошибки.
Собственно, компиляция (как проверка, а не как способ получить бинарник) — это относительно дешёвая и относительно слабая замена полноценных тестов, которая основывается на предположении, что если типы нигде не перепутаны, то всё как-нибудь выполнится.
"Полноценные тесты" с проверкой всех возможных вариантов данных, всех вариантов компиляции и так далее - для любой реальной софтины просто невозможны, потому что займут миллионы лет.
Сильная и статическая типизации - лучше обе, но и по отдельности тоже улучшение - позволяют сократить тестирование до характерных тестов - прямых и маргинальных.
В языках типа C/C++ к этому надо добавить максимальный обход undefined behavior, работы в этом направлении ведутся, хоть и слишком медленно. В более новых эта проблема чаще всего решена кардинально, даже если не слишком эффективно для работы кода.
Покрывать код тестами и прогонять их перед тем, как пускать недельные циклы.
Конкретный workflow вашего проекта имеет мало отношения к общей работе отрасли.
И я бы сказал, вообще так ставить вопрос нельзя — про преимущества статической типизации. Есть сценарии, где без неё просто нельзя обойтись. Например, задачи, для которых надо явно задать i4 или i8.
Или задачи, в которых должно быть именно целое число. Или задачи, в которых должно быть целое число от -90 до +90. Или ещё стопиццот вариантов, когда i4 или i8 это просто контейнер, слишком широкий для представимых значений, просто ближайший адекватный.
Там же наверняка (ну, я даю >95%) кобол и представление fixed decimal. Переписать будет стоить несколько миллионов только на админ. сопровождение работ.
Так-же при diff в YAML будет видно явное различие, у JSON, только если он написан с pretty форматированием, с соблюдением whitespace. у YAML этой проблемы нету, т.к. структура файла изначально определена стандартом.
Это абсолютно неверно. Для YAML это выполняется при тех же условиях: pretty форматирование. Следующие два входных YAML-файла дают один и тот же список из 2 элементов:
- Hello
- World
и
['Hello', 'World']
Чуть сложнее? Пожалуйста:
a:
aa: bb
cc: dd
b:
pp: qq
ss: tt
a:
{aa: bb, cc: dd}
b: {pp: qq,
ss: tt}
В последнем примере отступы сломаны, и ничего. Причём это самые основы, от описанного тут 1.1 vs 1.2 vs 1.2.2 не зависит.
Как известно, любой JSON документ является валидным YAML-документом. С pretty-форматированием или без него, пофиг, он валиден и должен читаться.
С другой стороны, дифф вам может показать различия, которые не имеют значения, в тех же примерах я мог написать aa: bb, а мог "aa" :"bb" и было бы то же самое. Это частая проблема, если меняется версия генератора для автоэкспортёра состояния.
Нет, любой из 5 вариантов деления обеспечивает этот инвариант, по-своему одновременно, но согласованно, определяя операции получения частного и остатка при делении.
если что-то хорошо ложащееся на математику - первый
При этом в GMP есть операция ceiling division специально для редких случаев хотения странного, но базовое у них всё равно T-деление.
Тогда не соизволите объяснить, каким образом ваше мнение должно было учитываться при переходе/не переходе с одного синтаксиса на другой? Для разработчиков Unix в то время.
А это как раз у вас тут образцовая, 300%ная демагогия. Потому что речь не о ситуации, типа, пришёл покупатель земельного участка и вдруг "почему тут сарай? я хотел именно тут пасеку", а продавец, поставивший этот сарай 40 лет назад, не мог представить себе подобного желания.
Нет, аргументы в пользу сохранения порядка аргументов (и вообще синтаксиса в целом) Intel они полностью и безоговорочно были понятны и тогда, и в их принципиальной корректности сомнений не было. А вот почему для конкретной команды исполнителей вес этих аргументов оказался ниже веса аргументов за сохранение того, к чему они привыкли в случае VAX, PDP-11 или, как предположил mpa4b@, M68k, несмотря на потенциальные проблемы при будущем расширении активно развивающейся архитектуры - вот это как раз хороший предмет для исторического исследования. И вот это вы почему-то пытаетесь заткнуть откровенной подтасовкой, типа, что здесь моё мнение, а не аргументация.
Человеку надо тратить умственные силы, чтоб "не засиживаться на месте
Но на что-то полезное. Решение кросвордов, например (пример маргинальный, но показательный) слишком малоэффективно для целей написания программ. Разворот аргументов каждый раз в голове - из этой же серии.
Проблема в том, что вы выше, уже за меня всё решили. Удобнее это мне или нет.
Я за вас ничего не решал. Вы можете для себя переделать любой язык и любой ассемблер как угодно. Посмотрите, например, на ассемблер Go для x86. Он совершенно несовместим ни с Intel, ни с AT&T - там, например, регистр зовётся AX независимо от размера данных в операции. Но его авторы имели свои цели (которые как раз озвучили), и там хотя бы известно, как они описали свои причины. И они не стараются доказать, что это лучший вариант... В случае же AT&T vs. Intel "народная" любовь статистически именно на стороне Intel, и этому причины не только в том, что владелец архитектуры гнёт в эту сторону.
Ну, возможно, да. Просто обычно в источниках пишут, что AT&T синтаксис был взят по аналогии с PDP-11. Я думаю, это уже натяжка, но на этом не акцентировал, а предполагал скорее VAX, на котором таки были образцовые Unix системы по состоянию на 1985. M68k тут как-то побоку, но как источник сомнительных решений типа "cmp p,q это источник флагов согласно q-p" вполне может прокатить...
Довольно странный вопрос. Вы знаете что делает команда cwtl? cwtd?
Пожалуйста, не делайте вид, что не поняли вопрос. Я не про понимание семантики, а про то, как из семантики дальше выводится конкретная буква окончания аббревиатуры. Тут понять невозможно, надо просто запомнить.
то при полном развороте (когда два источника, один приёмник) для синтаксиса AT&T будет достаточно правильно поменять местами именно все операнды, а не какой-то один (но это лишь догадки с моей стороны).
О! Извините, но, вероятно, вы себя тут сами засокра́тили (от имени Сократ). Получается, что синтаксис Intel всё равно исходный, и выяснение вопроса, как правильно, начинается с него... а затем зачем-то развернуть весь порядок.
Ведь в данном случае надо просто последовательно считать значения один за другим, не меняя в дальнейшем их местами.
Для чего именно? Для вычитания всё равно требуются оба аргумента, чтобы начать реальную операцию...
Для AT&T я даже не задумываюсь о том, какое идёт расширение.
Какая логика вам объясняет, когда писать cwtl, а когда - cwtd?
В том, что стали просто буквы использовать, а не полномасштабные команды.
Вы имеете в виду, наверно, указание размера одиночного аргумента в векторных командах. Да, оно там неизбежно, но размер полного набора аргументов по-прежнему определяется регистром. "Полномасштабные команды" это с указаниями типа "dword ptr"? Если нет, уточните.
И я там в последний момент дописал вопрос, вы могли не заметить. Intel:
Как так получилось, что уменьшаемое справа от вычитаемого? Ссылка на историю появления от PDP-11 тут не сработает: у PDP-11, даже, когда в "sub p, q" было вычитание p из q, при этом "cmp p, q" вычитало q из p.
Нам лишь решать использовать этот синтаксис или нет.
Именно. Поэтому, несмотря на то, что GCC и Clang по умолчанию используют AT&T syntax, и в ассемблерных кусках в ядрах и libc всяких Linux и *BSD в основном они - как только мы выходим за пределы этого поддомена, наблюдается существенный разворот в сторону Intel стиля. Я как-то анализировал наличную кодобазу в исходниках, где (в основном во всяком мультимедиа и криптографии) любят ассемблерные файлы.
Если вам этот синтаксис не удобен, то это не значит что он не удобен другим. Все ваши "недочёты", нивелируются человеком который читает код и понимает разницу между синтаксисом AT&T и Intel.
Кто занимается тут игрой слов, вопрос спорный, но я попытаюсь перейти к конструктиву. А он такой, что пропорция тех, кто предпочитает Intel, очень заметная, и за пределами тех, кто исторически с самого начала привык к AT&T, его (AT&T) очень мало хотят.
А с учётом резкого падения части X86 в разработках, где требуется ассемблер, будет падать ещё больше. Держать в голове постоянно выкрутки порядка - сложно.
Все ваши "недочёты", нивелируются человеком который читает код и понимает разницу между синтаксисом AT&T и Intel.
Можно читать не обращая внимание на язык. А можно - обращая, и это полезнее. Потому что от языка может зависеть, например, реакция на целочисленное переполнение, или отличие && в C от and у Паскаля может давать код, который просто так не перенесётся (в любую из сторон).
Недочёты нивелируются, да. Но это лишняя затрата умственных сил, порой резко заметная.
Зачем в очередной раз играть словами?
Я отвечал на ваш вопрос - "зачем перешли", а не "зачем его использовать", "зачем сохранять" и всё такое. Там, где вы видите игру слов, я вижу минимально корректный учёт того, что действительно сказал собеседник. "Игра слов" выглядит иначе.
но вы решили за разработчика что: "он должен делать так как вы сказали"!
Они сами и решают, без меня (см. соседний комментарий). В MIPS, ARM, RISC-V, куче других не только приёмник первый - это не было бы проблемой, если бы единообразно в пределах ISA он был последним - но Unix мир не меняет то, что сделано у соседей. Диверсия введена только для x86 (и, ещё раз повторюсь, не только в плане порядка аргументов). И тем не менее куда ни глянь где nasm, fasm, другие аналоги - Intel порядок тотально.
Логики нет у обоих, но у Intel хоть как-то ровнее. И, повторюсь, названные вами суффиксы не работают:))
Я бы их соответственно назвал: sexti8, sexti16, sexti32, sexto16, sexto32, sexto64 (или альтернативно: sexti ax,al; sexti eax,ax; sexti rax,eax; sexto dx,ax; sexto edx,eax; sexto rdx,rax). Но я тут не решаю.
Странно что вы не жалуетесь на формат команд SIMD-инструкций. Ведь это ближе к AT&T синтаксису, а не Intel.
В чём именно ближе? Вот с ходу из доки Intel:
66 0F 58 /r ADDPD xmm1, xmm2/m128 Add packed double precision floating-point values from xmm2/mem to xmm1 and store result in xmm1.
VEX.128.66.0F.WIG 58 /r VADDPD xmm1,xmm2, xmm3/mem Add packed double precision floating-point values from xmm3/mem to xmm2 and store result in xmm1.
Для меня синтаксис AT&T более удобен. Я к нему быстрее привык, чем к синтаксису Intel.
Попробуйте понять, почему вы думаете, что он вам более удобен. При том, что:
1) Требуется после чтения родных Intel источников каждый раз мысленно разворачивать порядок аргументов. 2) В некоторых случаях требуется делать замены логики в именовании, как в соотношении fsub :: fsubr. 3) Некоторые команды переименованы вопреки всякой логике, причём не получено от этого никакой пользы (ну-тко чем отличается ctlq от clto? Почему вообще не решили назвать как sexto и sexti, чтобы никто не путался?) 4) Порядок аргументов не соответствует подавляющему большинству конкурирующих ISA.
Стоит ли оно того?
Думаю это не нам решать, по какой причине Unix системы остались на синтаксисе AT&T, а не перешли на соседний.
Эээ... вообще-то и нам, и кому угодно. Это не попытка принять решение за других. Это поиск именно исторических причин, в том, что уже состоялось 30-35 лет назад. Вы решили запретить (нам - кому именно нам?) исследовать историю?
Это "недоразумение" существовало и использовалось ещё на PDP11.
Это само по себе не основание для переноса такого порядка на X86, при том, что для MIPS, ARM, RISC-V и прочих тот же gas использует порядок "результат первым".
В данном случае те люди, что сделали порт на 80386 для AT&T V86, заложили диверсию, которую, возможно, сами осознали, но было уже поздно.
Разворачивать все аргументы, а не только переносить приёмник вперёд... для shld, shrd в какой последовательности стоят аргументы - критично для понимания - а тут такая пакость возникла.
Вообще так называемый AT&T syntax, происходящий от прямого переноса логики PDP-11 на X86 ребятами, сделавшими вначале AT&T V86, и что перешло в SCO и затем во все юниксы на X86 - да, штука немного странная. Эффекты не только в порядке аргументов - например, в некоторых командах FPU. Но в реальности достаточно легко привыкаешь.
С точки зрения типов профессионального роста, программисту расти до начальника обычно смысла нет - он растёт квалификационно, в лестнице не поднимаясь выше того же техлида (хотя сколько человек подчиняются его решениям, не определено - могут быть и миллионы).
Зато для QA карьера до тимлида и выше - самое оно: сохраняя принципиальную техническую компетентность, он её только улучшает от такого роста. (Разумеется, если это грамотный разносторонний QA, а не просто тестер.)
Для принятия принципиальных решений вроде какую архитектуру выбрать - у него есть возможность заслушать разных экспертов. Так работает уже давно за пределами IT, где не важно, например, что начальник подразделения может не знать сам какие-нибудь параметры твёрдости конкретной марки стали.
Always call sys_icache_invalidate(::) before you execute the machine instructions on a recently updated memory page.
Вообще, отсутствие автоматической связи здесь и есть если не норма, то по крайней мере то, что надо всегда предполагать. X86 с его TSO и кучей моментов неявной автопомощи программисту здесь исключение (во многом себе во вред) даже для мира CISC.
Сайт сглючил и не дал дописать - что вообще-то вы задаёте вопрос немного не о том. Я в предыдущем комментарии писал не о собственно трекинге зависимостей и что для него нужно, а что кроме этого трекинга должен кто-то понимать, в чём собственно зависимость тех других проектов/компонентов и насколько можно вообще развивать/изменять и в каких направлениях. В такой среде это вполне возможно, хоть и требует постоянной работы со стороны майнтейнеров. А без этого знания легко запланировать какое-то изменение, которое кажется разумным, но будет настолько несовместимо с текущим использованием, что приведёт к форку...
Проще тогда в самом проекте, если он такой важный, перед мерджем PR проверять, что его известные зависимости не ломаются.
Ну вот я и думаю, что это дело CI. Если что-то ломается на его тесте, отправка (push/merge/submit/как_хочешь_назови) не должна проходить (без разрешения кого-то очень важного). А вот как именно CI вычисляет, что зависит, должно поддерживаться как я описал ранее.
А вот это надо решать административными методами. Правило в циркуляре под роспись о том, что введение любой непосредственной зависимости должно хотя бы постфактум порождать тикет об этом, который дальше прорабатывается держателями библиотеки.
Или, если есть указания прямых зависимостей, которые легко ищутся и парсятся, для CI, можно сделать робота, который по изменению этих зависимостей (как в плюс так и в минус) оповещает об этом (и тоже создаёт тикет).
Все средства для этого обычно у команды есть, осталось только интеграции добавить...
Я не найду с ходу ссылки, но делались расширения рантайма, который это проверял именно на основании описанных типов (вставлял assertʼы в рекомендованных местах). Встроиться в систему импорта в Python достаточно легко.
Но и описание для чекеров это уже неплохо, чтобы вылавливать самые грубые ошибки.
"Полноценные тесты" с проверкой всех возможных вариантов данных, всех вариантов компиляции и так далее - для любой реальной софтины просто невозможны, потому что займут миллионы лет.
Сильная и статическая типизации - лучше обе, но и по отдельности тоже улучшение - позволяют сократить тестирование до характерных тестов - прямых и маргинальных.
В языках типа C/C++ к этому надо добавить максимальный обход undefined behavior, работы в этом направлении ведутся, хоть и слишком медленно. В более новых эта проблема чаще всего решена кардинально, даже если не слишком эффективно для работы кода.
Конкретный workflow вашего проекта имеет мало отношения к общей работе отрасли.
Или задачи, в которых должно быть именно целое число. Или задачи, в которых должно быть целое число от -90 до +90. Или ещё стопиццот вариантов, когда i4 или i8 это просто контейнер, слишком широкий для представимых значений, просто ближайший адекватный.
И какие "остальные гипотезы" тут могут быть?
Инопланетян не включаем. Вариант с 2 планетами и больше - нет данных, чтобы отличить его.
Это нормальный научный процесс, обозначить проблему и дать максимально возможный с текущими данными и технологиями вариант ответа.
Там же наверняка (ну, я даю >95%) кобол и представление fixed decimal. Переписать будет стоить несколько миллионов только на админ. сопровождение работ.
Это абсолютно неверно. Для YAML это выполняется при тех же условиях: pretty форматирование. Следующие два входных YAML-файла дают один и тот же список из 2 элементов:
и
Чуть сложнее? Пожалуйста:
В последнем примере отступы сломаны, и ничего. Причём это самые основы, от описанного тут 1.1 vs 1.2 vs 1.2.2 не зависит.
Как известно, любой JSON документ является валидным YAML-документом. С pretty-форматированием или без него, пофиг, он валиден и должен читаться.
С другой стороны, дифф вам может показать различия, которые не имеют значения, в тех же примерах я мог написать aa: bb, а мог "aa" :"bb" и было бы то же самое. Это частая проблема, если меняется версия генератора для автоэкспортёра состояния.
Так что советую переуточнить своё представление.
Нет, любой из 5 вариантов деления обеспечивает этот инвариант, по-своему одновременно, но согласованно, определяя операции получения частного и остатка при делении.
При этом в GMP есть операция ceiling division специально для редких случаев хотения странного, но базовое у них всё равно T-деление.
А это как раз у вас тут образцовая, 300%ная демагогия. Потому что речь не о ситуации, типа, пришёл покупатель земельного участка и вдруг "почему тут сарай? я хотел именно тут пасеку", а продавец, поставивший этот сарай 40 лет назад, не мог представить себе подобного желания.
Нет, аргументы в пользу сохранения порядка аргументов (и вообще синтаксиса в целом) Intel они полностью и безоговорочно были понятны и тогда, и в их принципиальной корректности сомнений не было. А вот почему для конкретной команды исполнителей вес этих аргументов оказался ниже веса аргументов за сохранение того, к чему они привыкли в случае VAX, PDP-11 или, как предположил mpa4b@, M68k, несмотря на потенциальные проблемы при будущем расширении активно развивающейся архитектуры - вот это как раз хороший предмет для исторического исследования. И вот это вы почему-то пытаетесь заткнуть откровенной подтасовкой, типа, что здесь моё мнение, а не аргументация.
Но на что-то полезное. Решение кросвордов, например (пример маргинальный, но показательный) слишком малоэффективно для целей написания программ. Разворот аргументов каждый раз в голове - из этой же серии.
Я за вас ничего не решал. Вы можете для себя переделать любой язык и любой ассемблер как угодно. Посмотрите, например, на ассемблер Go для x86. Он совершенно несовместим ни с Intel, ни с AT&T - там, например, регистр зовётся AX независимо от размера данных в операции. Но его авторы имели свои цели (которые как раз озвучили), и там хотя бы известно, как они описали свои причины. И они не стараются доказать, что это лучший вариант... В случае же AT&T vs. Intel "народная" любовь статистически именно на стороне Intel, и этому причины не только в том, что владелец архитектуры гнёт в эту сторону.
Ну, возможно, да. Просто обычно в источниках пишут, что AT&T синтаксис был взят по аналогии с PDP-11. Я думаю, это уже натяжка, но на этом не акцентировал, а предполагал скорее VAX, на котором таки были образцовые Unix системы по состоянию на 1985. M68k тут как-то побоку, но как источник сомнительных решений типа "cmp p,q это источник флагов согласно q-p" вполне может прокатить...
Пожалуйста, не делайте вид, что не поняли вопрос. Я не про понимание семантики, а про то, как из семантики дальше выводится конкретная буква окончания аббревиатуры. Тут понять невозможно, надо просто запомнить.
О! Извините, но, вероятно, вы себя тут сами засокра́тили (от имени Сократ). Получается, что синтаксис Intel всё равно исходный, и выяснение вопроса, как правильно, начинается с него... а затем зачем-то развернуть весь порядок.
Для чего именно? Для вычитания всё равно требуются оба аргумента, чтобы начать реальную операцию...
Какая логика вам объясняет, когда писать cwtl, а когда - cwtd?
Вы имеете в виду, наверно, указание размера одиночного аргумента в векторных командах. Да, оно там неизбежно, но размер полного набора аргументов по-прежнему определяется регистром. "Полномасштабные команды" это с указаниями типа "dword ptr"? Если нет, уточните.
И я там в последний момент дописал вопрос, вы могли не заметить. Intel:
Но AT&T:
Как так получилось, что уменьшаемое справа от вычитаемого? Ссылка на историю появления от PDP-11 тут не сработает: у PDP-11, даже, когда в "sub p, q" было вычитание p из q, при этом "cmp p, q" вычитало q из p.
Именно. Поэтому, несмотря на то, что GCC и Clang по умолчанию используют AT&T syntax, и в ассемблерных кусках в ядрах и libc всяких Linux и *BSD в основном они - как только мы выходим за пределы этого поддомена, наблюдается существенный разворот в сторону Intel стиля. Я как-то анализировал наличную кодобазу в исходниках, где (в основном во всяком мультимедиа и криптографии) любят ассемблерные файлы.
Кто занимается тут игрой слов, вопрос спорный, но я попытаюсь перейти к конструктиву. А он такой, что пропорция тех, кто предпочитает Intel, очень заметная, и за пределами тех, кто исторически с самого начала привык к AT&T, его (AT&T) очень мало хотят.
А с учётом резкого падения части X86 в разработках, где требуется ассемблер, будет падать ещё больше. Держать в голове постоянно выкрутки порядка - сложно.
Можно читать не обращая внимание на язык. А можно - обращая, и это полезнее. Потому что от языка может зависеть, например, реакция на целочисленное переполнение, или отличие && в C от and у Паскаля может давать код, который просто так не перенесётся (в любую из сторон).
Недочёты нивелируются, да. Но это лишняя затрата умственных сил, порой резко заметная.
Я отвечал на ваш вопрос - "зачем перешли", а не "зачем его использовать", "зачем сохранять" и всё такое. Там, где вы видите игру слов, я вижу минимально корректный учёт того, что действительно сказал собеседник. "Игра слов" выглядит иначе.
Они сами и решают, без меня (см. соседний комментарий). В MIPS, ARM, RISC-V, куче других не только приёмник первый - это не было бы проблемой, если бы единообразно в пределах ISA он был последним - но Unix мир не меняет то, что сделано у соседей. Диверсия введена только для x86 (и, ещё раз повторюсь, не только в плане порядка аргументов). И тем не менее куда ни глянь где nasm, fasm, другие аналоги - Intel порядок тотально.
cwtd. Опечатался немного, потому что там логики 0 целых фиг десятых. И вы тут таки неправы:
потому что эта группа команд этим правилам не следует аж никак:
AT&T:
Но Intel:
Логики нет у обоих, но у Intel хоть как-то ровнее. И, повторюсь, названные вами суффиксы не работают:))
Я бы их соответственно назвал: sexti8, sexti16, sexti32, sexto16, sexto32, sexto64 (или альтернативно: sexti ax,al; sexti eax,ax; sexti rax,eax; sexto dx,ax; sexto edx,eax; sexto rdx,rax). Но я тут не решаю.
В чём именно ближе? Вот с ходу из доки Intel:
66 0F 58 /r ADDPD xmm1, xmm2/m128
Add packed double precision floating-point values from xmm2/mem to xmm1 and store result in xmm1.
VEX.128.66.0F.WIG 58 /r VADDPD xmm1,xmm2, xmm3/mem
Add packed double precision floating-point values from xmm3/mem to xmm2 and store result in xmm1.
Приёмник снова первый. Где тут "ближе к AT&T"?
Кстати, вы вспомнили SIMD?
Почему вычитаемое слева от уменьшаемого? ;))
Попробуйте понять, почему вы думаете, что он вам более удобен. При том, что:
1) Требуется после чтения родных Intel источников каждый раз мысленно разворачивать порядок аргументов.
2) В некоторых случаях требуется делать замены логики в именовании, как в соотношении fsub :: fsubr.
3) Некоторые команды переименованы вопреки всякой логике, причём не получено от этого никакой пользы (ну-тко чем отличается ctlq от clto? Почему вообще не решили назвать как sexto и sexti, чтобы никто не путался?)
4) Порядок аргументов не соответствует подавляющему большинству конкурирующих ISA.
Стоит ли оно того?
Эээ... вообще-то и нам, и кому угодно. Это не попытка принять решение за других. Это поиск именно исторических причин, в том, что уже состоялось 30-35 лет назад. Вы решили запретить (нам - кому именно нам?) исследовать историю?
Это само по себе не основание для переноса такого порядка на X86, при том, что для MIPS, ARM, RISC-V и прочих тот же gas использует порядок "результат первым".
В данном случае те люди, что сделали порт на 80386 для AT&T V86, заложили диверсию, которую, возможно, сами осознали, но было уже поздно.
Самая "мякотка" в этой диверсии в ситуациях типа:
Разворачивать все аргументы, а не только переносить приёмник вперёд... для shld, shrd в какой последовательности стоят аргументы - критично для понимания - а тут такая пакость возникла.
Можно включить Intel syntax.
Вообще так называемый AT&T syntax, происходящий от прямого переноса логики PDP-11 на X86 ребятами, сделавшими вначале AT&T V86, и что перешло в SCO и затем во все юниксы на X86 - да, штука немного странная. Эффекты не только в порядке аргументов - например, в некоторых командах FPU. Но в реальности достаточно легко привыкаешь.
С точки зрения типов профессионального роста, программисту расти до начальника обычно смысла нет - он растёт квалификационно, в лестнице не поднимаясь выше того же техлида (хотя сколько человек подчиняются его решениям, не определено - могут быть и миллионы).
Зато для QA карьера до тимлида и выше - самое оно: сохраняя принципиальную техническую компетентность, он её только улучшает от такого роста. (Разумеется, если это грамотный разносторонний QA, а не просто тестер.)
Для принятия принципиальных решений вроде какую архитектуру выбрать - у него есть возможность заслушать разных экспертов. Так работает уже давно за пределами IT, где не важно, например, что начальник подразделения может не знать сам какие-нибудь параметры твёрдости конкретной марки стали.
Вообще, отсутствие автоматической связи здесь и есть если не норма, то по крайней мере то, что надо всегда предполагать. X86 с его TSO и кучей моментов неявной автопомощи программисту здесь исключение (во многом себе во вред) даже для мира CISC.
Сайт сглючил и не дал дописать - что вообще-то вы задаёте вопрос немного не о том. Я в предыдущем комментарии писал не о собственно трекинге зависимостей и что для него нужно, а что кроме этого трекинга должен кто-то понимать, в чём собственно зависимость тех других проектов/компонентов и насколько можно вообще развивать/изменять и в каких направлениях. В такой среде это вполне возможно, хоть и требует постоянной работы со стороны майнтейнеров. А без этого знания легко запланировать какое-то изменение, которое кажется разумным, но будет настолько несовместимо с текущим использованием, что приведёт к форку...
Ну вот я и думаю, что это дело CI. Если что-то ломается на его тесте, отправка (push/merge/submit/как_хочешь_назови) не должна проходить (без разрешения кого-то очень важного). А вот как именно CI вычисляет, что зависит, должно поддерживаться как я описал ранее.
А вот это надо решать административными методами. Правило в циркуляре под роспись о том, что введение любой непосредственной зависимости должно хотя бы постфактум порождать тикет об этом, который дальше прорабатывается держателями библиотеки.
Или, если есть указания прямых зависимостей, которые легко ищутся и парсятся, для CI, можно сделать робота, который по изменению этих зависимостей (как в плюс так и в минус) оповещает об этом (и тоже создаёт тикет).
Все средства для этого обычно у команды есть, осталось только интеграции добавить...