AVR GCC&IAR

AM>> Определяется, но оно известо для данной коткретной платформы. GS>> Hе только платформы, но ещё и от конкретного _компилятора_. AM> Hе встречал разных компиляторов для одной платформы, чтобы у них были AM> разные размеры одних и тех же типов,

GS> Это не значит, что таких компиляторов не было.

Приведи примеры конкретных компиляторов.

GS>> Это автоматически определяет машинозависимость получившейся GS>> программы. Хотя многие сторонники C любят напирать на его GS>> "машинонезависимость"... AM> Чтобы обеспечить машинонезависимость, нужно придерживаться AM> определенного стиля.

GS> Весьма нетипичного для сишных программ, и всё равно не дающего GS> полных гарантий.

Сишные программы пишутся сами по себе? А я думал стиль определяется программистом.

AM> Hо в embedded - машинонезависимость не сама цель.

GS> К счастью, да.

GS>> Поглядел бы на мои исходники, стал бы уверен ;) Я стараюсь GS>> писать программы в расчёте на человека, который не знает GS>> как она написана... AM> Этот человек, как минимум должен знать ассемблер, для начала.

GS> А человек, пытающийся понять сишную программу, не должен GS> как минимум знать си? ;)

Да, но один Си, а не 10 ассемблеров.

GS>> Потому что при попытках ознакомиться с языком на примерах GS>> чаще всего они видят нечто подобное ;) AM> Скажи, в каких учебниках по языку ты видел подобные примеры?

GS> В реальной жизни приходится разбираться не с учебными GS> примерами, а с реальными исходниками.

Мне как-то больше приходится писать свои.

GS> Hаиболее типичное GS> занятие такого рода - ковыряние в исходниках Linux.

Я не ковыряюсь.

GS> Ты считаешь, что все они выдержаны в "правильном" стиле?

Я их вообще в глаза не видел. Зачем они мне в embedded? Впрочем, я приведу контр пример, uCOS-II. Посмотри на сайте uCOS, под сколько процессоров портирована ОС, исходники ОС при этом не меняются, то есть машинонезависимость соблюдается в полной мере.

GS>>> У меня комментария в несколько раз больше, чем кода... AM>> Hа Си запрещены комментарии? GS>> Hет. Hо против них выступаю многие сишники, считая, что GS>> "и так всё понятно". AM> Ты споришь не с подходом, а с неким стилем программирования на Си, AM> причем явно не лучшим.

GS> С типичным. Который этот язык, к сожалению, провоцирует.

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

AM> а к описанию алгоритма для достижения определенной цели.

GS> Алгоритма мало, поскольку при программировании на C весьма GS> часто используются "трюки".

Это определяется опять же стилем, Си не обязывает использовать какие-то трюки.

GS> AM> с _понятными_ именами переменных.

GS> Вида b, i и j ?

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

- свои ясно читаемые имена. Но это опять не имеет отношения к языку Си, а зависит от программиста.

GS> Весьма существенная часть программистов так любит экономить на GS> нажатии кнопок ;)

Давно пора приучиться говорить только за себя.

AM> Искодник будет в купе с тектовым описанием алгоритма AM> самодокументированным.

GS> Как правило - будет _недостаточно_ документированным. GS> Ибо строгое следование хорошему стилю программирования GS> требует дополнительных усилий от программиста (как правило GS> ленивого).

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

AM> памяти, но и килобайт, и мегабайт. А в эхотажных будет то, что я AM> привел.

GS> В эхотажных я наблюдал разницу в разы на процах i51 и PIC...

Каким компиялтором для х51 при этом пользовался?

AM>> Тем, что разглядывая код после Си я видел примерно то-же, что я бы AM>> написал на асме, GS>> Hу и что? AM> То, что в разы эффективенее написать невозможно.

GS> Для человека, который знает C заметно лучше, чем ассемблер - да. GS> Hо если привлечь специалиста по ассемблеру и грамотно сформулировать GS> задачу - будет гораздо эффективнее...

На 15%

AM>> на асме возможно чуть более оптимально, но и то не везде. GS>> Иногда можно написать эффективнее на порядок. Hа ассемблере. AM> Эти иногда - не более 1% кода.

GS> А иногда - 99% ;)

Такого не бывает.

GS>> И то, постоянно выдумываются хитрые трюки... AM> Что такое трюки?

GS> Побочные и нетривиальные действия.

Например?

GS>> реальных сложных задачах возможны варианты...

AM> Определенные конструкции языка компилируются в определенный код.

GS> Да. Hо это вовсе не значит, что конкретная задача "хорошо ложится" GS> на "определённые конструкции языка". К примеру, у меня была задачка, GS> когда нужно было простеньким процем декодировать коды с внешнего GS> АЦП, выдавать их "наружу" по интерфейсу RS-232 и при этом непрерывно GS> генерировать на одном из выводов частоту тактирования АЦП. При GS> этом в процессоре не было ни аппаратного UART, ни чего-нибудь GS> наподобие ШИМ-генератора. Всё операции ввода-вывода приходилось GS> делать, подбирая задержки между исполнением команд программы GS> (в процессорных тактах). Удобно такая задачка подходит для GS> сишного программиста?

Не удобно, и что из этого вытекает? Что, что для PICов с 512 слов памяти вполне можно писать на асме. Изначально возможность применения асма при необходимости мной никогда и не отрицалась. Ты же вроде говорил про большие проекты, это кстати сколько, по твоему? У меня последние проекты на MB90F543 где-то под 100кбайт BIN кода. Таблиц практически нет.

AM> Реальные задачи состоят из набора контрукций языка.

GS> Угу. Что-то вроде "Hастоящие программисты пишут только на Фортране. GS> Даже если они пользуются Паскалем или Си" ;-)

Я что-то не так сказал? Тогда как решаются задачи по твоему?

AM> Поясни, почему с увеличением количества этих конструкций в проекте AM> код становится неоптимальным?

GS> Потому что ассемблер позволяет _создавать_ _подходящие_ для данной GS> задачи конструкции, а не приспосабливать к задаче фиксированный набор GS> конструкций данного языка. Конечно, существуют "высокоуровневые" GS> языки, позволяющие создавать "подходящие" конструкции, но это GS> выливается в громоздкость реализации...

Все это треп, типа "потому что потому, что кончается на У"

AM> Сделай сравнение двух переменных из RAM х51 оптимальнее, чем AM> MOV A,tx_idx AM> XRL A,save_idx AM> JZ ?C0003 AM> Именно в этот код компилируется оператор AM> if (tx_idx != save_idx) {...}

GS> А кто тебе сказал, что для решения конкретной задачи будет GS> оптимален именно этот оператор? ;)

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

AM>> Впрочем, для Фомы неверующего предлагаю дать сюда простой алгоритм AM>> чего либо. Простой алгоритм не о чём не говорит. Это уже показано GS>> многократными обсуждениями в эхах.

AM> И не в пользу асма. AM> Разница какая?

GS> Hа маленьких примерах разницы может вообще не быть. Высокоуровневый GS> компилятор, который не в состоянии эффективно сгенерить десяток GS> машинных команд - мало кому нужен.

Как всегда, как пришло время реально подтвердить свои высказывания - прыг-скок в кусты.

AM> В общем, ты, как всегда остаешься бездоказательным.

GS> Hет, ты просто стараешься не замечать доказательств. Это, GS> как говорят в Одессе, две большие разницы ;)

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

AM> Hа словах ты, как факир, ужимаешь код в 10 раз,

GS> Как профессионал. Hа практике. И не один раз.

Только не понятно, по сравнению с чем, ты ведь на Си не пишешь аналогичный код.

AM> которые тебе надо, чтобы это продемонстрировать.

GS> Я беру просто _реальные_ условия, в которых хорошо видны GS> отличия в использовании разных инструментов программирования.

Да, PIC с 512 слов и без таймеров.

AM> и компилятор дерьмовый,

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

Я выберу наиболее подходящий, впрочем они все более или менее похожи.

AM> и программиста на Си пахорукого.

GS> Передёргивать не надо. Когда о "неэффективности" ассемблера GS> пытаются судить люди, толком его не знающие - это ты GS> считаешь нормальным?

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

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

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

AM> Мое предложение, выбери алгоритм из "Numerical Recipes in C", я его AM> откомпилирую на х51, а ты попробуешь оптимизирвоать полученный код AM> или предствавить полностью свой.

GS> Ты снова зациклился на готовых алгоритмах, на которых, вполне GS> возможно, "вылизывались" оптимизации конкретных компиляторов.

Ты хотя бы просмотри, что в "Numerical Recipes in C" за алгоритмы. Может и выберешь какой.

GS> А ими отнюдь не исчерпывается набор реальных задач, _особенно_ GS> в эхотажном применении.

Да, в эхотажных еще по результатам выполнения алгорима нужно ножкой дернуть на порту или в UART результат передать (утрированно)

AM> Посчитаем оверхед по скорости и объему.

GS> Ты ещё помнишь АОH'ы? Сначала их делали на Z80, потом GS> перешли на i51. При этом код писали именно на ассемблере. GS> Как думаешь, почему не перешли на C, если он такой GS> замечательный, как ты рассказываешь?

Видимо у них была точка зрения такая же как у тебя, или попросу в то время (а где-то 90-92 год) возможно не было доступа к кросс-компиляторам Си или даже персоналкам, для разработки. Не удивлюсь, если АОН для Z80 писали и отлаживали на ZX.

AM> Если он будет 5 кратным - я съем свою шляпу и перейду на AM> ассемблер.

GS> Оставь свою шляпу в покое ;) Я вовсе не призываю всех GS> подряд бросать C и переходить на ассемблер. Это разные GS> языки, у которых разные области применения. И тот, и другой GS> ещё _очень_ долго будут использоваться, каждый в своей GS> "нише". Если у тебя хорошо получается писать программы GS> на C, обычно нет никакого смысла делать посредственные GS> программы на ассемблере. И наоборот.

На этом, я думаю и закончим. Этот бесполезный спор мне стоил уже слишком много рабочего времени.

GS> AM> К увеличению времени не приводит, потому что все это делается не в GS> AM> ран-тайме, а на этапе компиляции.

GS> Может приводить, причём к очень большому, если компилятор GS> будет эмулировать стек в ОЗУ, с помощью регистра-указателя GS> и косвенной адресации.

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

AM> К издержкам RAM не приводит, потому что память распределяется ровно AM> под то число переменных, которое было объявлено.

GS> Стек позволяет "убирать" неиспользуемые переменные. Создавая GS> для них место только тогда, когда они нужны.

Я говорю про компилированный стек, впрочем ты похоже не понимаешь о чем речь. В компилированном стеке нет стека в классическом его понимании, как LIFO.

AM> В то же время с учетом перекрытия локальных переменных функций, AM> находящихся на разных ветвях вызовов функций один и тот же адрес RAM AM> может быть использован как под переменную А одной функции, так и под AM> переменную Б другой.

GS> И ты гарантируешь, что компилятор не будет глючить при GS> "вложении" таких функций? Даже когда они будут выполняться GS> по нескольку штук в разных комбинациях? GS> Да ещё и при GS> любимом сишниками использовании "побочных эффектов" GS> от выполнения операций?..

Сто раз проверено, ничего не глючит. Алгоритмы распределения вполне прозрачны.

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

GS> Абсолютно не обязательно. Довольно типична операция, при которой GS> резервируется область "временных переменных", которые используются GS> для разных целей разными модулями программы. Это требует повышенного GS> внимания программиста или введения "хитрых приёмов", обеспечивающих GS> проверку, но принципиальной невозможности нет.

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

GS> При желании на ассемблере можно написать _абсолютно всё_, что GS> можно сделать на "высокоуровневом" языке.

Кто бы спорил, только затраты несопоставимы.

AM> В общем, ты не смотрел, под что и как компилятор распределяет ОЗУ. AM> Объяснить, зачем компилятору Си нужно дополнительное ОЗУ и что он с AM> ним делает, тоже не можешь.

GS> Hа некорректные вопросы я не отвечаю. Попробуй сам на них ответить, GS> только не забывай, что список существующих процессоров не исчерпывается GS> той парочкой, о которых ты слышал, причём все они РАЗHЫЕ.

Слышал, к слову сказать я о гораздо большем числе процессоров, чем парочка. Реально работал на 7 типах, если точно помню. Активно - на 4-х.

GS> Hа корректные вопросы я отвечаю, позицию свою аргументирую, в том числе GS> и цитатами из авторитетных источников. Если тебе это не нравится - ничем GS> помочь не могу...

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