Программируемая логика и ЦОС

Аппаратный переключатель задач в софтпроцессорах. Или аппаратный своп. Или MMU руками. :) Предудущие обсуждения по теме: Ветка для идей по продвинутому API для RTOS http://caxapa.ru/159013.html Архитектура Memory Hub - дальнейшее развития идей по многопроцессорным embedded системам http://caxapa.ru/160099.html Заговор плисоделателей? http://caxapa.ru/160205.html Размышлизма про софт процессоры, коих противником я всегда был :) http://caxapa.ru/160274.html Пусть в качестве памяти у нас будет DDR-266, 16 бит. Пусть размер страницы, которуя такая память готова выдать "за один заход" - 2 Кбайта. Число "тактов" 266 мгц - 20 (открытие-закрытие) + 1024 (2 байта за "такт") = 1044 такта. Или 255 Гкц темп следования пакетов по 2 кбайта. Пусть каждой задаче нужно 8 кбайта на код и 2 кбайта на данные. т.е. контекст задачи состоит из 5 пакетов по 2 кбайта. 4 пакета нужно просто загрузить для исполнения и 1 пакет надо загрузить, а потом выгрузить, чтобы сохранить все наработанные данные задачи. Итого "на квант времени задачи" у нас уйдет 4+1+1=6 пакетов по шине. Или ~42 Кгц темп переключения задач :) Заметим, очень нехило для любого современного проца. Берем софтпроцессор. На шину ему ставим несколько блоков памяти в режиме ПЗУ и несколько блоков в режиме ОЗУ: контекст ОСи и глобальные перемнные системы, кеш - для доступа к глобальным медленным переменным в SDRAM, и, например, 8 кбайт универсальных блоков - контекст задачи (код и данные). Поскольку работа процессора состоит не только из переключения задач, то ставим 2 комплекта блоков - с одним процессор работае, а второй в этой время "переключается". Всю периферию снабжаем интеллектом, с буферами в SDRAM. Чтобы она не нагружала процессор лишними запросами. В идеале каждой периферии по picoBlaze. Суть всей этой возни в следуюущем. На кристалле очень небольшое число блоков ОЗУ. Их надо использовать экономно. SDRAM, DDR в особенности, очень эффективна в пакетном режиме, и столь же НЕ эффективна на коротких пакетах. Меж тем классическая реализация процов - большой кеш и 4..8 словные пакеты ничего, кроме злобы вызвать не может - с точки зрения расходования ресурсов ПЛИС - это просто опитимальный сопособ их разбазарить. Предложенный метод хорошо позволяет выжать максимум из всех аппаратных блоков, и учитывает специфику embedded систем. 40 Гкц частота смены контекста задач - это очень тажело для бычных процов. Кеш там засрется по полной программе, и эффективная производительность будет никакая. Искусство программирования такой системы точно будет искусством, ибо все привычные POSIX-like подходы тут нервно курят. Поскольку памяти у нас много, но все связи задачи должны юыть в пределаз некого "адресного окна", то реентерабельные функции - это зло. Также нужно очень силено командовать кодом (сделать "руками" понятие классов в простом С, чтобы у каждой задачи был свой экземпляр класса), компилером и линкером. Тут как раз мои идеи по микрошедулерам точно в тему будут.