|
|
Замечания на статью:
http://mcuselect.narod.ru/docs/CwoC2.htm
Вот что накидалось после первого "прогона". Может я где-то и не
прав.
1)
Вялое введение. Непонятно какая мысль ключевая после описания
всех “за” и ”против” относительно ассемблера и С, т.е. зачем это все
вообще перечислялось? Предпочтительность ассемблера недостаточно
обоснована. Напрасно. Мягкотелые: “несколько большие размеры”
и “скорость … бывает несколько меньше” совершенно не убеждают,
наоборот, возникает желание смириться и принять ‘С’ как должное на
все случаи жизни, что ошибочно. У ‘С’ есть своей “огород” и довольно
четко очерченный. Может так задумано? Странно.
Одним словом, если статья предназначена для широкого круга, не
мешало бы привести более веские аргументы, когда применение
ассемблера не имеет конкуренции. Ну, хотя бы:
-жесткое требование максимально эффективного использования
аппаратных ресурсов, независимо от их количества (никаких излишеств
на “удобства”);
-использование компилятора С запрещено руководством по политическим
(идеологическим, маркетинговым) соображениям (редкий случай);
-для данной аппаратной платформы на данный момент не существует
компиляторов С или они не отвечают предъявляемым требованиям (глючные
весьма, например);
-требование заказчика;
-скудность аппаратных ресурсов;
- …
и т.д. Ведь это - ключевой момент, на этой базе Вы в дальнейшем
преподносите Ваш “третий путь”, а в чем его принципиальные
преимущества над классическим С? Остается завуалированным. А зря! По-
моему, широкому кругу нужно убедительное обоснование и
непредвзятость. Ну, а если пишете для узкого круга, то зачем тогда
кашу по тарелке развозить? Лучше сразу приступать к изложению сути
по трансляции и всякие введения отбросить.
Но хотелось бы все-таки видеть, в какую “нишу” позиционируется
предложенное.
Второй абзац сверху:
>Однако компиляторы с языка Си часто менее доступны по сравнению с
ассемблером.
Мягкий намек, что дальше будет разговор в пользу бедных и это почему-
то настораживает.
Второй абзац сверху:
>“..при программировании на ассемблере программист полностью
контролирует весь код, >вплоть до самой последней команды, поскольку
в этом случае между ним и >контроллером отсутствует посредник в виде
компилятора”
Непонятно. Как “отсутствует посредник”!? Компилятор ассемблера
является таким же «посредником», как компилятор С.
И это очень шаткое - «полностью контролирует весь код». Если
подразумевается контроль на уровне мнемонических команд, то это
верно, но лишь отчасти. К примеру, (MPASM, PIC):
pagesel fun
call fun
В машинном коде директива pagesel будет раскинута на пару команд, и
проконтролировать «телодвижения» директивы pagesel в символьной
отладке можно лишь косвенно. И еще непонятно до какой
такой “последней команды”. Даже, если подразумевается голая
мнемоника, надо быть полностью уверенным, что она будет один в один
оттранслирована ассемблером в машинный код. А Вы уверены? Если
компилятор писали не Вы, то он для Вас всегда черный ящик и, как
всякий продукт рук человеческих, ассемблер, в процессе трансляции,
может и глюкнуть, и ошибиться. Скажем так, ассемблер, в отличие от
компиляторов высокого уровня, позволяет более полно контролировать и
использовать аппаратные ресурсы, поскольку он “ближе к телу”
исторически, по природе своей. А “полностью” – это слишком
категорично, да и не верно. Строго говоря, действительно полностью
контролирует код только программист, пишущий непосредственно в
машинных кодах. Да, Вам ли не знать.
2)
Ну, предположим, Вы убедили меня, как читателя в полной и
окончательной неотвратимости применения ассемблера в чистом виде без
примесей и указали нишу такой применимости (а она есть!). Итак, с его
помощью мы хотим опираться на такой способ (метод, стиль)
программирования,
>..который позволил бы сочетать достоинства программирования, как на
ЯВУ, так и на >языке ассемблера и одновременно сглаживал присущие
им недостатки.
Но, похоже, взялись за вековую мечту человечества – универсальный
инструмент для всех и для каждого. Вот тут вряд ли получится. По моим
прикидкам, жизнь дает другой расклад: для каждой ситуации – свой
инструмент. Я как-то услышал, как отличить хорошего мастера-плотника
от плохого. Хороший владеет множеством инструментов и не делает все
подряд одним “топором” … Это так, лирика. Но мы решили, что нам
выбирать не приходится, и потому идем дальше.
>..для этого нужно самому стать компилятором
От так от. Ну, все равно доярке бригадир скажет: “Хочешь корову
подоить? Изучи сначала основы генетики”. Интересно, как воспримет? А
доярки в массе своей?
И далее:
>..при кодировании программ нужно просто придерживаться стандартов
(соглашений, >правил, шаблонов) аналогичных тем, которые используются
в компиляторах.
Так-то оно так, но вот прочтет неискушенный человек, и встанет у него
затаенный, но вполне резонный вопрос: “А не проще ли использовать
компилятор С, да и пусть он все это реализует “за кадром” и
соблюдает эти “стандарты”, а я мол о задаче буду думать”? Но тут же
он вспомнит о навязанной ему “бедности”, что от ассемблера ему не
уйти, и у него опустится все, что только может опуститься у мужика.
Суровая проза жизни. Правда, когда узнает, что придется
изучать “основы генетики”, чтобы “выдаивать” из ассемблера то, что
компилятор С делает “легким движением руки”, то глубоко задумается, а
не проще ли, если не своровать, то снять последние штаны и все-таки
купить компилятор С?… Почти как у Куприна в «Белом пуделе»: ”Рубль
дать жалко, а пять копеек – стыдно. Вот и гонят со двора”. Тоже очень
интересно, чем закончится.
>Вы тоже можете принять для себя соответствующие правила.
Толстый намек такой. Одним словом, а не списать ли нам стиль у С
(“ремонт – это вам не шахматы, тут думать надо”) подсмотрев код,
сгенерированный С компилятором. Ну все равно, что наблюдаем в
замочную скважину за “половыми актами” С компилятора и опосля
творческой переработки повторяем тоже самое используя ассемблер.
Признаюсь, в условиях информационного голода баловался
подобным “вуайеризмом”. А чтобы легче было, формализуем
эти “телодвижения”, да еще свое кровное, в боях добытое, привнесем.
Чем не С? Ну пусть псевдоСи. Только вот беда, двоечники долго не
живут, и думать все равно придется и, конечно, привносить уже свои
правила. Вот тут и начинается самое интересное.
Еще один момент. Высота “полета” у разных компиляторов (компиляторов
ЯВУ, используя вашу терминологию) разная. У С одна, а у С++, сами
понимаете, другая. Есть еще Pascal, ADA и горные козлы…. Ну, так на
какую гору потом полезем? И где границы применимости такого подхода?
3)
>Любой программист, со временем, так или иначе, вырабатывает свой
>стиль, свои >правила, свои приемы программирования
>Я думаю, что это время можно значительно сократить, если делать это >более >осмысленно, более целенаправленно.
Ну, понятно. Постепенно склоняюсь к тому, что Ваша статья все-таки
для узкого круга. Возможно, пока для узкого. Проблема в следующем.
Чтобы сформировалась потребность в использовании подобными
инструментами, как в Вашей статье, надо пройти весь путь.
Представьте, человек только осваивает это дело. У него, как говорят
философы, понятийный аппарат даже еще не сформировался. А тут еще Вы
со своим “осмысленно и целенаправленно”. На каком этапе он вообще
сможет просто осмыслить саму концепцию как таковую, не говоря даже о
сознательном применении? В лучшем случае, он просто будет тупо
следовать Вашим шаблонам по проложенной колее, даже не проникаясь
самой сутью. Не буду далеко ходить – посмотрите, что делается с
C++.. Реально ее [идеологию] эффективно смогут применить те, кто в
своем программном мировоззрении уже сам подошел к этому порогу, или
перешел его. Именно тогда это можно сделать осмысленно и
целенаправленно. Наверное, в этом и парадокс. Нельзя одним скачком
стать Эйнштейном, используя чужой опыт, нужно накопить свой, который
надо кишками прочувствовать. И еще. Одного опыта мало. Стиль
программирования начинается со стиля мышления и второе первым не
перебить, можно разве что наложить отпечаток. Ведь недаром говорят,
что если человек учился программировать на Бэйсике, то, как
программист, он уже испорчен навсегда. Резкое заявление, но дыма без
огня не бывает. Человек должен сначала научиться стоять, а потом –
ходить. В этом секрет всех истинных Школ (научных, программных,
музыкальных и т.д.) Сначала научить правильно “думать”, сформировать
понятийный аппарат, потом набрать опыт и постепенно - закладывать
стиль. И еще говорят, что проще научить заново, чем переучивать.
Да. Опечатка в 7-м абзаце сверху: наверное, надо «реализация этих
стандартов»
4)
>Несколько замечаний относительно команд условного перехода. Можно
сделать их >менее зависимыми от используемого процессора, если
реализовать их в виде >макроопределений, используя средства
макропроцессора, имеющегося в ассемблере.
Не совсем понятно. Ассемблер по определению машинно-зависимый язык и
при переходе на принципиально другой (не родственный) процессор, а
следовательно на др. ассемблер, их все равно придется переписывать
полностью, т.к. изменения могут коснуться всего, включая
макропроцессор. По сути, программист, «пересаживаясь» вынужден будет
переписывать свои инструменты практически с нуля, иначе он потеряет
этот «стиль» и запутается в своих же ногах. А может, я не понял здесь
чего-то…
5)
Есть во всем этом большая положительная сторона. Глядишь, рано или
поздно придет мысль просто ввести новый язык, на базе уже
отработанных концепций, и создать под него компилятор. Возможно, это
будет новая веха, а возможно все это сгниет на винте, поскольку этот
путь уже был пройден создателями ‘С’ и много прочего народу полегло
на нем..
А вообще похвально, конечно. Я сравнил с кое-какими своими
подобными изысканиями. Завсегда приятно осознавать, что не заблудился.
Кто-то сказал, что “одни и те же мысли витают в воздухе”. Хотя Ваша
статья мне напомнила ситуацию в “Полете над гнездом кукушки”. Когда
Макмерфи поспорил с психами на 20$, что поднимет в душевой мраморную
тумбу. Пыжился, пыжился и отдал таки 20$. Они стоят и смеются. А он
им:
-Что смеетесь? Что? Я ХОТЯ БЫ ПОПЫТАЛСЯ!
E-mail: 
info@telesys.ru
