AM>> Кто-то отрицал применение ассемблера, при необходимости?
GS> Кстати, да ;) Hо за последнее время такие "экстремисты" потихоньку GS> перевелись...
Вот на этом и остановимся - никто не отрицает.
AM>> И какой модуль является "ехидным"?
GS> Который "плохо ложится" в концепции структурного программирования GS> и очень плохо реализуется "сишными" командами.
Может приведешь пример, из своей практики?
AM>> Чем нужно руководствоваться, чтобы определеить степень ехидности и AM>> хитрости модуля?
GS> Я не пытался формализовать этот критерий. Говорю просто о впечатлении GS> от алгоритма и кода.
Впечатление - вешь сугубо субъективная.
AM>> И что есть трюки (на асм)? Приведи пример.
GS> Классический ассемблерный трюк (которым я не пользуюсь, считая его GS> "плохим тоном") - самомодифицирующийся код.
Это метод вообще не имеет место быть на гарварде.
AM>>>> Задачи управления решаются конструкциями Си весьма эффективно. GS>>> Hе всегда. Попробуй написать на Си разбор АОH'овской посылки GS>>> ответа АТС, оцифрованную компаратором. В реальном времени, с GS>>> условием "кривости" реального "железа". AM>> Hу и, в чем проблема? В Си как-то прерывания по другому работают?
GS> Ты исходнички АОH'овские погляди, поймёшь, что прерывания здесь GS> не помогут.
Я еще раз говорю, мы не АОН обсуждаем, а общие подходы. АОН такой от бедности, потому что в совке просто не было ничего доступного кроме Z80 и РУ17 на тот момент. Вот и экономили байты, чтобы влезть. Сейчас этот же АОН на какой-нибудь AVR или PIC18 ляжет на Си и не подавится.
AM>> В крайнем случае, при необходимости процедура обработки прерывания AM>> пишется на асм, это где то отрицалось?
GS> Вся процедура обработки ответа пишется на асме. А она отнюдь не простая.
Да ради бога, пусть пишется.
AM>> Пользовательский интерфейс аона - на Си.
GS> Голосовые сообщения - это пользовательский интерфейс.
Это упакованные данные.
GS> Динамическая индикация и опрос клавиш - пользовательский интерфейс. GS> Работа со списками телефонов - тоже относится к пользовательскому GS> интерфейсу. Погляди, как это в АОH'ах реализуется и попробуй GS> сделать аналог на сях...
Было бы время еще туда смотреть
GS>>> А ты надеялся, что тебе сразу ответят на все вопросы, причём GS>>> дадут "единственно правильные" ответы? ;))) AM>> Hет, я надеялся, что свою точку зрения ты будешь подкреплять реальными AM>> аргументами.
GS> А я надеялся, что ты не будешь тупо игнорировать мои аргументы и GS> конкретные примеры...
Я не видел конкретных примеров кода, что может быть конкртенее их?
AM>> Я рассматриваю одного и того же программиста, который пишет одну и ту AM>> же задачу отдельно на Си и на Асм. Алгоритмы, применяемые им в обоих AM>> проектах совершенно одинаковы.
GS> Уже некорректный подход. Многие ассемблерные алгоритмы (всё тот-же пример GS> с самомодифицирующимся кодом) нельзя реализовать на Си. В этом примере GS> возникнет довольно сильный оверход.
И где они нужны вообще? А то, что флешак довольно трудно, а часто невозможно модифицировать, это ты надеюсь понимаешь?
AM>> Программист пользуется лишь инструментом (Си vs Asm) для реализации AM>> этих алгоритмов. При данных исходных условиях в подавляющем AM>> большинстве задач оверхед Си будет стоить 15-30% объема кода и AM>> производительности.
GS> Только в том случае, если программист не умеет эффективно пользоваться GS> ассемблером и не владеет "чисто ассемблерными" приёмами оптимизации.
Всем владеет одинаково. Сначала писал на асм несколько лет, потом перешел на Си, таких здесь много. Вот MP выбрал пример, специально такой, где можно выиграть поболее и даже в 2 раза не сократил. Мой пример, из реального моего проекта вообще ужимать не захотел, потому что практически нечего.
AM>> Это ты сводишь к частностям, каким то ехидным и хитрым функциям.
GS> Любая решаемая задача - частная. И для неё, при желании, почти всегда GS> можно придумать хитрый приём решения. Hо для этого нужно время и умение.
И что характерно, асм этого умения не добавляет, времени впрочем тоже.
AM>> Я как раз рассматриваю общий подход.
GS> А это не даст тебе возможность понять, откуда вдруг берётся такой выигрыш GS> на конкретных задачах ;)
Я вижу этот выигрыш. И вижу проигрыш. Я жертвую выигрышем, даваемым эффективностью асма, взамен получаю сокращение времени на разработку и простоту сопровождения. Плачу за это очень небольшим оверхедом, особенно для MB90. Кроме того, применяя ОС ухожу в еще больший отрыв от асм. Если бы у меня была задача для PIC12, я бы выбрал асм, скорее всего.
AM>> Пусть возникает, она также возникает и на Си.
GS> Hет. Hа си ты будешь решать задачу "сверху-вниз" и подобный алгоритм GS> не возникнет. А при решении задачи "снизу-вверх" использовать ассемблер GS> куда удобнее...
Си позволяет решать задачу хоть снизу-вверх, хоть сверху-вниз. Чаще я начинаю с написания HAL, потом двигаюсь вверх.
GS>>> Во сколько раз уменьшается часть проекта, если она исчезает? ;) AM>> У тебя по жизни на лице ухмылка, что ли?
GS> Как раз в соседних письмах тебе Максим Полянский нашёл время GS> продемонстрировать, как 4 сишных локальных переменных превратить в ноль GS> ассемблерных.
Там переменные упали в регистры, память не зарезервировалась, значит их нет. А если бы был процессор с аккумулятором и регистров бы у него не было, переменные на ассемблере очевидно запомнились бы в вакууме?
GS> И это на _примитивном_ примерчике, где мало что принципиально GS> поменять можно. В более сложных проектах, зачастую, половину кода можно GS> безболезненно выкинуть, а оставшийся существенно оптимизировать...
И через 3 года освободить еще 1 из 32К итак свободной памяти и приняться наконец за следующий проект.
AM>> В результате будут сравниваться алгоритмы, возможно разные,
GS> Условия задачи одинаковые. Какой ты конкретно алгоритм напишешь, это уже GS> твои трудности.
Это не мои трудности, а условия задачи. Алгоритмы, реализуемые на асм и Си должны быть одинаково оптимальными, или одинаково убогими. В этом смысл сравнения компилятора Си и асм. В противном случае это будет соревнование GS и AM в создании оптимальных алгоритмов.
GS> А подход "ты мне дай исходник на си, а я скомпилю" - явная GS> нелепость, компилятор я и без тебя запустить могу ;)
Вот и запусти.
AM>> Во-вторых, я не буду этим заниматься, потому что у меня нет времени AM>> на это.
GS> А у меня должно быть время, чтобы опровергать всякую фигню? GS> Интересная логика!
Нет и не надо. MP показал, что он не смог оптимизировать код даже в 2 раза. Можешь попробовать 2-ой пример, который он отказался оптимизировать.
GS> Чтобы решить поставленную задачу? Желательно. Хороший пример хорошо GS> формализованной задачи средней сложности. А если желание спорить пропало, GS> как только дошли до реальной задачи - просто сознайся, что спорил GS> из вредности, а доказать свои высказывания не в состоянии.
Я бы хотел посмотреть форт, но не могу из-за недостатка времени. Я тебе могу встречное предложение сделать. Давай напишем стек SLIP/IP/TCP. Но ты ведь точно также скажешь, что у тебя не времени изучать стек протоколов.
AM>> Да, я хотел бы, но не знаю, но и не должен.
GS> "Взялся за гуж..." ;)
GS> Кстати, с Фортом советую познакомиться поближе. Ты его можешь потом никогда GS> в жизни не применять, но увидишь целый набор очень интересных приёмов, GS> о которых знает далеко не каждый программист...
Это входит в мои планы, по мере появления времени. Какую литературу можешь посоветовать? Может в i-nete есть что-то отсканированное?