реклама на сайте
подробности

 
 
> Micro-Kernel on Chip, прошу анализ, критику, идеи и т.д. и т.п.
alman
сообщение Dec 24 2012, 10:30
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 45
Регистрация: 22-12-10
Из: Россия, Ростовская обл.
Пользователь №: 61 800



Уважаемые господа и дамы, позвольте проконсультироваться по вопросу аппаратного микроядра. Я слаб в микроэлектронике, поэтому прошу отнестиcь снисходетельно.

Итак, существует микроядро L4 спецификации X2. Я довольно давно с ним работаю и приблизительно столько же времени мечтаю увидеть его реализованным на кристалле. Чтобы добавить поддержку микроядра в микропроцесссор, необходимо модифицировать два блока - MMU и декодер команд.

К системе команд добавляется несколько команд. Главная команда Inter Process Communication (IPC). Для её реализации необходимо выделить на кристалле блок памяти для описания задач - Task Control Block (TCB). В общем случае TCB одной задачи должен включать следующе элементы - копия всех регистров ALU, буфер для описания соообщения (64-регистра), поля, описывающие задачу (приоритет задачи, текущий квант времени), данные для MMU, обеспечивающие привязку таблицы страниц к задаче, возможно что-то ещё. Адрес TCB в памяти одновременно является глобальным идентификатором задачи (нити исполнения, программного потока).

Команда IPC включает две фазы - фазу передачи сообщения и фазу приёма сообщения. Аргументом команды IPC является регистр, содержащий идентификатор задачи (физический адрес TCB), с котором происходит обмен сообщениям.

Что происходит, когда декодер команд распознаёт команду IPC? Анализирует фазы команды. Если фазы передачи нет, то процессор устанавливает флаг ожидания в TCB текущей задачи, сохраняет регистры ALU в TCB, затем выбирает TCB с наивысшим приоритетом, не находящимся в фазе ожидания приёма, и загружет ALU из выбранного TCB - в результате происходит переключение задачи.

В случае, если команда IPC имеет фазу передачи, то процессор анализирует состояние процесса-приёмника (поле в его TCB) и при условии, что приёмник находится в состоянии ожидания (от передающего или любого процесса), происходит обмен сообщениями - регистры сообщения копируются из TCB передатчика в TCB приёмника. В случае, если сообщение подразумевает передачу блоков памяти, процессор также передаёт их (на основе данных буфера описателя сообщения). В случае, если сообщение подразумевает mapping виртуальной памяти - эта функция также выполняется командой IPC.

Важным, на мой взгляд, моментом, является ситуация, когда блокированы все IPC - например, каждая задача находится в ожидании готовности другой или какого либо события. В этом случае процессор должен переходит в состояние низкого потребления энергии.

Другим важным моментом являются прерывания. Они так же организованы через IPC. Т.е. обработчик прерывания это задача, которая ждёт сообщение от источника прерываний. Таким образом любое прерывание может вывести процессор из состояния низкого энергопотребления, продолжив выполнение задачи, ожидающей IPC.

Ещё одна возможность L4 IPC - аттрибут, указывающий два интервала времени - время передачи сообщения и время приёма сообщения. Время описывается экпонентиальной величиной с двумя граничными состояниями - 0 - не блокироваться, если удалённая сторона не готова и бесконечность - ждать готовности удалённой стороны. Прияём, время передачи и время приёма - независимы.

Отдельно хочется сказать о многопоточности и многозадачности. Я использовал термин задача, для общего описания последовательности команд. Задачи разделяются на нити и процессы. Нити - это задачи имеющие общую таблицу страниц - они работают в одном адресном пространстве. Процессы отличаются от нитей тем, что каждый процесс имеет свою собственную таблицу страниц, т.е. задачи работают в выделенных адресных пространствах. Таким образом в случае обмена сообщениями между нитями и между процессами, отличает лишь тем, происходит ли переключение таблицы страниц или нет.

И наконец, MMU. Отличе L4 MMU от традиционных MMU является возможность использования страниц разных размером. Т.е. описатель виртуальной страницы содержит аттрибут, описывающий её размер. Таким образом блок памяти, например, 96 Кб, может быть описан двумя выравненными виртуальными страницами - 64Кб и 32Кб. Т.е. MMU должен поддерживать страницы с размерами, minimal_page_size * 2 в степени S.
Где S лежит в интервале от 0 до значения, описывающего полное адресное пространство.


Надеюсь, я смог достаточно понятно выразить "требования" к процессору с аппаратной поддержкой мироядра L4, хотя. многие моменты сознательно/нечайно упустил. Приглашаю к диалогу о возможности/трудоёмкости реализации данного расширения. С радостью отвечу на вопросы по микроядру L4.

Кому и для чего может понадобится такой процессор? Это процессор нужнем мне - я реализовал POSIX совместимую операционную систему на базе примитивов L4X2, которая вполне удачно и оптимально использует идеи этого микроядра.

В качестве бонуса прилагаю к теме раритетную спецификацию L4 X2, из которой ещё не убрали поддержку ARM. В свежих версиях спецификации остались только IA32, AMD64, PowerPC, PowerPC64.

Сообщение отредактировал alman - Dec 24 2012, 10:34
Прикрепленные файлы
Прикрепленный файл  l4_x2.pdf ( 1.01 мегабайт ) Кол-во скачиваний: 29
 
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
yes
сообщение Dec 24 2012, 14:10
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 2 198
Регистрация: 23-12-04
Пользователь №: 1 640



по первому впечатлению: все это реализуется софтверно, а делать в железе совершенно бессмыслено
передача TCB происходит редко и ее ускорение бессмысленно (тем более, что это будет тот же набор LD/ST, который занимает одинаково времени без разницы софтверный он или хардверный), оверхед на контрол-флоу и так 0
для MMU если minimal_page_size=4К то это стандартный MMU типа SRMMU (SR= sparc reference), выделяется потребное кол-во страниц и им непрерывное физическое пространство (как бонус - физическое пр-во может быть не непрерывным и множитель необязательно 2^S
------------------------
но может я что-то не понимаю в "тяжелых" архитектурах
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Jan 21 2013, 12:24
Сообщение #3


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(yes @ Dec 24 2012, 16:10) *
по первому впечатлению: все это реализуется софтверно, а делать в железе совершенно бессмыслено
передача TCB происходит редко и ее ускорение бессмысленно


С этим согласен. Вытеснение задач должно происходить как можно реже. Поскольку приводит к долгой очистке кэшей.
Ускорение передачи структуры TCB в пару сотен байт никакой роли не играет по сравнению с длительностью обновления многокилобайтных кэшей.
Да и TCB в предложенном варианте какой-то упрощенный, не учитываются как минимум сопроцессоры.
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 24th July 2025 - 08:35
Рейтинг@Mail.ru


Страница сгенерированна за 0.01813 секунд с 7
ELECTRONIX ©2004-2016