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

Да, пятью указателями там явно не обойтись

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



Не проверял, но сомневаюсь, что в МК засунут инструкцию, выполняющуюся сотни тактов.
Для справки: у интеловской x86 инструкции enter есть параметр level, который может изменяться от 0 до 31. Именно об этой вложенности я и говорю. А Вы, вероятно, только про случай level=0. Если ошибаюсь - поправьте.



Почему сразу стек ? Удобнее каждому экземпляру давать структуру, в которой будут все локальности (а также входные параметры), а функциям передавать единственный параметр - адрес этой структуры. Располагая эти структуры в глобальной памяти, можно ограничивать одновременную количество экземпляров, которые сможет обработать МК. (Экземпляр - это ветвь и т.п.). А стек оставьте исключительно для push/pop, call/ret

То есть интересен сам процесс, а не результат . Коммерческий подход - получить результат меньшей кровью и за меньшее время.


Может быть о разном говорим хотя названия похожи, асма на x86 под рукой нет. Для справки по МК от Fujitsu:
ENTER #N - Function entry processing (где N - объем резервируемой памяти)
LEAVE - Function exit processing
Первая резервирует память в стеке для локальных переменных, вторая освобождает. При этом определенный регистр получает значение адреса начала локальных переменных в стеке, через этот регистр выполняются все операции с локальными переменными.

Зашибись, еще осталось определить union этих структур для каждого уровня вложенности вызовов функций и экономия памяти будет на уровне... про оптимизацию кода и говорить нечего. Титанический труд, сложность сопровождения, т.п. и т.д. и ни какой практической выгоды данного метода. А если OS потребуется запустить то там вообще туши свет, этож придется для каждой задачи объявлять отдельные экземпляры структуры и везде таскать указатели на них. Что-то я не пойму в чем удобство?!
Написал считалку стека для MB9X, достаточно много анализировал расход памяти (стека в том числе) при разных подходах ее распределения. Пришел к выводу что ручное/статическое распределения памяти не дает экономии, часто даже проигрывает варианту с локальными переменными. Не думаю что для других процессоров ситуация будет иная.

Вы не любите котов? Вы просто не умеете их готовить
Сам долго исповедывал взгляды сходные вашим....Пока жизнь не заставила хорошенько покопаться в Сишных листингах. Итак, чем же код генерируемый компилятором отличается от написанного ручками?
1.Стартапом
2.Вызовами/завершениями функций.
Циклы, ветвления, присваивания итп. это и есть тривиальные задачи, котроые мало-мальски нормальный компилятор сгенерит также, как и самый искушенный программист.
Стартап освобождает от совершенно рутинной и тривиальной задачи начальной инициализации памяти.Если у вас на этот счет свои соображения - никто не запрещает вам подключать собственный стартап или вообще обходиться без такового.
Наиболее больной вопрос - вызовы функций и передача аргументов.
Да, нужно это или нет, компилятор приведет все вызовы к стандартному виду. Это дает вполне очевидное преимущество - не задумываться о порядке вызова функций - аргументы передаются гарантировано, гарантировано сохраняется контекст. Расплата за это - несколько больший расход стека и снижение быстродействия.
Однако, если вы более-менее хорошо знаете свой компилятор, это не есть проблема - вы четко знаете, сколько аргументов передастся через регистры, сколько раз вызовется push/pop. Дальше все в ваших руках - минимизация передаваемых аргументов, минимизация локальных переменных, привязка переменных к регистрам, inline -функции.Если вы правильно описали задачу - С быстро сгенерит вам работоспособный код, избавив от рутины и ошибок связанных с ней.
Если время позволяет ее вылизывать - вы можете сделать это не хуже , чем на ассемблере. Если нет, можете оставить все как есть. Меньшее количество текста и недоступные явно метки и распределение памяти сильно облегчит модификцию кода методом copy/paste. Вместе с тем они не будут представлять из себя черный ящик - на физические адреса вы сможете посмотреть в любой момент.

P.S.Здесь длинный спор между мной и dxp на тему оптимизации
у gcc и IAR. Приводится ассемблерный код, можете ознакомится.
http://electronix.ru/forum/index.php?showtopic=12284&st=75

Интересным является два подхода к оптимизации - прямолинейный у gcc и с вывертами у IAR. Так что, и компилятор можно подыскать по вкусу.

Данный ответ был мной предугадан
Жаль, знание возможностей данного языка не было бы лишним.
Экзотичность языка, прежде всего, связана с его малой известностью( если не сказать почти 0-й)
среди российских разработчиков аппаратуры и непониманием его идеалогии.

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

Судя по объёму флуда, - асм жив, и более того - alive forever.
Даже те, кто кодят на ЯВУ - всё равно его знают, хотя бы для того чтобы убедится, что высокоуровневый копмилятор не наворотил чего лишнего.

Про альтернативные соглашения при передаче аргументов в асмовской программе - полностью за и тоже использую этот метод.

Со всем уважением к Вам. Не надо никаких если, давайте просто оценим, что же показывает ваш тест!
8 битный AVR - 11+тыс. тактов.
16-битный MSP - 5+ тыс. тактов.
Только с учетом того, что рабочая частота AVR в два раза выше чем MSP, то 8-ми разрядный AVR по суммарной производительности практически равен производительности 16-ти разрядного MSP. Теперь об аппаратном умножителе. Судя по всему аппаратный умножитель AVR не применялся, следовательно для чистоты сравнения надо брать результат для MSP без аппаратного умножителя. Как Вы говорите, без аппаратного умножителя MSP справляется с задачей в 1.5 раза дольше, т.е. 7.5+ тыс. тактов. AVR - 11+ (~12) тыс. тактов
Теперь давайте учтем соотношение частот AVR-16Mhz, MSP-8Mhz.
Сведем все к MSPшным тактам. Один такт AVR равен 8/16 = 1/2 такта MSP.
Домножаем 12 тыс на 1/2
12 * 1/2 = 6тыс. MSPшных тактов.
И получаем, что AVR справляется с задачей за 6 тыс MSPшных тактов, а MSP за 7.5 тыс. тактов.
LOL, так получается AVR еще и "сделал" MSP на 25%.


Если РОНы "шире" - неизбежно операции с плавающей точкой потребуют меньше тактов для исполнения. Поэтому все законно и ожидаемо на 16-bit РОНах FP операции выполняются быстрее, чем на 8 битных. И более того, я сказал бы, что результаты этого теста больше в пользу AVR, т.к. имея в два раза меньшую разрядность, наблюдается замедлениние в два раза (практически линейная зависимость, что вполне естественно).


Я из вашего теста могу построить следующий вывод:
На одинаковых тактовых частотах AVR проигрывает MSP приблизительно в два раза (в большинстве задач - меньше чем в два раза). В реальных задачах AVR работает быстрее чем MSP430 за счет более высокой тактовой частоты ядра, поэтому добавив еще и факт, что AVR дешевле MSP - целесообразнее применять именно AVR.


Вы хотите сказать, что Bf будет 1.25+ тыс тактов выполнять код из Вашего теста?

Да что вы все прицепились к этому тесту?! Я сразу сказал и повторил, что это, во-первых, не тест как таковой, во-вторых, он не характеризует картину в полной мере - тут плавучка, а значит тут доминируют два фактора: 1) реализация библиотек, где определены подпрограммы операций с плавающей точкой; 2) эффективность ядра, т.к. операции в ядре доминируют над операциями с памятью. У MSP430, как и у любого фон Неймана, работа с памятью - слабое место. А вот ядро у него хорошее - регистровый файл, каждая операция в регистрах за один такт. Никакой 8-битных процессор тут не поспорит. Вот и все. И давайте уже оставим этот фрагмент кода.

На деле, как уже неоднократно сказал, MSP430 быстрее почти везде. При равных тактовых, ессно, т.к. сравнивается эффективность ядра.


Какую-то Вы тут софистику устроили. Зачем это? В реальных проектах MSP430 быстрее почти везде. Не в два раза, конечно, но процентов на 10-20. Это неоднократно установленный мной факт. Хотите поисследовать - пожалуйста, все в Ваших силах. Начать можете с того примера, который я уже предлагал, там почти одинаковый код. Очень хорошо видна реализация в обоих случаях. Упора на 16-битность данных там нет.


Вы еще забыли про потребление. Вот тот полином у меня вычислялся в проце, работающем на 5 МГц - хватало, - при этом весь МК побреблял около 2.4 мА при питании от 3 В. Дивайс батарейный. Найдите-ка мне такой AVR? В реальных задачах надо не максимальную скорость - тут главное, чтоб успевал с некоторым запасом. А вот потребление частенько требуется как можно меньше. Вот у меня МК посчитал результат, отправил его на вывод, и на боковую (в Idle). А из Idle он просыпается за 6 мкс. Таким образом, почти все неактивное время он спит, переход ко сну и обратно почти ничего не занимает. Эффективность максимальная.

Насчет того, дешевле ли AVR - это еще вопрос! AVR не предлагает полноценной замены MSP430 почти во всем: он медленее, он больше потребляет, у него почти во всем хуже периферия, у него нет такой удобной и гибкой системы распределения тактовых частот. Кроме того, у MSP430 на борту встроенный отладчик, который требует копеечного адаптера, в отличие от AVR, которому нужен недешевый JTAG-ICE, работающий к тому же нестабильнее и медленнее. Возможности отладчика в MSP430 новых моделей несравенно богаче - до 8 аппаратных брейкоинтов, не только на код, но и на данные, всякие условные брейкпоинты и т.д.

Преимущества AVR я уже перечислял выше - возможность 5 В питания, если кому актуально (мне,например, никогда это не было актуально - наоборот, от 5 В только лишнее энергопотребление), возможность внешней аппаратной шины у некоторых МК (опять же это только пара чипов, да и на MSP430 можно программно это организовать, написав класс-шлюз, чтобы работа со стороны программы была прозначной по отношению к этой шине), наличие EEPROM (здесь удобство AVR неоспоримо, но с MSP430 большого головняка не вышло - тоже написал класс, который манагит запись данных в блоки флеши попеременно, пользоваться этим просто и безопасно. С EEPROM'ом, кстати, тоже для надежности надо дополнительный код писать, с резервированием значений и проверкой при записи/чтении, т.ч. оно где-то одно к одному и выходит). Это практически все.

На деле существуют ситуации, когда AVR выгоднее и без этих оговорок - когда требования проекта удовлетворяются возможностями МК. Например, если хватает меги8, то и замечательно, ничего больше не нужно, даже если есть и более замечательные МК. Фактически же главным фактором является даже не возможности МК, а владение конкретным разработчиком тем или иным МК. Если человеку, работающему с AVR что-то в нем не хватает, он в большинстве случаев поставит недостающую часть снаружи (вплоть до применения второго МК), но не будет переходить на MSP430. Это психология и инертность мышления. А также требования по времени к выполнению работы на фоне внутренней увереннности в результате. По этой причине до сих пор жив 51-й (конечно, есть тут и другая причина - поддержка старых разработок, но старые разработки требуют старых МК, на оригинальном 12-тактовом ядре, а вот все новые, с новой периферией и новыми возможностями - это исключительно психология).


Что Вас удивляет? У него нет аппаратной поддержки плавающей точки.

Ссылка на интересную статью и ресурс для роботостроителей.
( в проекте используется ATMEGA128 )

http://rema.44.ru/about/persons/dobrinin/

P.S. Не ассемблер, но тоже интересный подход.
Не знаю, в какой топик лучше поместить.?

Еше 2 года назад писал Vxd драйверы под windows на асм.Умер 98 и умер ассемблер.Последнее за,
что он цеплялся , так это Vxd драйверы.Кто из вас пишет WDM драйверы на асм.?Хотя на WASM.ru
еще остались защитники ассемблера.Сидят и переписывают всю майкрософтскую библиотеку под
асм.Зачем? Также будет и микроконтроллерами.Меня уже не заставить писать на асм.Программу,
которую я напишу на Си за 1 час ,на асм. буду писать около месяца.Для меня это уже недопустимо.
Вспомните как противились использованию калькуляторов в школах.Боялись, что ученик разучится
умножать в столбик.Хотя калькулятор его избавил от того, что он мог не решить основную задачу
если не умножил бы 2х2.
Прощай асм.

Интересно, как, например, Вы будете делать сохранение констакста при переключении задач ОС без асма? Таких примеров еще можно найти. Поэтому давайте различать асм, как основной инструмент для написания программ, и как вспомогательный. Как основной он уже умер (за исключением отдельных случаев типа DSP, но и там тенденция однозначная). Как вспомогательный инструмент он жив и будет жив до тех пор, пока живы процессоры.

Ну вот ещё пример - о вечном. Совершенно прикладная прога - огромный объём вычислений с плавучкой - обработка больших объёмов экспериментальных данных. Среда разработки - даже никакой не МК, не ДСП -а борланд Ц++ под виндой 2000 - казалось бы какой в баню ассемблер - это даже не системный уровень.
Ан нет - мне показалось не влом потратить день на переписывание трёх строчек Ц на 18 строк асма х86 и сократить время обработки блока данных с 12 минут до 2. Временные затраты на отладу отбились за неделю использования проги. Опять же код переносим на любой х86 проц с FPU - то есть практически работает на любой машине.

Дык если с умом писать то разгонишся очень сильно
Было у меня куча проектов достаточно сложных и объемных и в 512байт влезал аж бегом.Асм нужен для того чтобы тока критические секции писать.