[alman 0]

Уважаемые господа и дамы, позвольте проконсультироваться по вопросу аппаратного микроядра. Я слаб в микроэлектронике, поэтому прошу отнести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.

l4_x2.pdf

Изменено 24 декабря, 2012 пользователем alman

[Mad_kvmg 0]

Ну, а от людей чего Вы хотите-то?

Пообщаться на тему возможности/трудоемкости, да возможно,

да трудоемко за вечер пятницы не сделаешь.

Если ищете outsource, то есть другой раздел форума на эту тему.

Если это research, то как-то переформулируйте свою просьбу,

а не то что вот мне надо, давай те все вместе напряжемся и сделаем.

[alman 0]

Ну, а от людей чего Вы хотите-то?

Пообщаться на тему возможности/трудоемкости, да возможно,

да трудоемко за вечер пятницы не сделаешь.

 

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

 

Если ищете outsource, то есть другой раздел форума на эту тему.

 

Пока не ищу. Да смысла нет приходить с чужим PDF (L4 X2 Reference manual) и говорить: "Сделайте такое, как тут описано, только в железе".

 

Если это research, то как-то переформулируйте свою просьбу,

 

Для начала хотелось бы узнать, что такое "плавающая маска для виртуальных адресов в TLB"? Мне подсказали, что она необходима для реализации MMU с поддержкой FlexPages - виртульных страниц различного размера.

 

а не то что вот мне надо, давай те все вместе напряжемся и сделаем.

Нет нет, я никого ни к чему не принуждаю. Лишь надеюсь, что тема аппаратной реализации синхронных сообщений и расширенного MMU будет интересна кому-либо ещё. Мне кажется тут даже две темы - можно не следовать стандарту и сделать микрокронтроллер без виртуальной памяти, но с поддержкой сообщений. Т.е. тему можно расценивать так же и как обращение к разработчикам оригинальных CPU.

 

 

[yes 5]

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

передача TCB происходит редко и ее ускорение бессмысленно (тем более, что это будет тот же набор LD/ST, который занимает одинаково времени без разницы софтверный он или хардверный), оверхед на контрол-флоу и так 0

для MMU если minimal_page_size=4К то это стандартный MMU типа SRMMU (SR= sparc reference), выделяется потребное кол-во страниц и им непрерывное физическое пространство (как бонус - физическое пр-во может быть не непрерывным и множитель необязательно 2^S

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

но может я что-то не понимаю в "тяжелых" архитектурах

[alman 0]

передача TCB происходит редко и ее ускорение бессмысленно (тем более, что это будет тот же набор LD/ST, который занимает одинаково времени без разницы софтверный он или хардверный), оверхед на контрол-флоу и так 0

 

Позвольте не согласиться в Вами, передача TCB происходит при любом системном вызове. Некоторый overhead при перегрузке ALU с лихвой компенисруется упрощением софтверной части. Первое что можно гарантировать - отстутствие необходимости в реализации объектов синхронизации. Если это не оффтопик, то я бы постарался обосновать эту точку зрения. В любом случае, если аппаратная реализация сократит хотя бы несколько тактов, это будет уже выигрыш в скорости по сравнению с программной реализацией.

 

для MMU если minimal_page_size=4К то это стандартный MMU типа SRMMU (SR= sparc reference), выделяется потребное кол-во страниц и им непрерывное физическое пространство (как бонус - физическое пр-во может быть не непрерывным и множитель необязательно 2^S

 

Дело в том, что операция отображения страниц (когда одна задача отображает свою виртуальную страницу в адресное пространство другой задачи) реализована как сообщение (через команду IPC). Количество страниц, которые можно поместить в сообщении, ограничено размером буфера собщения (64-слова). Одна страница занимает два слова. Поэтому максимальный размер отображаемый памяти в одном сообщении - 32 * 4К = 128Кб. В случае FlexPages - 32 страницы, помещающиеся в сообщении, способны описать любой регион памяти.

 

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

но может я что-то не понимаю в "тяжелых" архитектурах

 

Спасибо, что даёте шанс отстоять точку зрения.

Изменено 24 декабря, 2012 пользователем alman

[alman 0]

Выношу на ваш суд спецификацию "Формальное описание аппаратного микроядра L4" - http://l4os.ru/download/L4_Hard_20130119.pdf.

 

Документ описывает расширение системы команд микропроцессоров для реализации аппаратной поддержки микроядра L4 ревизии X2 и совместимых спецификаций. Основная идея в том, чтобы реализовать эти идеи в уже существующих микропроцессорах. Некоторую информацию о том, что такое аппаратное микроядро, можно почерпнуть из следующих обсуждений:

 

1. http://forum.ixbt.com/post.cgi?id=print:8:...ser=%20xameleon
2. http://www.linux.org.ru/forum/talks/8719518
3. http://forum.ixbt.com/post.cgi?id=print:8:...ser=%20xameleon
4. http://habrahabr.ru/post/113654/

 

Ну, а от людей чего Вы хотите-то?

 

Микропроцессор, соответствующий формальному описанию :)

 

 

[AlexandrY 3]

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

передача TCB происходит редко и ее ускорение бессмысленно

 

С этим согласен. Вытеснение задач должно происходить как можно реже. Поскольку приводит к долгой очистке кэшей.

Ускорение передачи структуры TCB в пару сотен байт никакой роли не играет по сравнению с длительностью обновления многокилобайтных кэшей.

Да и TCB в предложенном варианте какой-то упрощенный, не учитываются как минимум сопроцессоры.

[yes 5]

стоило бы дать сцылку на http://l4hq.org/ , чтоб было понятно, о чем речь

 

из общих соображений - например архитектура SPARC поддерживает аппаратные банки регистров, которые не требует сохранения на стеке и при желании, можно рассматривать, как аппаратную поддержку L4

 

дало ли это какие-либо преимущества порту на SPARCv9 ? по-моему нет

 

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

 

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

 

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

есть помоему, и для ARM-а симуляторы и для МИПСа

 

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

 

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

 

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

 

btw: симулятор с открытым кодом http://en.wikipedia.org/wiki/QEMU

 

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

 

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

 

с аппаратными регистрами - посмотрите тот же SPARC (например sparcv8.pdf) там есть аппаратные банки регистров, но была у меня ультраспарковская станция, она сильно проигрывала по производительности пню с такой же тактовой (а у пня архитектура тупая до невозможности, вся хитрость в реализации)

 

[alman 0]

С этим согласен. Вытеснение задач должно происходить как можно реже. Поскольку приводит к долгой очистке кэшей.

 

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

 

Ускорение передачи структуры TCB в пару сотен байт никакой роли не играет по сравнению с длительностью обновления многокилобайтных кэшей.

Да и TCB в предложенном варианте какой-то упрощенный, не учитываются как минимум сопроцессоры.

 

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

 

 

стоило бы дать сцылку на http://l4hq.org/ , чтоб было понятно, о чем речь

 

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

 

из общих соображений - например архитектура SPARC поддерживает аппаратные банки регистров, которые не требует сохранения на стеке и при желании, можно рассматривать, как аппаратную поддержку L4

 

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

 

дало ли это какие-либо преимущества порту на SPARCv9 ? по-моему нет

 

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

 

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

 

для проверки таких идей нужно вначале написать симулятор гипотетического процессора (для этого не нужно знать 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

 

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

 

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

 

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

 

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

 

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

 

с аппаратными регистрами - посмотрите тот же SPARC (например sparcv8.pdf) там есть аппаратные банки регистров, но была у меня ультраспарковская станция, она сильно проигрывала по производительности пню с такой же тактовой (а у пня архитектура тупая до невозможности, вся хитрость в реализации)

 

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

 

 

Есть ли какие либо возражения об использовании аппаратного L4 в микроконтроллерах без MMU? Ведь обменваться сообщения можно и в одном адресном пространстве.

[yes 5]

чтоб излишне не цитировать -

 

что ядро работает я не сомневаюсь, использовать симулятор ПРОЦЕССОРА я предлагаю, чтобы понять, какие фичи имеет делать аппаратно, а какие нет

 

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

 

про реализацию кэша и ММУ я пишу, что это тяжелое аппаратное решение, которое требует много ресурсов (кремния) и достаточно трудоемко

сделать его последовательно, как описывают в ISA на процессоры смысла не имеет, так как будет медленно. поэтому там приходится хитрить. и "утяжелять" без достаточных оснований не очень хорошо

 

------

 

сравнивал СПАРК и ПЕНЬ под линуксом

 

у SUN-а есть кстати OpenSPARC, который доступен в виде исходных кодов и документирован - там можно ознакомится с тем как процессоры устроены (и pdf и исходники). но проект тяжелый, я например, не поднимал, но в конфе есть люди, которые могут проконсультировать