in4 писал(а):
вот отсюда можно начать изучать аппаратную реализацию диалекта языка Форт, сделанную автором, Чарльзом Муром.
http://www.intellasys.net/index.php?opt ... &Itemid=41 Да нет, не стоит оттуда начинать изучать, те технологии вряд ли будут доступны. А доступны другие, поближе.
Попытаюсь слегка резюмировать свои примечания по семинару в ИДМ-Плюс.
1. Методики оценки.
www.eembc.org - Embedded Microprocessor Benchmark Consortium. Если говорить о выходе куда-то в кремний, то без оценок подобного уровня будет сложно. Макеты, конечно же, не стоят таких денег, а раз так, оценки производительности макетов не имеют жесткого требования быть строго обоснованными.
2. Соотношение аппаратной архитектуры и системы команд.
При оценке аппаратной части система команд, конечно, играет роль. Но не столько набор операций, сколько архитектура самой системы. То есть до определенного предела не играет роли, что именно мы делаем и в каких сочетаниях. Допустим, 16-разрядная команда, АЛУ на 12 операций и регистровый файл формата 2R1W - это "раз". В этих пределах мы можем реализовать большое количество разных систем, которые будут существенно отличаться друг от друга с точки зрения программиста, но общие показатели с точки зрения цифровой схемотехники останутся теми же. И заменить одну систему команд на другую будет очень просто. Конечно, если мы вместо сумматора поставим умножитель, изменится площадь и потребление, но это уже неизбежный эффект (и тогда его нет смысла пытаться как-то учесть в проектировании).
А вот второстепенные с точки зрения программиста вещи могут неожиданно создать лишние проблемы (классически негативного вида - площадь больше, частота меньше). Например, одна-единственная многотактная команда заставит усложнить автомат декодирования).
3. Универсальность и специализация.
Очень мощная волна - быстрое создание специализированных МК. Чем силен тот же Microchip - позицией "мы сейчас поставим на кристалл именно то, что вам надо". Разработчики же находятся в окружении огромного количества поставщиков, которые наперебой предлагают им самые разные кристаллы, и к производительности отношение такое "чтобы хватало". Вобщем-то вопрос был сформулирован совершенно в точку (причем уже в парке, не помню кем) - "как 23% прироста производительности превратить в 23% прироста денег"? Причем не столько конструкторам, сколько убедить покупателей-разработчиков систем на этих МК, что им это выгодно. С учетом того, что разработчик обязательно скажет "ээ, нет, я все равно буду покупать с определенным запасом, чтобы потом при наладке-запуске изделия иметь возможность закрыть дыру, не мучаясь с компилятором-оптимизатором". То есть система команд, подобная минному полю, где чуть неэффективная последовательность операций резко снижает производительность, формально имеет право на существование, но сейчас планка вхождения в embedded-дизайн понижается, поскольку надо очень много устройств. И приходится считаться с тем, что на МК будет работать человек, который заявит, что он программист по необходимости, а потому писать будет так, как ему удобно. Опять же по поводу универсальности - если есть два МК, каждый из которых лучше в определенном типе задач, то новый универсальный никто и не возьмет. Практически единственное, что он обеспечивает - простоту освоения (один процессор вместо двух). А это нивелируется наличием ЯВУ для обоих МК и мощной волной методических материалов. Опять же различные виртуальные машины, облегчающие перенос алгоритмов.
4. Не процессор, а процессор
ы.
Чип-дизайн в области МК я представляю примерно так. Сначала мы "серфим на волне", выдавая серию макетов в ПЛИС. Вопросы совместимости, эффективности, производительности общей и частной можно решать на ходу и применительно к
конкретной задаче (дешевизна процесса по сравнению с изготовлением кремния это вполне позволяет). В этой связи было бы очень полезно иметь методики разносторонней оценки собранной системы, чтобы иметь возможность показать параметры будущего чипа конкретному заказчику. Мне существенно проще мыслить в терминах теории управления, где одним из центральных моментов является понятие обратной связи. Вот по семинару она получилось отсутствующей - эффективность системы оценивается не потому, что конкретный проект получает существенную выгоду, а потому, что были предприняты большие усилия по составлению "универсально-адекватной" рейтинговой системы. А наличие возможности регулировать что-то на ходу существенно эффективнее просто тщательной первоначальной подгонки. Здесь, конечно, очень большую помощь может оказать моделирование на уровне транзакций (на PC) и макетирование в ПЛИС для проверки эффективности схемотехнической реализации основных концепций.
Вход
Регистрация
Благодарности
Forth-FAQ
А вот насчет нафталина и недоступности - в сад, в сад... Все практически то же самое.
