) боец" в делах программирования МК, написал пока одну единственную программку на ASM, но тем не менее в голове появляются мысли на сабжевую тему, и я решился их обнародовать - вдруг кому интересно и может кто что подскажет Речь, собственно, о коде. Давайте примем допущение (в общем случае не всегда верное), что аппаратная часть (сам МК, его обвязка, внешняя периферия и т.п.) у нас работает правильно и в полном соответствии с даташитом - хотя бы собственно сам МК, за всю обвязку и периферию обещать трудно. Что те ASM команды, которые в него прошиты, он выполняет четко и правильно. Разумеется, на этом низком уровне абстракции нельзя сказать, какое поведение МК и всей системы где он работает является "правильным", а какое "ошибкой" - может разработчик хотел именно этого поведения. И тут мы выходим на персону(ы) разработчика(ов) - как неких субъектов, имеющих свои мысли, и желающих соответствующего поведения системы. Для этого они декомпозируют задачу на подзадачи, составляют схему аппаратной реализации, выбирают МК и пишут для него код. А потом нередко получают "ошибочное поведение" системы или она "вообще не работает". На первый взгляд, причины этого можно записать в следующем порядке приоритетов (очень навскидку и упрощенно):
1) задача не решается в принципе
2) ограничения в технических характеристиках выбранной элементной базы
3) ошибки в логике общего алгоритма работы устройства
4) ошибки проектирования блок-схемы или принципиальной схемы устройства
5) всевозможные "баги" с точки зрения разработчика - от непропая контакта до ошибки в коде
Если остановиться только на п.5 (хотя все предыдущие часто имеют к нему отношение тоже), то можно сказать, что разработчику не удается донести свои мысли до МК (который, как мы предположили, работает без ошибок)
Вернемся к коду. Если он написан на ASM, то разработчик "сам дурак" - не смог продумать в логике работы RISC все свои желания - и пожинает плоды этого. Человеку трудно думать как МК, поэтому волшебники "K&R" (С) придумали С. Разработали стандарт, по которому всё более умные с течением времени компиляторы делают из разработчик-ориентированного кода "чистый и красивый ASM" - насколько это возможно в каждом случае. Контроллеру исходник С не нужен, его потребляет компилятор. Значит, по меньшей мере, надо знать его "повадки" - куда в память он будет что распределять и засовывать/брать, какую оптимизацию в каких случаях применит и т.п. "Иногда" при этом не лишне придерживаться стандарта С и знать архитектуру конкретного МК. Но это не исключает необходимости знать "повадки" компилятора, который, кстати, может при разных настройках оптимизации и прочего по одному исходнику С сгенерить работающий и "ошибочный" код.
Продолжу. Наглядность кода С компилятору безразлична. Ему важна его логическая стройность, непротиворечивость, "грамотность" - в его понимании
, и т.п. Всякие рекурсии, вынос частых последовательностей операции в функции и т.п. - это минимизирует результирующий объем кода (в т.ч. и ASM) и делает его более "стройным и логичным" - с точки зрения человека. Плюс всякие форматирования, отступы, разделители и т.п. - тоже для "наглядности".Но, например, макроподстановки НЕ уменьшают размер ASM кода - они служат исключительно для упрощения записи на С. Вдобавок, рекомендуют писать "#define f do {....} while(0)" и т.п. - то есть, существует (наверное, ибо на С вообще не писал
) много "правил и традиций" как надо писать в каждом конкретном случае. Позвольте, но ведь макроподстановку я смогу сделать сам прямо в txt файле даже автозаменой в любом текстовом редакторе! И даже добавить после неё необходимую ";", если её там ещё нет - и таким образом избавиться от "do {....} while(0)". Точно таким же образом я могу заменить например "#БесконечныйЦикл" на for( ;; ) а не на while(1) и даже "для" и "пока" на for и while. Думаю, можно придумать ещё аналогичные моменты. Я даже самонадеянно полагаю, что смогу сгенерировать внутреннюю локальную переменную внутри функции, которой присваивать значение из ОЗУ для последующего многократного её использования - если это ещё не было сделано. То есть, я смогу написать такой "обработчик" txt файла кода на С, который будет делать по возможности что-то полезное, сам вставлять правильные макроподстановки, заменять возможно русскоязычные синонимы и даже оптимизировать код В качестве исходника будет браться код на С или на "С с русскими словами и зарезервированными конструкциями" - который будет возможно более удобочитаем и удобопонимаем разработчиком - а в качестве выходного результата - код на С "для компилятора".Уфф.... Понимаю, многабукаф
Это я ещё заставил себя остановить поток сознания Что скажете, господа? И по теме как таковой вообще, в её философском смысле, и по конкретному предложению? Или вы настолько знаете "повадки компилятора" и прочие стандарты, что вам абсолютно ясен и понятен любой код и вам не надо его никак видоизменять под вас?
Что автоматически сводит на нет одно из самых главных преимуществ языков высокого уровня (и С в частности) - понятность и ясность (не только для одного человека, а для всех!)