Обычно я использую ассемблер, чтобы дополнить то, что компилятор C не может сделать, а также возможности языка ассемблера, который он не может или не может реализовать, когда я этого тоже хочу. Или в местах, где мне нужна производительность либо через знание набора данных и инструкций, либо через знание аппаратного обеспечения, которое не знает компилятор. Выравнивание чего-либо со строкой кэша или знанием ширины или характера шины данных, буфера записи и т. Д. Загрузочного кода для встроенного кода, основной части кода на C, но некоторых разделов на ассемблере по вышеуказанным причинам. Иногда ассемблер является уровнем абстракции для встраиваемых систем, и для повторной компиляции приложения в операционной системе используется другой уровень абстракции.
Некоторые люди пишут на ассемблере для всего проекта (сегодня), и это кажется мне скорее политическим, чем практическим. Чтобы доказать, что это может быть сделано, или личная цель или царапина, которые нужно было чесаться. Подобно восхождению на гору, потому что она там, некоторые делают это для личного внутреннего умственного или физического обогащения и приносят им пользу, другие делают это строго для того, чтобы хвастаться и хвастаться, стыдить их. Для больших приложений компилятор (сегодня) будет лучше выполнять код в среднем, выполняя код вручную, и, в конце концов, rtos или все, что вы сделали, может быть скомпилировано и запущено на многих машинах, а не только на ассемблер для одного процессора, который вы выбрали.
Я делаю много встроенных работ, и некоторые из них - микроконтроллеры. Я часто выбираю (все) ассемблер для этих программ по ряду причин: периферийные устройства, регистры и входы / выходы на этом микроконтроллере не переносимы на какой-либо другой микроконтроллер, поэтому не переносимость ассемблера не является проблемой. Память часто очень ограничена, а наборы команд часто неэффективны и не дружественны к компилятору (это не значит, что нет компиляторов). И самое главное (кросс-компиляторы с открытым исходным кодом / без) написаны не таким образом и не поддерживаются таким образом, чтобы они работали год за годом по мере изменения и улучшения операционных систем (Linux), где ассемблеры часто проще и больше шансов продолжить работу из года в год. Другая причина в том, что я иногда покупал этот микроконтроллер просто для того, чтобы изучить набор инструкций и внутреннюю микросхему и узнать, как она может быть лучше или хуже других. И C-вызовы библиотек в SDK мне не помогут.
Я был еще в тот день, когда C переходил от Pascal, и мне задавали тот же вопрос, и можно было показать, что некоторые могут кодировать и отлаживать приложение на ассемблере, а другие могут кодировать и отлаживать на C в примерно столько же времени Тогда все было проще. В обоих мирах вы не создаете все с нуля, точно так же, как когда вы едете на работу и с работы, ваши ноги и руки имеют эту память и ездят в автопилоте, одна и та же скучная дорога день за днем, большая часть ваших программ выполняется в автопилоте, Вы вырезаете и вставляете или повторно вводите или ссылаетесь на те же самые процедуры, которые вы полировали всю свою карьеру. В ассемблере вы повторно используете те же самые любимые инструкции и никогда не используете другие, в C вы используете те же самые любимые переменные или языковые функции и никогда не используете другие. Это человек, а не язык.
Итак, чтобы ответить на ваш вопрос. Макросы и функции и повторное использование ранее разработанного кода или библиотек, так же, как вы могли бы использовать макросы и функции или ранее разработанный код или библиотеки сегодня на языке высокого уровня. Вы были более внимательны и осторожны с программистом, высокого или низкого уровня, ресурсы (память, диск и т. Д.) Были не такими, какими они являются сегодня, регистры / переменные были выбраны тщательно и экономно. Компиляторы Си были далеко не так хороши, они едва компилировались и были менее оптимизированы. И, как и любой язык, автомобиль, клавиатура или мышь, чем больше вы используете их, тем эффективнее вы ее используете. Опытный программист на ассемблере может превзойти новичка так же, как опытный программист на Си может превзойти новичка. То, сможет ли опытный программист на ассемблере превзойти программиста на С, зависит как от отдельных лиц, так и от приложения, и не только от языка.
Структуры - это решение, позволяющее сэкономить на печати для некоторых языков. Ассемблер позволяет вам использовать один и тот же базовый адрес + (индекс * размер структуры) + вычисление смещения и многое другое. Некоторые наборы команд делают это намного проще, и некоторые программисты могут поменять множитель на смену или смену плюс сложение. Или используйте умножение накапливать.
Строки - это то, где ассемблер действительно сияет. Самые крутые трюки на ассемблере можно найти в функциях string и copy в библиотеках C. Если вы собираете весь ассемблер, вы можете использовать паскаль плюс данные или C идти до тех пор, пока вы не достигнете нуля или не смешаете и не сопоставляете, или составляете свои собственные. Вы можете или не можете улучшить библиотеку C в этой области, но неоптимизированный строковый код одинаково тривиален в C и ассемблере.
Вызов вызовов os / C от ассемблера. Загрузочный код часто вызывает memcpy для .data и memset для .bss. Если вы хотите вызвать библиотеку C, вы, вероятно, находитесь в лагере «Я использую C для всего приложения и ассемблер для нескольких редких случаев». «Я пишу всю эту вещь в лагере ассемблеров» не будет использовать этот ярлык, они не будут программировать на ассемблере, если бы это было так. Вызовы операционной системы должны выполняться в любом случае, и нет другого пути, кроме как написать свою операционную систему на ассемблере и делать то, что вы хотите.
Объединения - это просто повторное использование одного и того же пространства памяти, вы можете делать что угодно и переопределять любой байт в памяти, как считаете нужным. Assebler не связывает вам руки и не заставляет вас ходить и думать определенным образом, как это делает язык высокого уровня.
Текстовый редактор или ide не имеют ничего общего с языком, личностями и их привычками / предпочтениями. Иногда проект или компания вынуждают использовать инструмент, которым вы пользуетесь, или получаете другую работу или продвигаетесь достаточно высоко, чтобы изменить политику компании. Текстовые редакторы, инструменты, вкладки, пробелы, тезисы - очень трогательные темы в профессиональной среде, это все равно, что заставлять всех водить одну и ту же марку и модель автомобиля или носить ту же марку и модель обуви. Это не имеет ничего общего с языком. С другой стороны, есть случайный процессор, который имеет только один инструмент только в одной среде, и если вы решите использовать тот процессор, который вы используете.
Системная инженерия важна и часто упускается из виду или делается плохо. Когда это сделано и сделано правильно, тогда вызов соглашения между определенными модулями автоматически выпадает из процесса. Решение использовать везде одно и то же соглашение или настроить соглашение для модулей с обеих сторон, также является частью этого процесса системного проектирования. Для ассемблера сегодня вы с большей вероятностью найдете соглашение о вызовах C, используемое или близкое к нему, с некоторыми изменениями для производительности (ну, я знаю, что мне не нужно сохранять R4 для этой функции, потому что я знаю, что везде, где я использую эту функцию, я никогда не буду собираюсь использовать R4) просто потому, что он хорошо известен и в наши дни тщательно спроектирован, и вы никогда не знаете, когда захотите вызвать эту классную функцию, которую вы написали из C, или поделиться с другом по программированию на C.
Если вы хотите уйти далеко назад, вы говорите о долях времени или более старых, когда аппаратное обеспечение едва работало, и у вас было много времени, чтобы вручную закодировать биты машинного языка до того, как машина будет восстановлена. И у вас все равно не было терминала или клавиатуры. Или, немного новее, у вас была доля времени, когда вам, возможно, приходилось запускать вашу программу один раз в день или раз в несколько дней, так что у вас было куча времени для создания дополнительных перфокарт, и снова у вас не было терминала, клавиатуры или текстового редактора. Ваш язык высокого уровня был, вероятно, Fortran, если что-нибудь. Вы были рады, что ваша программа немного поработала, прежде чем она рухнула, и мысли о том, сколько тысяч строк отлаженного кода, которые вы можете создать за неделю, еще не были изобретены.