Если стоит задача переносимости, то - да. В противном случае - не обязательно.


Опять же, зависит от поставленой задачи. "Толстые" задачи на "толстых" чипах удобнее решать таким образом. Но 128-ю Мегу применять там, где и Тиня управится, это как бы из пушки да по воробьям. А тут уж и ужиматься приходится. Инструментов для создания программы фактически всего-то два - ассемблер да Си. Ассемблер позволяет дать максимально эффективный код, но со значительной затратой времени. Си, при соответствующем подходе, может дать код не намного избыточнее, но создание программы идет значительно быстрее, поэтому является вполне разумным компромиссом и для мелких чипов. Вот тут, как раз, и нужны наработанные приемы получения компактного кода, пускай даже в ущерб переносимости.

"Кого ЭТО волнует?"©

Противоречие у Вас получается ;>
C одной стороны Вы говорите о Tiny с 1-2-4Kb памяти, с другой говорите о затратах времени при написании программы на ассемблере. 2Kb на C заполнить - дурное дело не хитрое - полчаса и вся память занята - это не просто сокращенные трудозатраты, это можно сказать их вообще нет. Но и функциональность такой программы в тиньке также получится "никакой".

Хотите функциональности - будьте добры потрудитесь - либо то 8k-16k на C выдавить, либо, что сравнимо по трудозатратам - 1-2k ассемблере. При этом на ассемблере вы получите оптимальный вариант кода естессно непереносимый на другие платформы. На C поизвращавшись тоже втиснете нечто сравнимое по функциональности но не в 2k, а скажем в 4k, при этом получить мало того, что непереносимый код, так еще и неоптимальный. Не проще уже тогда сделать переносимый и поставить более толстый чип?

Так что или asm в руки и программим тиньки, или C - но тогда уж начинаем с M16.

IMHO, ложное впечатление.

Не так давно рисовал программу для одного измерительного прибора. Изначально предполагалось выполнить на Меге8 как минимум, хоть алгоритм не очень сложный, но громозкой таблица получалась. Проанализировав таблицу, увидел, что зависимость достаточно близка к корню 4-й степени. После извлечения корня зависимость получилась значительно линейнее, поэтому таблица, учитывая, что для вычисления промежуточных результатов была применена кусочно-линейная аппроксимация, оказалась совсем маленькой. Вычисления все целочисленные. Только там, где необходимо было, использовались long. Поэтому сама математика много места не заняла. В результате все уместилось на Тини26 и даже чуть-чуть места осталось.

Просмотр ассемблерного листинга показал, что компилятор достаточно грамотно распорядился программной памятью и врядли чисто ассемблерный код оказался бы намного компактнее. Естественно, оптимизация по размеру была выбрана максимальной. Правда пришлось попробовать разные варианты сишного кода, и далеко не всегда более компактный сишный давал более компактный ассемблерный. Но в результате получилось все значительно быстрее и удобнее, чем если бы это всё выполнялось на ассемблере. Поэтому и для "тонких" чипов Си вполне идет.

PS: Да, кстати, забить 2 килобайта на Си всякой хренью за полчаса действительно - дурное дело нехитрое. Вот разумно распорядиться - заметно дольше получается. Но все же - получается. А относительно ассемблера, я отнюдь не являюсь ассемблерофобом. Напротив, знать его и уметь на нем код писать считаю необходимым.

Видимо самый быстрый вариант на С будет таким:

компилируется в:

итого 7 команд/тактов

Это не впечатление, это просто мое мнение...
Когда ПП <=4k - инструмент для реализации чего-то серьезного может быть только асм.

Я не спорю, что некоторые простые задачи - мигалки гирлянд, управление шаговиками, динамическими индикатороми, lcd и т.п. - можно и нужно решать на Tiny + C. Сам грешен ;>
Но как только появляется серьезная задача, например "что-то" over IP, программная реализация encoder'a/decoder'a FSK и т.п. - то в тиньку только на асм'е можно такое втиснуть.

недавно засовывал в 48-ю мегу именно кодер/декодер FSK с автоматическим включением передачи. Писалось на C. Заняло меньше 1 К кода вместе с таблицей DDS, которая ещё и для разных сдвигов фаз при работе без разрыва фазы прописана была. Э-эх так и не понадобилось лазать по асму и поднимать тактовую Но приходилось иногда думать как на асме - какую переменную компилер будет перегружать, а давай ему, чтоб не перегружал, локальную переменную подсунем или порядок строк да поменяем)) Скажу, что думали опуститься до использования хитрых иаровских модификаторов для неперегрузки z-регистров и т.п., но как-то не дошло. Думаю, что примеры, где же асм нужен априори, приведены неправильные, зависимость выбора инструмента от размера памяти программ необоснованна, хотя полностью согласен, что где надо юзать асм, там нефиг микроскопом гвозди забивать

Ничего странного, если использовать в IAR битовые поля:


дает такой результат при среднем уровне оптимизации:


Правда, IAR странно читает 7-й бит в флаг Т - через флаг С перемещает его в 0-й бит регистра(при этом обнуляя сам регистр) и уже потом делает bst Rxx,0. Если в вышеприведенном примере менять местами не 3 и 4-й биты, а 6 с 7-м, то результат получается следующий:

Все правильно, в варианте с битом 7, компилятор поступает правильно,
тк значение tt.Bit7 есть не что иное как unsigned char (0 или 1, то есть полный байт),
и если далее в коде будет работа с этим битом через обращение tt.Bit7, то он
будет пользоваться значением временной регистровой переменной в которой хранится 0 или 1.
А в варианте с битами 3 и 4 оптимизатор понял что дальше обращения к этим битам не будет
и смог соптимизировать это на конструкцию bst/bld

Вы спросите почему он не проделал тоже самое с битами 6 и 7 ?
Так собственно по тому, что (8бит) это не только unsigned char(byte) но еще и просто
char, для которого правила арифметики чуть-чуть отличаются...(старший бит может быть знаком)

Да, и еще, в Вашем варианте для перестановки битов получилось использование
двух временных регистров, что не есть гуд...
то есть в тестовом варианте это конечно выглядит неплохо, но в реальной задачке,
когда другие регистры тоже чем то заняты, это будет приводить к
дополнительным(нежелательным) операциям сохранения регистров или в младших
регистрах или в памяти/стеке.

Ну и в конечном итоге, нужно понимать/помнить что все эти варианты
оптимизации(и мои в том числе) в достаточной степени компиляторозависимы,
то есть пишем код на С, компилим, если непонравилось, начинаем сначала,
и так неколько итераций...

Проблема применения асма/Си сама по себе надуманая. Применяется то и там, где дает оптимальный результат. Точка. Все остальное - от лукавого. Если для прибора на Тини26 прекрасно подошел Си, то перед этим нужно было реализовать устройство с 4 взаимонезависимыми каналами, генерирующее выходные импульсы, длительность и скважность которых зависела по определенному табличному закону от длительности и скважности входных, выходные асинхронны по отношению ко входным. Тут, как раз, никакой Си не помог бы, даже с ассемблером пришлось поизголяться, чтобы получить необходимые реалтаймовые параметры.

Все равно не могу понять поведения компилятора. Почему обработка битового поля внутри байта должна отличается аналогичного поля на границе байта? И почему компилятор должен воспринимать переменную как char, если для нее явно указан модификатор unsigned?
А временным регистром можно было бы обойтись и одним. Второй использовал только для того, чтобы листинг не был перегружен обращением к volatile-переменной. Хотя уже сейчас понял, что нагляднее было бы впихнуть все это в какую-нибудь процедуру, отличную от main.
К тому же я не стемился минимизовать размер кода/время выполнения, а просто хотел показать, как "заставить" IAR обратиться к флагу Т стандартными средствами С, а не выражениеми типа SREG.T = (s&0x01)!=0;