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

Почему это? Это просто потому, что старые привычки трудно сломать, или есть более веские причины?

Например:

• Atmel ATMEGA32U2 (2010?): TIFR1(Вместо TimerCounter1InterruptFlag), ICR1H(вместо InputCapture1High), DDRB(вместо DataDirectionPortB) и т. Д.
• Набор команд .NET CLR (2002): bge.s(вместо branch-if-greater-or-equal.short) и т. Д.

Не проще ли работать с длинными, не зашифрованными именами?

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

Кроме того, если ваш основной аргумент касается физического пространства на бумажной диаграмме , учтите, что это абсолютно не относится к языку ассемблера или CIL, плюс я был бы признателен, если бы вы показали мне диаграмму, где краткие имена подходят, но читаемые из них ухудшают диаграмму , Исходя из личного опыта в компании Fabless Semiconductor, легко читаемые имена подходят и приводят к более читаемым диаграммам.

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

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

Это поднимает вопрос о том, почему таблицы используют короткие имена. Вероятно, это потому, что вам часто нужно представлять имена в таких таблицах, где у вас нет места для 25-символьных идентификаторов:

Кроме того, такие вещи, как схемы, схемы выводов и шелкографии на печатных платах, часто очень ограничены в пространстве.

Закон Ципфа

Посмотрев на этот текст, вы сами увидите, что длина слова и частота употребления, как правило, обратно пропорциональны. Слова, которые используются очень часто, как it, a, but, youи andочень короткие, в то время как слова, которые используются реже нравится observe, comprehensionи verbosityбольше. Эта наблюдаемая связь между частотой и длиной называется законом Ципфа .

Количество команд в наборе команд для данного микропроцессора обычно исчисляется десятками или сотнями. Например, кажется, что набор команд Atmel AVR содержит около сотни различных инструкций (я не считал), но многие из них являются вариациями на общую тему и имеют очень похожую мнемонику. Например, инструкции умножения включают в себя MUL, MULS, MULSU, FMUL, FMULS и FMULSU. Вам не нужно долго просматривать список инструкций, прежде чем вы получите общее представление о том, что инструкции, начинающиеся с «BR», являются ветвями, инструкции, начинающиеся с «LD», являются нагрузками и т. Д. То же самое относится и к переменным: даже сложные процессоры предоставляют ограниченное количество мест для хранения значений: регистры условий, регистры общего назначения и т. д.

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

Кроме того, наборы команд для разных процессоров часто используют одинаковые имена для похожих операций. Большинство наборов команд включают операции для ADD, MUL, SUB, LD, ST, BR, NOP, и если они не используют эти точные имена, они обычно используют имена, которые очень близки. Как только вы изучите мнемонику для одного набора команд, адаптация к наборам команд для других устройств не займет много времени. Так имена , которые могут показаться «загадочными» к вам о том, как знакомые , как такие слова , как and, orи notдля программистов, специалисты в данной области техники программирования низкого уровня. Я думаю, что большинство людей, которые работают на уровне сборки, скажут вам, что обучение чтению кода не является одной из самых больших проблем в низкоуровневом программировании.

В общем

Качество именования - это не только наличие описательных имен, оно также должно учитывать другие аспекты, и это приводит к рекомендациям, таким как:

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

Обратите внимание, что эти рекомендации противоречивы.

Инструкция по мнемонике

Как программист на ассемблере, использование short-branch-if-greater-or-equalfor bge.sдает мне то же впечатление, что и когда я вижу, как программист Algol SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSвместо вычислительной геометрии dx := p2.x - p1.x. Я просто не могу согласиться с тем, что первые из них более читабельны в контексте, о котором я забочусь.

Зарегистрировать имена

Вы выбираете официальное название из документации. Документация выбирает имя из дизайна. В дизайне используется множество графических форматов, в которых длинные имена не подходят, и команда разработчиков будет жить с этими именами месяцами, если не годами. По обеим причинам они не будут использовать «Флаг прерывания счетчика первого таймера», они будут сокращать его как в своей схеме, так и при разговоре. Они знают это и используют систематические сокращения, TIFR1чтобы избежать путаницы. Здесь TIFR1важно отметить, что это не случайное сокращение, а результат схемы именования.

Помимо причин «старых привычек», код Legacy, написанный 30 лет назад и до сих пор используемый, очень распространен. Несмотря на то, что думают некоторые менее опытные люди, рефакторинг этих систем, чтобы они выглядели красиво, стоил очень дорого за небольшую выгоду и не был коммерчески выгодным.

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

Насколько bge.sэто похоже на ассемблер - тем немногим, кому нужно это знать, более длинные имена менее читабельны. Если вы не можете заставить себя bge.sзадуматься и думаете, что branch-if-greater-or-equal.shortэто что- то изменит - вы просто играете с CLR и не знаете этого.

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

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

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

Итак, вот краткое изложение ответов, опубликованных другими здесь. Я публикую это как CW, и я намерен в конечном итоге отметить это как принятое. Пожалуйста, отредактируйте, если я что-то пропустил. Я пытался перефразировать каждую идею, чтобы выразить ее кратко, но четко.

Так почему загадочные короткие идентификаторы так распространены в низкоуровневом программировании?

• Потому что многие из них достаточно распространены в соответствующей области, чтобы гарантировать очень короткое имя. Это ухудшает кривую обучения, но является ценным компромиссом, учитывая частоту использования.
• Потому что обычно есть небольшой набор исправляемых возможностей (программист не может добавить в набор).
• Потому что читабельность - это вопрос привычки и практики. branch-if-greater-than-or-equal.shortявляется изначально более читаемым , чем bge.s, но с некоторой практикой ситуация становится обратной.
• Потому что их часто приходится печатать полностью вручную, потому что языки низкого уровня часто не поставляются с мощными IDE, которые имеют хорошее автозаполнение, или / c не является надежным.
• Потому что иногда желательно упаковать много информации в идентификатор, а читаемое имя будет недопустимо длинным даже по стандартам высокого уровня.
• Потому что именно так исторически выглядели среды низкого уровня. Нарушение привычки требует сознательных усилий, рискует раздражать тех, кому нравятся старые способы, и должно быть оправдано как стоящее. Придерживаться установленного способа является «по умолчанию».
• Потому что многие из них происходят из других источников, таких как схемы и таблицы данных. На них, в свою очередь, влияют космические ограничения.
• Потому что люди, отвечающие за присвоение имен, никогда не задумывались о читабельности, или не осознают, что создают проблемы, или ленивы.
• Потому что в некоторых случаях имена стали частью протокола для обмена данными, например, использование ассемблера в качестве промежуточного представления некоторыми компиляторами.
• Потому что этот стиль мгновенно узнаваем как низкоуровневый и, следовательно, выглядит круто для гиков.

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

Я собираюсь бросить свою шляпу в этот беспорядок.

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

Некоторые, однако, служат определенной цели. Конечно, BranchGreaterThan был бы намного более читабельным, чем BGT , но сейчас существует соглашение, это инструкция, и, как таковая, она приобрела некоторую популярность за последние 30 лет использования в качестве стандарта. Почему они начали с этого, возможно, какой-то произвольный предел ширины символов для инструкций, переменных и тому подобного; почему они держат это, это стандарт. Этот стандарт такой же, как использование int в качестве идентификатора, было бы более легко использовать Integer во всех случаях, но это необходимо для тех, кто программирует более нескольких недель ... нет. Почему? Потому что это стандартная практика.

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

Дизайнер имеет некоторый контроль над этим, но, как и любой другой язык / поле, существуют соглашения, которые следуют от оборудования к оборудованию, и поэтому должны оставаться одинаковыми для каждого языка ассемблера. Я могу посмотреть на фрагмент сборки и получить суть кода, даже не используя этот набор инструкций, потому что они придерживаются соглашения, LDA или некоторого отношения к нему, вероятно, загрузка регистра MV , вероятно, перемещает что-то откуда-то в в другом месте речь идет не о том, что вы считаете хорошим, или о практике высокого уровня, это язык сам по себе, и, как таковой, имеет свои собственные стандарты и означает, что вы, как дизайнер, должны следовать, зачастую они не так произвольны, как они кажутся.

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

Одна из причин, по которой они используют загадочные короткие идентификаторы, заключается в том, что они не загадочны для разработчиков. Вы должны понимать, что они работают с ним каждый день, и эти имена действительно являются доменными именами. Таким образом, они знают наизусть, что именно означает TIFR1.

Если новый разработчик придет в команду, ему придется прочитать таблицы данных (как объясняет @KarlBielefeldt), чтобы им было удобно с ними.

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

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

Резюме

Инициализм является распространенным явлением во многих технических и нетехнических кругах. Как таковая, она не ограничивается программированием низкого уровня. Для общего обсуждения см. Статью в Википедии об аббревиатуре . Мой ответ относится только к низкоуровневому программированию.

Причины загадочных имен:

1. Низкоуровневые инструкции строго типизированы
2. Нужно упаковать много информации о типе в название инструкции низкого уровня
3. Исторически, односимвольные коды использовались для упаковки информации о типе.

Решения и их недостатки:

1. Существуют современные низкоуровневые схемы именования, которые более последовательны, чем исторические.
   • LLVM
2. Однако необходимость упаковки большого количества информации о типах все еще существует.
   • Таким образом, загадочные сокращения все еще можно найти повсюду.
3. Улучшенная читаемость между строками поможет начинающему программисту низкого уровня быстрее освоить язык, но не поможет с пониманием больших частей низкоуровневого кода.

Полный ответ

(A) Более длинные имена возможны. Например, имена встроенных в C ++ SSE2 в среднем составляют 12 символов по сравнению с 7 символами в мнемонике сборки. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) Затем возникает вопрос: сколько времени / некриптику нужно получить из низкоуровневых инструкций?

(С) Теперь мы проанализируем состав таких схем именования. Ниже приведены две схемы именования для одной и той же инструкции низкого уровня:

• Схема именования № 1: CVTSI2SD
• Схема именования № 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

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

(C.2) Каждая инструкция низкого уровня должна кодировать много информации о типе в свое имя. Примеры информации:

• Архитектура Семья
• операция
• Аргументы (входы) и выходы
• Типы (целое число со знаком, целое число без знака, число с плавающей запятой)
• Точность (битовая ширина)

(C.3) Если каждая часть информации прописана, программа будет более многословной.

(C.4) Схемы кодирования типов, используемые различными поставщиками, имеют давние исторические корни. Например, в наборе команд x86:

• B означает байт (8 бит)
• W означает слово (16 бит)
• D означает слово «двойное слово» (32-разрядное)
• Q означает слово "quad-word" (64-разрядное)
• DQ означает dqword «двойное четверное слово» (128 бит)

Эти исторические ссылки не имели никакого современного значения вообще, но все еще остаются вокруг. Более последовательная схема поместила бы значение ширины в бит (8, 16, 32, 64, 128) в имя.

Напротив, LLVM является правильным шагом в направлении последовательности в низкоуровневых инструкциях: http://llvm.org/docs/LangRef.html#functions

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

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

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

В основном это идиоматично. Как говорит @TMN в других местах, так же, как вы не пишете import JavaScriptObjectNotationили import HypertextTransferProtocolLibraryна Python, вы не пишете Timer1LowerHalf = 0xFFFFна C. Это выглядит одинаково нелепо в контексте. Каждый, кто должен знать, уже знает.

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

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

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Теперь единственная существующая IDE, которая будет анализировать это, является собственной IDE HiTech ( HiTide ). В любом другом редакторе вам придется каждый раз печатать его вручную, из памяти. Это очень быстро стареет.

Также есть тот факт, что при использовании инструментов разработки для проверки регистров у вас часто будет отображаться таблица с несколькими столбцами (имя регистра, значение в шестнадцатеричном формате, значение в двоичном формате, последнее значение в шестнадцатеричном формате и т. Д.). Длинные имена означают, что вы должны расширить столбец имени до 13 символов, чтобы увидеть разницу между двумя регистрами, и сыграть «найдите разницу» между десятками строк повторяющихся слов.

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

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

1. Научная база программиста.
2. Навыки программирования программиста.
3. Среда программиста.

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

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

Объяснение второго аспекта: поскольку большинство программистов не являются программистами, их навыки программирования ограничены. Вот почему они часто не заботятся о соглашениях по кодированию, но больше о соглашениях по конкретным областям, как указано в первом аспекте. Также, если вы не обладаете навыками программиста, у вас нет понимания соглашений о кодировании. Я думаю, что большинство из них не видит острой необходимости писать понятный код. Это как огонь и забыть.

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