Средства и методы разработки

Обобщенный ассемблер и оптимизация алгоритмов. Интересно, такое реализовано где-нибудь? Пусть у нас есть некий алгоритм. Записанный в виде простых операций над простыми переменными (оставим структуры в покое). Простые операции - это полные аналоги команд RISC процессора. В отличие от С учитывают бит переноса и т.д. При кодирование такого алгоритма в АСМ нужно решить задачи: * что в регистры, что в память * оптимизация обращений в память. * алгоритмическая оптимизация - вынос константы за цикл и т.д. Т.е., конечно, монстры типа AVR берут и кодят, но нельзя ли как-нибудь упростить это мепроприятие? При трансдяции такого псевдокода в АSМ задача может быть решена многими способами - почему бы не автоматизировать поиск оптимального решения? Вплоть до тупого перебора - сделал трансляцию, прогнал на симуляторе, подсчитал количество тактов, сравнил и т.д. На ночь поставил - к утру имеешь веер трансляций с их характеристиками. Посмотрел, в какую сторону отработал оптимизатор - поправил изначальный код, и снова на оптимизацию. Конечно, для всего кода проекта это будет сильно муторнно, но для DSP задач, для time critical - самое то! Оптимизация работы с памятью RISC процессора - это вообще песня: * что в регистры, что в память * групповой обмен регистровый файл <-> память. В ARM это LDM STM, в других архитектурах есть нечто похожее. * оптимизация размещения переменных в памяти - чтобы в ордин кеш line попали и т.д. * максимальное резнесение обращений по времени - чтобы всякие кеши и шины успели отработать * учет работы внутреннего конвеера Вероятно, чем-то подобным занимаются компиляторы (хочется верить, но не факт что в полном объеме!). К чему это я? К портируемости ассемблерного кода. Пример - есть ARM (с хреновой кучей режимов - ARM, Thumb, Thumb-II, MAC и пр), есть CF, есть MIPS. Сколько нибудь сереьный оптимизированный алгоритм портировать на все сразу руками, да еще с учетом фич каждого конкретного компилера - нереально! Пишем наш алгоритим на псевдоязыке. Прямо в коментах в исходнике. Внешняя тулза транслирует это в asm {} для нужной архитуктуры в стиле нужного компилятора. Учет времени исполнения можно и на живом железе проверить в автоматическом режиме (полноценный симулятор, с учетом кеша и спекулятивного исполнения, можно и утрахаться делать). Написал псевдокод. Тут же test unit. Транслировал. Скомпилировал в виде отдельного файла (с обвязкой для тестирования.). Загрузил через JTAG. Прогнал тест. Проверил правильность и время выполнения. Занес в таблицу. Прогнал другой вариант и т.д. Для DSP - я вообще не понимаю, как без этого живут!!! Для современных процов, с кучей параллельных блоков - это же ё... можно все это в голове оптимизировать! "Вкалывают роботы". Я не знаю точно, как это сделать, но убежден, что лучше всего будет что-то типа: * написал псевдокод * по нему отрисовалась красивая картинка с ромбиками и стрелочками * подумал (примерно представляя, как процессор работает), пооптимизировал * натравил оптимизатор. Он откомментировал код и картинку, показывая - что вот тут слишком сильная связь по данным, тут у нас такое-то ограничение, а тут все ок - написанный алгоритим максимально оптимально ложится на выбранную структуру, оптимизировать дальше нехрен. * поправил код. Снова оптимизатор и т.д. Если машина и человек будут работать вместе, будет очень эффективно! Для всего остального С кода - это бычный кусок кода, который взаимодействует с ним обычнми методами. В плане TDD тоже все складно получается. Написали все на С. Прогнали тесты. Проверили время. Поняли, где засада. Начали отдельные куски оптимизировать, не забывая прогонять тесты. Я не уверен, что можно сделать полностью универсальную среду. Но вот иметь ряд заготовок на Python, и потом рихтовать их в рамках решения конкретной задачи - это самое то! Потом, по мере накопления опыта, глядишь, это и продуктом станет. Интересно, что-то похожее есть? Или я в своих теоретических изысканиях уже подошел к пониманию того, как работает компилятор? Что-то меня в последнее время тянет на DSL http://en.wikipedi …c_programming_language