Я в правильное место попал?

Если ты хочешь чтобы тебя втоптали в грязь или чтобы тебе забрызгали монитор жиром троллей, то да...
А вообще — просто спрашивай(а вдруг есть среди СПВ С по В). Всё равно прибежит тазхейт и потрёт все с -20:(

Специалистов я бы все-таки в девелопменте спрашивал.

Пни когда выложишь rtl на опенкоресы

Когда выложит «пни»...

А юристы тебя каким боком интересуют?

Stahl:

Если ты хочешь чтобы тебя втоптали в грязь или чтобы тебе забрызгали монитор жиром троллей, то да...

Не думаю, что тролли понимают значение понятия «Большой регистровый файл».

leave:

Специалистов я бы все-таки в девелопменте спрашивал.

Тема на самом деле флеймообразующая, там её быстрее отмодерируют.

slackwarrior:

Пни когда выложишь rtl на опенкоресы

Никогда. Сам на не пишу ни на Verilog, ни на VHDL. Предлагаю не процессор, а спецификаию расширения для существующих процессоров. Точнее даже не предлагаю, а вопрошаю. В общем, я сам запутался, но формальное описание почти завершено.

another:

А юристы тебя каким боком интересуют?

Результат очаровал и хотелось бы получить максимум профита и минимум головняка.

А юристы тебя каким боком интересуют?

С Эпплом судится, зачем де еще?

У ТСа вполне себе коммерческий проект, который при соответсвующем финансировании может даже взлететь.

Запахло едой.

Круто, чё. Позовите, когда заработает не на бумаге.

Даешь аппаратный КДЕ!

Ну или хотябы для начала перевести плазмоиды с JavaScript на Верилог

Начни с какого нибудь списка рассылки HURD и HURD-L4. Если реально обладаешь квалификацией на заявленную тобой вундервафлю. Как исследовательский проект с переспективой пойти на освоение грантов имхо вполне себе тема, и требует ресурса который есть у среднего левела хоббистов. Владение шаманством подчинения своей воле fpga и деньгами на продукцию xilinx. Но это если ты не являешься очередным дениской поповым.

Правда судя по твоей дискуссией с тейлганером ты очередной фрик, даже если этой магией владеешь. Так что в приличных местах тебя пошлют и остается только ЛОР.

PS
Еще бы интересно сделать обзор научной литературы на тему почему эта очевидная уже больше 20 лет идея до сих пор не осуществлена.

Сам на не пишу ни на Verilog, ни на VHDL. Предлагаю не процессор, а спецификаию расширения для существующих процессоров.

Пока не будет эталонной реализации всё это пустой трёп и с тобой никто дела иметь не будет. Если не знаешь HDL-языки, очевидно же, изучай.

Бонусом идёт аппаратный планировщик

и в чём собственно здесь бонус?

kernel тебе правильно про литературу написал кстати.

расширения системы команд микропроцессора

Без сарказма: а в чем профит? Повышение производительности? Это не очевидно, учитывая причины провалила java/lisp-процессоров. Вобщем интересно почитать.

учитывая причины провалила java/lisp-процессоров

какие тут причины?

ARMv2 кажется доступно для использования в HDL кодах. Посмотри на marsohod.org

Java процессоров вполне себе живут в ARM. man Jazelle

Хорошая идея. Вот только кто б такие камни печатал?

Спасибо. Тезисы очень просты:

• 1. Задача это последовательность команд, обрабатываемая исполнительным устройством.

• Каждая задача имеет собственный «Блок регистров задачи» (TCB) и однозначно определяется и описывается им. Переключение задач осуществляется посредством коммутации блока регистров задачи (TCB) с исполнительным устройством.
• Блок регистров задачи состоит из четырех секций:
  • регистры общего назначения;
  • регистры сообщений;
  • регистры планировщика;
  • регистры управления адресным пространством.
• Регистровое пространство процесса включает TCB и коммутируемый буфер сообщений. Процесс – это одна или несколько задач, разделяющие одну и ту же таблицу страниц (адресное пространство). В системах без MMU возможно существование единственного процесса – все задачи исполняются в едином адресном пространстве. Любые две задачи, исполняющиеся в различных адресных пространствах, по отношению друг к другу являются процессами.
• Поток – это задача, исполняющаяся в адресном пространстве какого-либо процесса. Любые две задачи, исполняющиеся в едином адресном пространстве, по отношению друг к другу являются потоками.
• Планировщик – функциональный блок микропроцессора, расширяющий систему команд и предоставляющий возможность обмена синхронными сообщениями между задачами.
• Любая операция, будь то обмен сообщениями, либо прерывание (от устройства или таймера) или аппаратное исключение (page fault, protection fault, bus error и т.д.), организуется через вход в планировщик с установленными регистрами сообщений.
• Задача имеет доступ только к регистрам своего TCB. Планировщик имеет доступ ко всем TCB.
• Доступ EA означает, что регистры с таким типом доступа могут быть записаны планировщиком.
• Системные вызовы спецификации L4 ревизии X2, которые не определены данным документом, могут быть реализованы в виде сообщений планировщику.

Далее следует скучное описание регистров, алгоритмов, разбавленое описанием «что, для чего и как».

Еще бы интересно сделать обзор научной литературы на тему почему эта очевидная уже больше 20 лет идея до сих пор не осуществлена.

Она попросту не была востребована. Сейчас востребована, по крайней я знаю одного человека, которому это нужно :)

Java процессоров вполне себе живут в ARM. man Jazelle

живут но не используются. а если и используются то проприетарщиной т.к. Jazelle нужно лицензировать и документация отсутствует в свободном доступе.

и в чём собственно здесь бонус?

Чтобы это понять, надо представить как он работает. Я помогу. :)

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

Без сарказма: а в чем профит? Повышение производительности?

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

поздравляю, ты описал то, как оно сейчас и работает. только ipc_exchange не новая инструкция порцессора, а прерывание от таймера.

и что, процессорам с jazelle не нужна vm?

нужна для управления памятью/сборки мусора. Прикладной код выполняется с аппаратным JIT

Она попросту не была востребована. Сейчас востребована,

В «cаенс фрикс».

Было востребованно. Микроядра это большое и сильное направление в академическом айти. А то что нужен процессор ЕМНИП, консенсу достигнуты во времена Mach3.
Обойти это ограничение попытались с L4 - когда предложили решение по которому микрокернел не должен вылезать кеша.
Результатом стало множество проектов с L4 и новое поколение академических гранто-осовоений на это дело. Преимущество было в том что в отличие от «счас запилим свой процессор для фриков», тут используется массовое железо - с соотвествующим соотношением цена/качество. И нахождением отдельных нишь где это применимо.

При этом по опыту Hurd/L4 vs LInux/L4 можно сказать что теперь не понос так золотуха. То есть всплыла вторая огромная проблема микроядер - сложность программирования под них. В рабочих подходах к дизайну взаимодействия компонентов обычно соформулированный протокол такового - завершающий этап. То есть сначала хаос и нахождение полуимперическим потем протоколов - потоом кодирование протокола в какие то ограничивающие рамки.
А с микроядрами так не получается. Цикл «придумать протокол и потестить» в них на порядок более дорогой чем для «обычного стирального порошка». Фейл.

по крайней я знаю одного человека, которому это нужно :)

И это во первых фрик а во вторых он живет в РФ или какой-нибудь беларусии. В принципе да, теоретически вот такая попильная тема, под бравуными лозунгами «спасем россию матушку от басурманских закладок!»

Практически там где пилят никого не пустят, а если внезапно поймут что идея годная - просто там где пилят эльбрус наколенке накатают тут же аналог такого расширения. Тем более что они профессионально в этим занимаются - тегированная память, все дела.

Было востребованно. Микроядра это большое и сильное направление в академическом айти. А то что нужен процессор ЕМНИП, консенсу достигнуты во времена Mach3.

Единственное, что хорошего породило Mach3 - это Mac OS X.

Обойти это ограничение попытались с L4 - когда предложили решение по которому микрокернел не должен вылезать кеша.
Результатом стало множество проектов с L4 и новое поколение академических гранто-осовоений на это дело.

Ну Вы даёте! Я чуть со стула не упал. Почему пытались? ДОКАЗАЛИ ЖЕ! Неужели Вы не заметили, что я говорю о L4 X2?

При этом по опыту Hurd/L4 vs LInux/L4 можно сказать что теперь не понос так золотуха.

Что Вы хотели, когда студенты, только что понявшие как работают семафоры и критические секции, начинаю пилить синхронные ядра? Последний раз на Hurd (скорее всего на Hurd/L4) я смотрел около 10 лет назад и с тех пор у меня навсегда пропал к нему интерес.

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

Всё в этом мире сложно. Нужно всего-лишь понять некоторые базовые принципы L4X2 и сложное становится простым.

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

Вижу, Вы человек в этих вопросах опытный. Вот, посмотрите на протокол - http://l4os.ru/ProtocolSpecRus.pdf - я его очень давно не правил и код, его реализующий, в очередной раз обогнал протокол. Тем не менее, надеюсь, Вы сможете составить некоторое впечатление о дизайне взаимодействия компонентов. Приблизительно то же самое, но несколько большем объёме, реализует ядро Линукса.

А с микроядрами так не получается. Цикл «придумать протокол и потестить» в них на порядок более дорогой чем для «обычного стирального порошка». Фейл.

И это замечательно, что у конкуренотов не получается. Что может быть приятнее, чем фейл конкурентов. Если бы Hurd/L4 меня не разочаровал, то мы бы сейчас обсуждали что-нибудь другое, например очередной оконный менеджер.

нужна для управления памятью/сборки мусора

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

Единственное, что хорошего породило Mach3 - это Mac OS X.

Оно породило все следующее поколение микроядер, типа L4. Это наука а не кодерство, тут одни идеи порождают другие идеи.

Ну Вы даёте! Я чуть со стула не упал. Почему пытались? ДОКАЗАЛИ ЖЕ! Неужели Вы не заметили, что я говорю о L4 X2?

Не понимаю смысла этой фразы. То что L4 удалось снизить до приемлемых латентность приема/отправки сообщений путем помещения микроядра в кеш (которое стало вследствие этого наноядром) это очевидно.
Только вот изначально все микроядра были придуманы как нечто что жизнь облегчит. А стали хорошим направлением освоения грантов - не более.

то Вы хотели, когда студенты, только что понявшие как работают семафоры и критические секции, начинаю пилить синхронные ядра?
Последний раз на Hurd (скорее всего на Hurd/L4) я смотрел около 10 лет назад и с тех пор у меня навсегда пропал к нему интерес.

Это вот ваше высокомерие вас погубит.

Всё в этом мире сложно. Нужно всего-лишь понять некоторые базовые принципы L4X2 и сложное становится простым.

Это ответ красноглазого школьника. Еще раз - я говорю о вполне конкретной вещи, try-n-error цикле. Если под чтото программировать сложно а под чтото другое - просто, вокруг этого развиваются вполне характерные социальные процессы.

Вижу, Вы человек в этих вопросах опытный. Вот, посмотрите на протокол - http://l4os.ru/ProtocolSpecRus.pdf - я его очень давно не правил и код, его реализующий, в очередной раз обогнал протокол. Тем не менее, надеюсь, Вы сможете составить некоторое впечатление о дизайне взаимодействия компонентов. Приблизительно то же самое, но несколько большем объёме, реализует ядро Линукса.

Извините, но нет, не хочу ничего смотреть :D Не потому что критически отношусь (хотя есть такое. впрочем я считаю что мое критическое отношение базируется на вполне объективных вещах), а потому что у меня самого FOSS& научные проекты на которые уходит все мое время. Извините еще раз.

Собственно один из «недостатков» ЛОР и уровень дискуссии происходит от того что тут все кто что-то может - очень занятые люди - и у них нет времени вникать в сложные вопросы. Максимум в узкопрофесиональных областях. По этому искать тут команду помошников можно только для школопроектов - у школьников есть свободное время но только школопроекты они и тянут.

И это замечательно, что у конкуренотов не получается.

Ваше высокомерие вас погубит. «Конкуренты» не идиоты. А я говорю не о том что они «не могут» а о вполне системных вещах - цене try-n-error цикла в разработке обвеса к микроядрам. Она объективно на порядок выше чем для обычного программирования

Что может быть приятнее, чем фейл конкурентов. Если бы Hurd/L4 меня не разочаровал, то мы бы сейчас обсуждали что-нибудь другое, например очередной оконный менеджер.

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

Собственно главный вопрос - что вы видите в этом проекта для себя, чего хотите достичь?

Одно направление (N1) - это заниматься на базе этой идеей наукой, в виде DIY науки и дальнешем выходе на «официальную» науку. На публикации в серьезных журналах. И основной профит получать в виде самореализации вас лично и людей с вами. Могу расписать подробней, если что.

Второе направление (N2) - пилить стартап. Тут деньги и экономические процессы главный фактор.

Одно напрямую не исключает другого - но очень сильно влияет друг на друга. И на этом этапе подход N2 выглядит денис-поповщиной и научным фричеством. «Здравствуйте я написал свою ОС !111».

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

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

Когда вы потестите ваши идеи с научной точки зрения наступит следущая фаза - актуализирутся часть N2. Небольшая группа из этого коммунити ответвится и начнет на полукоммерческих основаниях пилить стартап. Как реализацию исследованных идей. Репутация и наработанные «лампочки» не дадут этому уйти во фричество, репутация опять же позволит вам разговаривать с инвесторами и грантодателями на разумном языке - на много порядков увеличивая ваши шансы на успех. Ну то есть вам дадут денег.

То что L4 удалось снизить до приемлемых латентность приема/отправки сообщений путем помещения микроядра в кеш (которое стало вследствие этого наноядром) это очевидно.

Я не могу согласиться с Вами в этом вопросе. Вот что я вкладываю в понятие L4:

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

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

Не могу сказать, сколько килоевро «попипила» L4Ka Team из университета Karslruhe, но Pistachio вполне юзабельное как минимум на архитектуре IA32. И есть вполне коммерчески успешная версия L4X2 для архитектуры ARM от http://www.ok-labs.com/

Это вот ваше высокомерие вас погубит.

Это просто способ обратить на себя внимаение, не более того. Если я Вас случайно оскорбил - примите мои искринние извинения. Высокомерие не со зла, а чтобы обратить на себя внимание.

«Конкуренты» не идиоты. А я говорю не о том что они «не могут» а о вполне системных вещах - цене try-n-error цикла в разработке обвеса к микроядрам. Она объективно на порядок выше чем для обычного программирования

Я приведу Вам конкретный пример - драйвер накопителя на гибуом магнитном диске (контроллера флоппи диска), который был позаимствован из FreeDOS. При переносе его в Хамелеон, он стал значительон проще - ушли сложная обработка прерываний, таймеры и блокировки. При переносе я выкинул напрочь весь системозависимый код, оставив только код работы с регистрами контроллера. А выкинутый код заменил одним «суперциклом» с единой точкой входа от прерываний и запросов файловой системы. Таймер для останова привода не понадобился - его заменила команда ожидания сообщения, которая умеет ожидать сообщение в течение заданного интервала. В результате код значительно уменьшился в размере и стал проще. Хочу лишь заметить, что это единственный драйвер, позаимствованный из Linux. И уж чтобы быть на 100% откровенным, уже лет семь в этом драйвере присутствует ошибка, до исправления которой руки не доходят - при останове мотора floppy привода и при последующем его старте я не жду раскрутки мотора, посему на реальном железе драйвер будет глючить. Тем не менее, даже после исправления этой логической ошибки, драйвер останется проще, чем он был в оригинале.

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

Для науки я уже староват - меньше недели осталось до 40 лет.

Собственно главный вопрос - что вы видите в этом проекта для себя, чего хотите достичь?

Хочу построить стабильную долгоживующую компанию, управление которой перейдёт к моим детям.

На публикации в серьезных журналах. И основной профит получать в виде самореализации вас лично и людей с вами. Могу расписать подробней, если что.

В любом случае это интересно. С удвольствием послушаю.

Я пытался подготовить статьи для журнала «Открытые системы» и даже подписался на него, но после подписки мне показалось, что формат не подходит - облачные вычисления и перепечатки c IEEE Spectrum, который предпочитаю читать в оригинале - imho, не самое лучшее место для статей о микроядрах.

Одно напрямую не исключает другого - но очень сильно влияет друг на друга. И на этом этапе подход N2 выглядит денис-поповщиной и научным фричеством. «Здравствуйте я написал свою ОС !111».

Таки написал, и уже довольно давно. И разными намёками привлекаю внимание специалистов, чтобы школьники пропустили «мимо ушей». Если не ошибаюсь, до Дениса Попова был ещё кто-то очень на него похожий.

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

Спасибо за подсказки. Честно говоря, я не определился с дальнейшей судьбой проекта и возможно Ваши слова подскажут правильное и оптимальное решение.

Не могу сказать, сколько килоевро «попипила» L4Ka Team из университета Karslruhe, но Pistachio вполне юзабельное как минимум на архитектуре IA32. И есть вполне коммерчески успешная версия L4X2 для архитектуры ARM от http://www.ok-labs.com/

Попил и освоение - это две большие разницы. Освоение это вроде эльбруса - когда после >20 лет работ есть процессор с отставанием от конкурентов минимум на 10 лет и «не имеющий аналогов». А раз нет аналогов - сравнивать некорректно. И все. Претензий нет, только ох****е. И ведь реально никто конкретно не виноват кроме всей системы организации работы. Попил же это просто разновидность воровства, совсем другое дело. Они часто сочетаются - но это разные явления.

С другой стороны, опять же, если вы реалистично оцениваете перспективы такой разработки (а судя по всему так и есть), то есть речь не идет об мировом господстве - то можно заниматься и вменяемыми освоениями в хайтех области. И даже на некую рентабельную коммерцию выйти, имхо. Но по моему с рентабельной коммерцией будет сложно. Насколько ok-labs именно коммерчески успешен, а не просто убыточная фирма-инкубатор технологий, на самом деле - загадка.

Я собственно об этом говорю потому что с одной стороны надо четко понимать что вы делаете, а с другой стороны если вокруг проекта не будет экономики (в том числе монетизированной), то есть удовлетворения потребностей, то проект помрет.

Это просто способ обратить на себя внимаение, не более того.

Я исключительно про то что неадекватная оценка соотношения сил, как ваших личных, так и в мировом масштабе - тут неуместна. Обычно это свидетельствует о том что высокомерный товарищ - фрик. Я рад что это не так (точнее надеюсь что это не так. :D ваш спор с тейлганнером про то что секурити увеличивается через использование ioctl, это вам в минус.)

Я приведу Вам .... Тем не менее, даже после исправления этой логической ошибки, драйвер останется проще, чем он был в оригинале.

С драйверами на уровне описанном вами все понятно. Во первых драйвер ложится в придуманную вами архитектуру демонов обвязки вокруг L4, и так далее. Проблемы же возникают когда вам приходится *менять* архитектуру обвязки.Грубо говоря вот ваша система получает распространение, идет в реальный мир. И упирается в невидимые *до этого* архитектурные ограничения.

Обычно на этом этапе происходит эволюция, и происходит она понятным методом - пишутся несколько архитектурных решений в областях возникших проблем, сравнивается, выбирается лучшее. И вот в этом месте цикла try-n-error микроядерные системы впираются в то что нужно править и связующий процессы протокольный клей, и так далее. При чем чаще всего если мы говорим о популярности и упрощении - то вокруг сообщений вешается автогенерируемый маршальный код. Это же вы пишете на низком уровне - а более массовый проект в этой области въедет в нехватку специалистов. Но это палка о двух концах - генераторы маршаллига придется переписывать и в общем опа. То на чем в том числе помер Хурд.
Системы же вроде линукса позволяют набросать тестируемый вариант архитектур «на коленке», при чем как и студентами в том числе.

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

Для науки я уже староват - меньше недели осталось до 40 лет.

«…И такие работы, как изучение заводских процессов в машиностроении, предпринятое Тейлором, развитое Фордом и приведшее к созданию новой системы организации производства и техническому перевороту в автомобилестроении и других отраслях, нужно рассматривать как научную работу. Если Форда не принято называть ученым, то только потому, что все свои изыскания он вел замкнуто, для себя, руководствуясь своими узкими капиталистическими интересами и имея в виду только успехи своего предприятия». С. Л. Капица (который отец)

Вы на самом деле занимались наукой полжизни, просто как то это не осмысливали. Вот пришел момент осмыслить :D В данном случае ваш возраст в гораздо большей степени +1 к тому что получится.

На публикации в серьезных журналах. И основной профит получать в виде самореализации вас лично и людей с вами. Могу расписать подробней, если что.

Я пытался подготовить статьи для журнала «Открытые системы» и даже подписался на него, но после подписки мне показалось, что формат не подходит - облачные вычисления и перепечатки c IEEE Spectrum, который предпочитаю читать в оригинале - imho, не самое лучшее место для статей о микроядрах.

Я к сожалению микроядерными ОС занимался скорее для себя, по этому лучше журналов посоветовать не могу.
С другой стороны вам же нужны не открытые системы а научные журналы. Если хотите публиковать чтото на русском языке - то есть список принимамый ВАК, чтото мне подсказывает что там точно что-то есть. Открытые системы это скорее чтото вроде рекламы вашего дела.

И разными намёками привлекаю внимание специалистов, чтобы школьники пропустили «мимо ушей».

Понимаете в чем дело - «неинтересная»/«грязная» часть науки делается студентами и аспирантами под руководством профессуры. Школьники в понимании ЛОР конечно не нужны, но вот со «специалистами» в науке глухо.

Происходит это потому что в науке во многом работают «за интерес»(деньги прилагаются но интерес идет впереди). Проблема в том что у специалиста этих интересов - дофига своих собственных а не чьих-то. На то он и самостоятельный инженер-ученый.

Так что это системная проблема науки - отсутствие специалистов в понимании бизнеса. Есть либо профессура - это мегаспецы но они не наймиты, с ними не бизнес и даже не стартапные отношения. Кто-то вроде вас, за интерес но и жить хорошо хотят. И есть студенты-школьники.

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

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

Хочу построить стабильную долгоживующую компанию, управление которой перейдёт к моим детям.
Спасибо за подсказки. Честно говоря, я не определился с дальнейшей судьбой проекта и возможно Ваши слова подскажут

правильное и оптимальное решение.
Я надеюсь что мои соображения будут вам полезны.

В любом случае это интересно. С удвольствием послушаю.

Я попробую ответить вам в несколько постов.

Результат очаровал и хотелось бы получить максимум профита и минимум головняка.

Если тебе алгоритм запатентовать, то они в России, по счастию, не патентуются.

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

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

А если у тебя просто некая идея без конкретной реализации, то такое не защищается ничем и никем.

Как-то так.

программа экспериментов

Продолжу. Если говорить о программе экспериментов то (это мое имхо)

* сделать на основе ваших расширений системы эмулятор на основе bochs. Сделать l4 использующее ваши расширения, сравнительно потестить, научно обосновать что ваше решение лучше и тп.

* HDL (верилог) модель + bochs, все то же самое. На чем гонять верилог надо спрашивать специалистов. Собственно тут, подозреваю, возникнет ситуация когда вы увидите что в железе удобнее будет делать вашу систему команд несколько другой.... сильно другой :D. Тут может возникнуть смычка с другими исследователями - например HPC люди заинтересуются задачей постановки ваших опытов на HPC системах (кластерах, гридах и так далее).

* верилог на FPGA матрицу + какой нибудь свободно распространяемый risc. тут будет нужно железо.

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

С матмоделированием плюсы в том что через него можно выйти на ученых в РФ занимающихся смежными областями и интегрироватся в «большую» науку через науку РФ, найти соратников в НИИ и ВУЗах и так далее.

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

Хотелось бы задать несколько вопросов специалистам по VHDL/Verilog

http://electronix.ru/forum

инфраструктура (1)

Если вы продвинетесь далеко в вашем начинании, вам понадобится экспериментальная база : лаборатория и экспериментальная установка. Будет ли это все «виртуальным», или «реальным» не столь важно. И не важно будут вам софт на хостинги ставить добровольцы или это все за деньги. Важно то что в любом случае это по сути капиталовложения, а «лаборатория» - капиталоемкий объект. Собственно задача(одна из) профессора в науке это снять со студентов оргвопросы. И никто кроме профессора это сделать не может, потому что никто нее знает что именно нужно, студенты этого не знают в первую очередь.

Пример. Пусть в нашем случае вот вы дошли до пункта 2 (2.5) - у вас есть верилог + bochs, или полноценная верилог симуляция на кластере. У вас есть коллектив из профессора/профессоров(то есть вас лично) и кучи «студентов» / «аспирантов». Новые привлекаются - старые отпадают.

Соответственно ваша задача оптимизировать процесс «производства» экспериментального материала. А значит что в идеале «студент» должен куда то логиниться и там сразу опыты ставить. А не разворачивать у себя дома патченный bochs сопряженный с верилог эмулятором и всем фаршем. Дело интересное для будущих админов и прочих софтовых инженеров - но абсолютно *непродуктивное* для вашего проекта. А если у вас есть например уже FPGA - то тем более. «Студент» теоретически конечно может весь комплект разраба купить - но практически это маловероятно.

Ваша цель созданием «лаборатории» во первых минимизировать порог вхождения, во вторых минимизировать порог переключения (Это когда ваш аспирант пришел заняться проектом после работы и ему нужно не обеспечить работу личной «экспериментальной установки» а начать работу. Он же небось опять «гентушечку» переставил и у него все опять не работает)

Если такая система создана, то во первых к ней линкуются попавшие в ваши руки на шару ресурсы - к которым таким образом облегчается доступ. Вот например вы пообщались с тазхейтом, он вам дал мегасервер в своей конторе, вы проводите серию вычислительных экспериментов. И не только вы лично но и ваши студенты, со своими логинами и данными. А потом оп - сервер понадобился в другом месте, у вас 2 часа на то что бы выместись вот :D Представьте что у вас вот два десятка таких «арендованных» хостов...

Что бы это не приводило к фейлу вы должны заранее продумать ИТ инфраструктуру - то есть вот эту самую «лабораторию». Очевидно что это должно быть в духе - надежный сервер( у вас в гараже :D ) - линкуемые ноды.

Отсюда собственно вывод - чем такая штука сложнее, тем вам нужнее админ(ы) которые ее будут с вами пилить, освобождая «ученых»(студентов) от непродуктивной по отношению к проекту нагрузки.

Собственно пример подобного шаринга ресурсов в крупных масштабах, европа:
http://www.planet-lab.eu/ и http://onelab.eu/ (один проект)

Да - отсюда вытекает что cloud is your friend - клаудстартапщики и клаудхоббисты ваши естественные друзья, несмотря на большую разницу в интересах ... :D

Проблемы:

Главная проблема этого пункта - то что россиянские люди^W айтишнеки - асоциальные одиночки. Выглядит это так.
- Парни, давайте сделаем ххх и будем им пользоваться
- Не, ненужен, я дома это на гентушечку накачу.
- А я на LFS!!!!
.... и никто не делает.
При чем если сделать этот ххх, с трудом, но могут начать пользватся. Нет культуры шаринга ресурсов.

PS
Точно упустил что-то важное - по этому тисну дополнение попозже.

инфраструктура (2) : "библиотека"

Библиотека.

Собственно если вы пишете научные статьи, читаете статьи, привлекаете аспирантов и студентов к научной и инженерной работе - у вас скапливается (точнее должно скапливатся) большое количество всякого материала:

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

При этом часть материала вам коллеги присылают емейлом, в том числе статьи которые в открытом доступе не лежат. Но нужны они не только вам, а всей вашей рабочей группе.

Обычно, но не всегда, каждый ученый сам собирает подобную коллекцию. Но часто приходит к коллегам и сливает ее куда то на флешку, добавляя потом к своей.

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

Соответственно в идеале, что бы сразу начать работать, волонтеры должны получать этот шмат информации оптом и с апдейтами.

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

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

Я предлагаю держать такую штуку в DCVS (git, mercurial). git подходит лучше - в нем можно удалять информацию о старых версиях, вроде лучше работает с бинарями. (правда лично использую mercurial, он проще :D)

Собственно понятно(надеюсь) что для описанной мной ситуации это подходит лучше всего - новый участник коллаборации получает краткую текстовую инструкцию «как влится в наш коллектив» с однит из пунктов «git репа тут, сливать так, апдейтать так». И никто не мешает и на сайт это выложить, и кусками выложить, и на дропбоксе держать, ...

В общем поверх этого много что можно прикрутить. Как миниум поиск, настройки которого прямо там и держать. Я так не делал кстати. Я обычно кладу в DCVS сделанную при помощи разных makefile текстовую версию, кеш такой. И по этому кешу уже ищу тупо find'ом.

Писать, кстати, рядовым членам туда не обязательно. Это делает либо «профессор» либо кто то типа «библиотекаря». Собственно его задача - поддерживать данную «кучу» в структурированном виде. Это кстати одна из time consuming задач, если смотреть в сумме на потраченное время - расход ресурса(времени волонтеров и вашего).

Как собирать

Понятно что поиски по интернету в ходе создания обзоров литературы по тематике.

Важный момент - это все должно делаться регулярно.

Опять же важный момент. когда вы наладите контакт с коллегами, в том числе и на ЛОРе - у вас будет доступ «через знакомых» к разным библиотекам научной литературы. Оттуда и будете брать статьи. Полулегально, но чтож поделать.
Важно отметить что ваши волонтеры это делать смогут с трудом - еще один плюс разделения труда и «инфраструктурного» подхода.

Собственно когда вы выйдете на соотвествующий уровень - в вашей группе просто появятся студенты и аспиранты работающие в обычных ВУЗах - а у них будет доступ к необходимой литературе. Такие «добытчики» будут.


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

В общем опять наверное дофига всего забыл.... апдейты будут в оббщем. Ну и спрашивайте, идеи предлагайте :)

Спасибо. Вы дали большую пищу для размышлений. Внимательно прочитал, некоторые моменты несколько раз.

Возникло несколько вопросов.

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

Второй вопрос касательно Bochs - в списке рассылки L4Ka Group название Bochs упоминалось очень часто. Не могли бы Вы пояснить, почему именно Bochs и в чем его преимущество перед обычными эмуляторами типа MS Virtual PC, VMWare и VirtualBox?

Третий вопрос касается программы экспериментов и он немного личный - как Вы видите коммерциализацию исследования? Я не имею в виду именно аппаратный L4, а вообще исследование, проведенное по вышеописанному сценарию.

http://hthreads.csce.uark.edu/wiki/About_Hthreads

Я, наверное, поздно набрёл на эту тему, но всё же. Я довольно поверхностно знаком с L4 и не совсем поверхностно с тем, как работает микропроцессор. Вот с аппаратной точки зрения и возникают вопросы/замечания.

Во-первых, по поводу аппаратного планировщика и «жёстких» регистров TCB. Это реализуется микрокодом и будет заведомо тормознее, чем обычный код для нормальной RISC-машины.

Во-вторых, коммутируемый регистровый файл. Так устроены санки — у них здоровый регистровый файл и скользящее по нему окно для каждого процесса. Причем, окна соседних процессов налезают друг на друга — как раз для передачи сообщений. Это из старенького. Из новенького есть аппаратная многопоточность в свежих мипсах, тоже с коммутацией регистрового файла. Вы не копали в эту сторону?

В-третьих, для чего вам новые инструкции? Чем не устроил старый-добрый syscall?

Со своей стороны, я думаю, что я могу ответить на ваши вопросы по HDL'ям.

Очень рад, что Вы подключились к дискуссии. Спасибо за интерес.

Во-первых, по поводу аппаратного планировщика и «жёстких» регистров TCB. Это реализуется микрокодом и будет заведомо тормознее, чем обычный код для нормальной RISC-машины.

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

Во-вторых, коммутируемый регистровый файл. Так устроены санки — у них здоровый регистровый файл и скользящее по нему окно для каждого процесса. Причем, окна соседних процессов налезают друг на друга — как раз для передачи сообщений. Это из старенького.

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

Из новенького есть аппаратная многопоточность в свежих мипсах, тоже с коммутацией регистрового файла. Вы не копали в эту сторону?

Пока не копал, однако, L4Ka Pistachio поддерживает мипсы. Теоретически, если код Pistachio использует новые возможности мипсов, то в такой связке получается очень мощное решение. Спасибо за наводку, постараюсь глянуть в эту сторону.

Со своей стороны, я думаю, что я могу ответить на ваши вопросы по HDL'ям.

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

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

Потому что для микрокода очень неудобно организовывать конвейер. Если это старая многоцикловая архитектура а-ля VAX-11 — пожалуйста, никаких проблем. Только это будет в 5-10 раз медленнее при прочих равных, чем внятный RISC. Если же в ПЗУ хранить обычные RISC-инструкции, которые прекрасно конвейеризуются, то получается, что ПЗУ не нужно — эти инструкции и из внешней памяти прекрасно исполняются. Собственно говоря, во всех RISC'ах так и сделано. Особенно наглядно — в Альфе. Там у них было понятие PalCode — это область памяти, в которой были реализованы «сложные» инструкции, набранные из обычных RISC-команд. Сложные инструкции из PalCode'a составляли ядро операционной системы. (Кстати, привет, тру-микроядро: OSF/1 же.) Такой явный механизм нужен был для совместимости с VAX-11 прямо из коробки. Вызов шел специнструкцией CallPAL. Но по сути, это сисколл.

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

Ну, на самом деле, остальные риски немногим хуже. В MIPS, Alpha и, вероятно, PowerPC, короткое IPC идёт через регистры, т.е. точно так же не копируется ничего вообще. Насколько я понял, под это выделяются те же 8 регистров, что и в санках, а это 64 байта.

Не могли бы Вы рассказать о принципах работы этого устройства в общем случае?

В общем случае — выполняется преобразование одного адреса в другой по таблице, которая тоже лежит в памяти. Т.е. любое обращение к памяти требует не одного, а двух обращений; плюс проверка флагов (Dirty, Valid, read-enable и пр.). Это очень дорого, поэтому часть вышеупомянутой таблицы кэшируется в процессоре и зовётся TLB. TLB представляет собой полностью ассоциативный кэш, или content-adressable memory, кому как больше нравится. У каждой ячейки такой памяти есть тэг, по которому она и доступна. Ну и вот при обращении, значение одновременно сравнивается со всеми тэгами. Значение из такой памяти выбирается по совпавшему тэгу, если таковой нашёлся. Это, кстати, тоже очень дорого (не только по скорости, но и по площади), поэтому даже на современных процессорах количество ячеек TLB очень редко превышает 64.

Что же до flex-pages, то это более-менее совпадает с аппаратным решением в том же MIPS. Решение заключается в выборе количества бит, которое преобразуется с помощью TLB. Например, для 4кб страницы в 32-битном процессоре младшие 12 бит остаются без преобразования, а старшие 20 идут через TLB. Ну и вот (в узких пределах и грубо говоря) можно выбирать сколько бит идет через TLB, а сколько остаётся как есть. Через это получаются страницы размером в разные степени двойки. Но вообще, это можно и софтверно сделать, кмк.

Ну и да, когда говорят о MMU, обычно подразумевается еще и защита памяти. Это реализуется с помощью исключений в случае некорректного преобразования адреса.

Спасибо за обстоятельный ответ. У меня есть ещё вопросы, но потребуется день или два, чтобы их сформулировать.

Ну и да, когда говорят о MMU, обычно подразумевается еще и защита памяти. Это реализуется с помощью исключений в случае некорректного преобразования адреса.

В L4 - обработчик исключения, это задача, которая принимает сообщения, а информация об исключении приходит в виде стандартного сообщения. Простите, я не знаю по какой ссылке Вы нашли эту тему, не смотрели ли Вы вот этот документ - L4_Hard_20130119?

В L4 - обработчик исключения, это задача, которая принимает сообщения, а
информация об исключении приходит в виде стандартного сообщения.

Ну да, но эти сообщения посылает ядро в ответ на возникновение аппаратного исключения или прерывания. И далеко не всегда, кстати. Во-первых, если идёт простой промах мимо TLB (но при этом существует валидное преобразование в памяти) сообщение никому не отправляется; происходит просто обновление TLB и текущая задача выполняется дальше. Во-вторых, некоторые исключения имеют смысл только для ядра — это всякое печальное, вроде Bus Error, Cache error и TLB Miss'ы в ядре. Ну и в-третьих, там, вроде, есть механизм ассоциации задачи с конкретными исключениями.

Простите, я не знаю по какой ссылке Вы нашли эту тему, не смотрели ли Вы вот
этот документ - L4_Hard_20130119?

Попал по ссылке с хабра. Документ смотрел, да. Подробно, впрочем, не разбирал. Собственно, этот документ как раз и оставил вопросы, вроде «зачем» и «почему».

P.S. Я думаю, что не стоит величать меня на «Вы», еще и с большой буквы. Я вполне молод и достаточно скромен :)

Потому что для микрокода очень неудобно организовывать конвейер. Если это старая многоцикловая архитектура а-ля VAX-11 — пожалуйста, никаких проблем. Только это будет в 5-10 раз медленнее при прочих равных, чем внятный RISC. Если же в ПЗУ хранить обычные RISC-инструкции, которые прекрасно конвейеризуются, то получается, что ПЗУ не нужно — эти инструкции и из внешней памяти прекрасно исполняются.

Это предмет для спора :) Я бы всё же предпочёл область на кремниевой пластине с жёстко прошитой микропрограммой на этапе формирования топологии. Точнее с двумя микропрограммами - планировщиком и корневым менеджером памяти (Sigma0).

Ну, на самом деле, остальные риски немногим хуже. В MIPS, Alpha и, вероятно, PowerPC, короткое IPC идёт через регистры, т.е. точно так же не копируется ничего вообще. Насколько я понял, под это выделяются те же 8 регистров, что и в санках, а это 64 байта.

Маловато для L4. Один регистр используется под описание сообщения, получается что только 7 регистров можно передать в одну сторону за операцию. В принципе, для большинства задач вполне хватит, но если описывать передачу строк и отображение (mapping) страниц, то для каждой из этих операций необходимо по два регистра.Три строки, которые можно передать в восьми регистрах, вполне достаточно для большинства прикладных задач. Проблема в том, что трех составных регистров не хватит, чтобы описать любой регион виртуальной памяти. Потребуется несколько сообщений для описания некоторых регионов. Или придётся принебречь накладнымии расходами и пытаться описать любой регион тремя отображентями.

В общем случае — выполняется преобразование одного адреса в другой по таблице, которая тоже лежит в памяти. Т.е. любое обращение к памяти требует не одного, а двух обращений; плюс проверка флагов (Dirty, Valid, read-enable и пр.).

Так. Кажется родилась идея. Некий эквивалент TLB переходит в блок регистров задачи. Самый простой способ, подразумевающий софтверный MMU. В общем случае описываем операцию отображения двумя словами:

[0] Активная универсальная страница
[1] Физический адрес трансляции

Одновременно:

• проверям, входит ли траслируемый адрес в пространство, описанное активной страницей.
• производим трансляцию адреса в физический адрес

Если адрес находится в пространстве страницы, используем транслированный адрес. Если адрес находится за пределами активной страницы, входим микропрограмму MMU.

Где профит:

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

Для POSIX системы достаточно нескольких пар трансляции:

1. Сегмент кода
2. Сегмент данных
3. Сегмент кучи
4. Сегмент стека

Спасибо за идею, Вы очень помогли!

Предложенный вариант далеко не идеальный, но уже есть от чего оттолкнуться. Процесс, не использующий shared memory, очень просто описывается с помощью 8 слов.

Это предмет для спора :) Я бы всё же предпочёл область на кремниевой пластине
с жёстко прошитой микропрограммой на этапе формирования топологии. Точнее с
двумя микропрограммами - планировщиком и корневым менеджером памяти
(Sigma0).

Это не предмет для спора. На истину в последней инстанции не претендую, вместо этого, рекомендую прочесть книгу «Digital Design And Computer Architecture», by Harris & Harris. Она короткая, при этом очень информативная и понятная. Еще есть пара книг по Computer Architecture by Patterson & Hennessy — тоже очень хорошие. Там понятно написано о том, зачем нужен микрокод и чем микрокодовая реализация хуже конвейерной. Это, кстати, очень интересное место, потому что у microcoded реализации запросто может быть более высокая тактовая частота, но работать она при этом всё равно будет медленнее. В общем, крайне рекомендую.

Так. Кажется родилась идея. Некий эквивалент TLB переходит в блок регистров
задачи. Самый простой способ, подразумевающий софтверный MMU.

Если у вас чистый микрокод, который абсолютно никуда не спешит — пожалуйста. Но такая реализация может оказаться даже медленнее софтверной. При переключении задач TLB не сбрасывается, при этом он имеет существенно больше записей, чем одна.

Для POSIX системы достаточно нескольких пар трансляции:

Тоже не совсем верно. Чисто сегментная организация виртуальной памяти, в принципе, возможна, но крайне неудобна IRL. (Мемори менеджер офигеет эти сегменты в памяти располагать, офигеет их сливать на диск, а потом офигеет их загружать). По этому поводу кое-что есть в книге «See MIPS Run Linux» — тоже очень рекомендую к прочтению, даром, что не про L4.

«Digital Design And Computer Architecture», by Harris & Harris.

Занимательная книга. Пока осилил только 257 страниц из ~550. Очень интересно и познавательно.

При переключении задач TLB не сбрасывается, при этом он имеет существенно больше записей, чем одна.

Откуда-то с linux.org.ru пошёл слух, что при переключении задач TLB сбрасывается. Но спорить на эту тему не буду, потому что не знаю.

Что касается количества записей в TLB, то тут преимущество не очевидно: что лучше - одна-две-три больших виртуальных страницы, покрывающих регион, или много много мелких, которые все не поместятся в TLB?

Чисто сегментная организация виртуальной памяти, в принципе, возможна, но крайне неудобна IRL. (Мемори менеджер офигеет эти сегменты в памяти располагать, офигеет их сливать на диск, а потом офигеет их загружать). По этому поводу кое-что есть в книге «See MIPS Run Linux» — тоже очень рекомендую к прочтению, даром, что не про L4.

Обязательно прочитаю после «Digital Design And Computer Architecture». Но здесь «выползло» некоторое наслоение терминов. Возьмём, например, секцию .text исполняемого файла. Допустим, в ней размещёны инструкции процессора и константы. Для простоты не будем различать права доступа на исполнение и чтение - если разрешено исполнять, значит можно и читать. Допустим, секция .text занимает 157 килобайт. Разбиваем её на универсальные страницы - 128К + 32К. Если взять за основу вариант из предыдущего поста, то пока счётчик команд не выходит за границы текущей страницы (которая может быть 128 или 32 килобайта), обращений к MMU не происходит. Здесь экономия очевидна. Со стеком, кучей и .data выигрыш не очевиден. Точнее, его может и не быть.

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

Что касается количества записей в TLB, то тут преимущество не очевидно: что
лучше - одна-две-три больших виртуальных страницы, покрывающих регион, или
много много мелких, которые все не поместятся в TLB?

С точки зрения попадания по TLB, большие страницы или сегменты безусловно лучше. (Под сегментом понимается страница, у которой указана длина). Но это налагает ограничение на расположение данных в физической памяти — данные должны лежать в ней непрерывно. И так — для всех программ. Физическая память в таком случае очень быстро закончится, так как «пасьянс» не сойдётся.

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

Я думаю, на этот вопрос стоит взглянуть с другой стороны. Вот, например, есть у вас демон, который просыпается раз в день. ОС может работать с ним как с полноценной задачей: она будет запущена и будет ждать своего сообщения «Пуск». При этом, если не запрещать выгрузку кода из памяти, такая задача практически не будет использовать ресурсы машины. Сам код при этом может лежать на диске, в исполняемом файле — никакой своп не нужен.

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