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

 
 
> 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
alman
сообщение Jan 21 2013, 20:07
Сообщение #4


Участник
*

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



Цитата(AlexandrY @ Jan 21 2013, 16:24) *
С этим согласен. Вытеснение задач должно происходить как можно реже. Поскольку приводит к долгой очистке кэшей.


В случае обработки системных вызовов в одном потоке, вытеснение происходит реже, чем в случае асинхронной борьбы за ресурсы.

Цитата(AlexandrY @ Jan 21 2013, 16:24) *
Ускорение передачи структуры TCB в пару сотен байт никакой роли не играет по сравнению с длительностью обновления многокилобайтных кэшей.
Да и TCB в предложенном варианте какой-то упрощенный, не учитываются как минимум сопроцессоры.


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


Цитата(yes @ Jan 21 2013, 16:32) *
стоило бы дать сцылку на http://l4hq.org/ , чтоб было понятно, о чем речь


Простите, моё упущение.

Цитата(yes @ Jan 21 2013, 16:32) *
из общих соображений - например архитектура SPARC поддерживает аппаратные банки регистров, которые не требует сохранения на стеке и при желании, можно рассматривать, как аппаратную поддержку L4


А ещё механизм "сверхбыстрых" прерываний на ARM имеет нечто общее с идеями L4.

Цитата(yes @ Jan 21 2013, 16:32) *
дало ли это какие-либо преимущества порту на SPARCv9 ? по-моему нет


Не сочтите за оффтопик, но это случай когда аппаратное решение обогнало программное. Если не ошибаюсь, то ли в Sun OS, то ли в Солярис, то ли в обеих, на каждую пользовательскую задачу создавалась задача в ядре. По моему скромному мнению, именно этот факт превратил преимущество в недостаток.

Цитата(yes @ Jan 21 2013, 16:32) *
----------------

для проверки таких идей нужно вначале написать симулятор гипотетического процессора (для этого не нужно знать VHDL, достаточно С) с простым ограничением - достать слово из памяти 1 так, все остальное тоже 1 такт

после сравнить выигрышь от работы приложения с этим микроядом на таком симуляторе и на симуляторе того же SPARC-а - их полно.
есть помоему, и для ARM-а симуляторы и для МИПСа

наверняка можно найти с открытым кодом и добавлять в нее симуляцию хитрых инструкций

после этого уже утверждать, что предлагаемые изменения имеют смысл

--------------------


А само микроядро L4 Pistachio в MS Virtual PC, VM Ware Player или в Oracle Virtual Box, не может ли являться достаточным доказательством?

32-х битная версия http://narod.ru/disk/30145508001/floppy.img.html
64-х битная версия для Virtual Box - https://docs.google.com/file/d/0Bzo8HAmNqHg...2hxVEVXdlk/edit

Цитата(yes @ Jan 21 2013, 16:32) *
--------------------

по поводу MMU - там проблема с кэшированием (САМ память так сказать), то есть избежать трансляции виртуальных адресов в физические и дать ответ попали в кэш или нет быстрее - это стоит многого и для произвольных страниц с потерей механизма кэширования будет большая потеря производительности


Часть информации о таблице страниц можно поместить непосредственно в TCB. В этом случае можно "закешировать" какие-то опорные данные для MMU.

Кстати, дать гарантию на кое-какое увеличение быстродействия можно. Самый простой пример, это выборка команд. Например, сегмент кода можно описать меньшим числом страниц - меньше page fault. На выборке кода из универсальных страниц можно значительно разгрузить MMU.

Беда в том, что я не могу представить, как работает MMU. Если бы кто-нибудь подтолкнул к подробному низкоуровневому описанию работы MMU, можно было бы сгенерировать идею.

Цитата(yes @ Jan 21 2013, 16:32) *
с аппаратными регистрами - посмотрите тот же SPARC (например sparcv8.pdf) там есть аппаратные банки регистров, но была у меня ультраспарковская станция, она сильно проигрывала по производительности пню с такой же тактовой (а у пня архитектура тупая до невозможности, вся хитрость в реализации)


Простите, а какая ОС исполнялась на Sparc, а какая на пне? Ядро Windows NT очень хорошо спроектровано. Уверен, что в данном случае выиграла не архитектура процессора, а архитектура операционной системы.


Есть ли какие либо возражения об использовании аппаратного L4 в микроконтроллерах без MMU? Ведь обменваться сообщения можно и в одном адресном пространстве.
Go to the top of the page
 
+Quote Post



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

 


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


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