AVR GCC&IAR

MP> MP>> Я об этом знаю хотя-бы потому, что в HC11 (ежли не считать SP/PC) MP> MP>> всего 4 регистра, 2 аккумулятора A и B и 2 индексных X и Y. MP> AM> Hет, ну ты за логикой то следи. "Я знаю, что в проекте на х51 регистры MP> AM> R6 и R7 ........ , потому что в HC11 всего 4 регистра."

MP> [цитата] MP> DO> Оно и заметно. А у меня - есть. Пришлось переписывать чужую MP> DO> программу с ассемблера HC11 на С, из-за того, что сопровождать ее MP> DO> на асме не было уже никакой возможности. MP> [кончилась]

MP> Все нормально с логикой у меня!

Значит с времением реакции. Я привел пример по регисрам R6, R7 для х51

MP> Ты просто путаешь ветки флейма, краткая история MP> - в этой ты решил усомнится в сопровождении проги на HC11-ASM ;)

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

MP>> В реальности использоание индексных регистров для привязки к MP>> какой-либо точке озу видел только в Z80, и производном дибильных MP>> си-компиллеров на pc. AM> Очень даже не плохо эти индексные регистры используются для адресации AM> параметров и локальных переменных функции в стеке. Hапример IAR C Z80 AM> так может делать, как впрочем может делать и компилированный стек AM> (задается опцией) И чем это так плохо, по твоему?

MP> Hапример это усложняет мне жизнь.

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

AM> И какие процессоры с индексными регистрами ты еще знаешь?

MP> Лучше наверно сказать какие я знаю без них. Hапример пики - очень добрая MP> архитектура. Как не напиши - все понятно. Hикаких хитростей не придумаешь. ;)

Это все? То есть разработчики большинства uC дураки, намеренно ввели усложнение в архитектуру в виде индексных регистров, чтобы побольше денег содрать с потребителей?

AM> Я и говорю - практически нет. AM> Редко проект занимает ОЗУ под завязку, кроме того часто Си позволяет AM> экономить ОЗУ, создавая компилированный стек для размещения локальных AM> переменных функций,

MP> Тебе не приходила в голову идея, что локальные переменные зачастую не нужны?

Да, а запопинание значений в промежуточных точках будет делать А.С.Пусшин

MP> А эфект этого распределения сомнителен.

Он, эффект, налицо.

MP> А так-же что большинство яву алгоритмов имеют избыточные переменные

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

MP> (например счетчик while и

Что, счетчик while? На асм не надо такого же счетчика?

MP> индекс массива явно заданный как переменная, MP> считающие вперед и различающиеся на еденичку а то и вообще одинаковые).

И что? Причем тут Си? Ассемблер то эти счетчики в воздухе хранит, что ли?

MP> Кроме того не существует методики грамотного расходования MP> озу применительно к тем-же pic.

Объясни, зачем компилятору Си нужно больше ОЗУ, чем асм-у? Он его, что, солит?

AM> что очень сложно сделать руками на асме и приходится под каждую AM> локальную переменную выделять собственный адрес в ОЗУ.

MP> И не говори. Как люди писали на 11-м проце с 4-мя регистрами, тут я гляжу MP> некоторым и 32-х не хватает ;)

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

AM> ПЗУ - примерно тоже, даже с учетом оверхеда Си 15-30% MP> "Шо.. oпять?" (c) мф. "жил был пес".

Я предложил Шепелеву выбрать алгоритм из Numerical Recipes in C. Предлагаю и тебе. Выбери алгоритм, я его откомпилирую под х51. Докажи на деле, что на асм можно сделать хотябы на пол-порядка эффективнее.

AM> верхний объем памяти кристалла в большинстве случаев не достигается, AM> особенно с последней тенденцией удешевления flash и увеличения AM> накристальной памяти в современных uC. Скорость - если успевает, но AM> по барабану, если не успевает, критические куски переписываются AM> вставками на асм.

MP> Hе забудь еще про потребление. Есть устройства с питанием от батарей. От MP> телефонной линии. И скорость в них желательно предельно снизить.

Желательно - это не термин ТЗ. Если в ТЗ забиты требования по энергопотреблению, то они должны быть выдержаны. Способы могут быть разные.

MP> Поэтому все теории только для розетки годятся.

Начинаешь юлить. Спроси у Alex Golov или поищи в архивах конференции. Он приводил в свое время для Pic энергозатраты на вычисления с плавающей точкой.

AM> Остается твой единственный аргумент - внутреннее удовлетворение от AM> бОльшей эффективности программы на асм. Только эта эффективность AM> мифическая, не влияющая на показатели конечного устройства.

MP> Влияет и сильно. Я банально возьму контроллер который медленнее с меньшим MP> обемом памяти и дешевле.

Объем памяти, он обычно кратен. Конечно, если на асм можно ужать программу в 2047 байт по объеме ПЗУ 2К, то на Си вряд-ли получится и придется взять следующий кристалл. Но во-первых, это бывает далеко не всегда, Во-вторых, выигрыш заметен только при очень больших тиражах и очень дешевых устройств.

OR>> А этот очень неплох и вpоде бы на месте не стоит. OR>> Hо его макpовозможности как минимум не меньше aspic.

DT> И посимвольный pазбоp аpгументов есть? Знаешь, не помню -- всякие STRCMP,STRCAT,GETSTRCHAR,SUBSTR уже в нём были или после того, как Клочко потоптался... Поищи его, за лет 5-6 многое могло поменяться.

wbr,