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> помочь не могу...
Брукс, кстати, готовя переиздание книги добавил главу, в которой признал некоторые из своих ранних утверждений ошибочными.