Микроконтроллеры

..некоторые соображения: Лирика: Если опираться на какие-либо алгоритмические тесты (любые), то проблема оптимальной реализации алгоритмов обязательно будет иметь место. Всегда найдется кто-то, кто скажет, утирая сопли, что под этот uC уж он-то этот самый тест напишет лучше. Это для asm. Для С проблема еще более усугубляется, поскольку кроме человеческого фактора на объективность теста влияют особенности реализации конткретного компилятора, да еще конкретной версии. Поскольку тестироваться будет ядро, то неплохо определиться, на всякий случАй, что это такое. Скажем так, ядро есть микропрограмма + железо. Микропрограмма ядра, по сути, определяет, как будут выполняться команды (инструкции ядра). Состоит она из последовательности очень простых операций: выставить на внутреннюю шину, снять с шины, щелкнуть одну операцию АЛУ и т.д. Короче, это вся последовательность действий железа после дешифрирования инструкций (хе хе, включая само дешифрирование). Так вот, коли тестироваться будет ядро, то нужно иметь ввиду, что функциональная насыщенносить системы команд каждого конкретного ядра будет неизбежно влиять как на производительность выполнения любого алгоритма, вополняемым под ним, так и на объем используемых ресурсов (командная память). К примеру, ядро некоего uC X имеет инструкции для выполнения битовых операций, а вот ядро uC Y - не имеет. Какое-то ядро имеет развитую систему условных ветвлений, а другое - нет. В любом случае, если программист не получает некоторой функции в ядре, в виде одной инструкции, то он будет вынужден использовать некую комбинацию инструкций для ее реализации (те же условные ветвления). Ну, это все знают. Конкретные типы uC не рассматриваю, дабы не усугулять флеймом. К чему это все: Предлагаю опуститься ниже каких-либо реализаций конкретных алгоритмов. До базовых алгоритмических функциональностей. Для начала можно взять наиболее часто применяемые (проверка на ноль, проверки < > <= => ==, все битовые операции и их комбинации и т.д.). В принципе, любой алгоритм в своей реализации сводится к ним (они - один из промежуточных этапов), вот их-то и вычленяем. Цель этих телодвижений: опуститься до уровня функциональностей ("кирпичей"), реализацию которых для каждого ядра можно будет легко и наглядно свести к самому оптимальному способу (критерий оптимальности - ресурсы, требуемые для реализации). И доказать обратное будет уже трудно,э-э.. невозможно. Кроме того, исходники должны быть доступны всем. Вот уже избавились от субъективности. Далее. Составить набор базовых функциональностей, принять большинством голосов и прогонять все тестируемые ядра для каждого. Получим довольно большую таблицу. Совершенно очевидно, что ядро, выполняющее ВСЕ атомарные алгоритмический функциональности за меньшее время, чем осталные респонденты, при прочих равных внешних условиях (тактовая F) будет наиболее производительным под ВСЕМИ программами, использующими эти функциональности. Каким бы гениальным программер не был, он выше этой планки не прыгнет - ведь он по-любому на эти "кирпичи" опирается явно (asm'исты) или не явно (многие С'ники). Не спорю, будут возможны варианы - какое-то ядро будет хорошо в одном, но хуже остальных в другом. Но это и есть, самое оно - все "кирпичи" перед глазами, то бишь почва для объективных выводов. Чем больше функциональностей будет включать тест-таблица - тем ближе к истине будут результаты тестирования. В идеале их надо охватить все. Вообще-то, ежели репу почесать, то их вполне обозримое количество... Что касается плавающей точки, деления, умножения, то тактика такая: если хотя бы одно из сравниваемых ядер имеет это в аппаратной реализации, то получает бонус в соответствующей графе в виде жирного плюса, а остальные - прочерки. В том случае, когда ни одно ядро не имеет такой возможности, эти тесты просто отбрасываются, поскольку сами по себе будут состоять из базовых алгоритмических функциональностей, а это уже субъективность, зависящая от программера... Ну, вот так, вкратце..