Без планировщика рухнет вся идея передачи сообщений. Увы, выкинуть его не получится. Подразумевается древовидная структура приоритетов планирования. В корне дерева сам планировщик, который распределяет время между узлами, исходящими из корня. Если задача в узле блокирована, то её время отдаётся подзадачам. Т.е. задачи, находящиеся в подветвях получают управление только в том случае, если их узловая задача блокирована. Чем дальше задача от корня дерева, тем ниже её приоритет.
Что касается архитектуры Sparc, то, похоже, она гораздо привлекательнее для реализации микроядра L4, чем архитектура x86. Проблема в том, что сейчас архитектура Sparc превратилась в экзотическую и вести разработку под неё не имеет смысла.
Вы очень точно описали проблему блокировок при использовании синхронных сообщений. Но в этой слабости и сила решения. Если обработчику сообщения понадобится полчаса на то, чтобы дойти до инструкции ожидания сообщения, то этот обработчик неправильно спроектирован. Любой обработчик обязан максимально быстро обработать входящее сообщение и снова войти в состояние ожидания. Нормальное состояние системы когда все обработчики забокированы в ожидании входящих сообщений. Любое входящее сообщение провоцирует «цепную реакцию» обмена сообщениями, которая в конечном счёте приводит к последующей блокировке в ожидании следующего события. Во время ожидания процессор находится в режиме низкого энергопотребеления. А чтобы прогаммистам не было грустно и тоскливо пользоваться этим, то им будет предложено API, решающее проблемы блокировок.
Обмен данными произвольного размера это важная часть спецификации L4, которое предлагает две вещи — «строки» (блоки памяти) и операции маппинга. В случае «строк» происходит их физическое копирование между задачами и их оптимально использовать для передачи небольших порций данных между адресными пространствами. Для передачи больших объемов памяти спецификация предлагает мапинг универсальных страниц виртуальной памяти — регион памяти, который описывается с помощью нескольких универсальных виртуальных страниц, можно передать в сообщении с помощью операции «маппинга» или «гранта» (прошу прощения за транслитерацию — пока не могу подобрать эквивалентных русскоязычных терминов) в обеих случаяъ область памяти, описываемая универсальными страницами виртуальной памяти, отображается в адресное пространство процесса получателя сообщения, но в случае гранта эти страницы убираются из адресного пространства источника сообщения. Это интересная возможность, но её удастся реализовать не раньше чем заработает передача «простых» сообщений. В нынешнем виде устройство не оперирует понятием адресных пространств и не имеет вирутальной памяти.
Инструкция idle действительно не очень нужна. Сейчас она используется для отладки устройства.
Сейчас нельзя. В текущей версии ограничение на 31 задачу. Для микроконтроллера вполне достаточно. В будущем, если ничего не помешает, то будет реализована выгрузка задач в ОЗУ.
Уже два раза представлял проект перед инвесторами на выездных сессиях «Сколково» и оба раза получил отказ. Но не думаю что это плохо — кроме инвесторов на презентации присутствовали и технические специалисты, они подходили после презентации и интересовались проектом.
Монетизация по типу fabless компаний — продажа IP блоков и, возможно, лицензий. А вот как прийти к монетизации это сложный вопрос. Доработка и развитие устройства, убеждение разработчиков в преимуществах архитектуры, формирование сильной команды и формиравние комьюнити — вот это всё, помноженное на время, и есть путь к монетизации. Кстати, сейчас хороший момент для публикации в прессе — многие издания готовы опубликовать технические материалы — хороший вариант убеждения разработчиков.
Наконец, есть резервный вариант — перевести все материалы на английский язык и продвигать архитектуру за рубежом.
Кстати, с интересом наблюдаю за Вашими проектами — Марсоход2 удивительное устройство, о котором раньше можно было только мечтать.
1. Пример не показывает с кем ведётся обмен сообщениями. В регистре R0 идентификатор процесса получателя сообщения, в регистре R1 таймаут. Может так получиться, что помимо задачи, которая реализует функцию puts, сущесттвует задача с более высоким приоритетом, которая бы запустилась по истечении кванта времени текущей задачи. В этом случае обмен сообщенем задержится пока более приоритетная задача не заблокируется или не выработает свой квант времени. Другой случай — приёмник сообщения чем-то занят и не готов принять сообщение. Как результат, время простоя будет отдано планировщиком другим задачам. Т.е. с помощью инструкций SEND и RECV вводится точка переключения контекста. У меня как раз возник спор по этому поводу на одном из форумов — предполагается что переключение контекста по таймеру, когда задача исчерпала свой квант времени, это более редкая операция чем переключение контекста в момент обмена сообщениями. Иными словами — большую часть времени все задачи будут блокированы при исполнении инструкции RECV, ожидая внешних событий. Это нормальное состояние устройства. Напротив, блокирование задачи при исполнении инструкции SEND говорит о том, что приёмник в данный момент времени чем-то занят и не готов принять новое сообщение. Таких блокировок надо по возможности избегать и минимизировать их возникновение.
Иначе говоря, любая система строится как множество взаимодействующих субъектов (задач, слушающих сообщения, обрабатывающих сообщения каким-то образом и затем отвечающих на эти сообщения).
2. Буфер не один, иначе он полностью теряет смысл. В идеальном случае количество буферов равно количеству задач. Но для большинства применений оптимальное количество буферов может быть половиной от количества задач. Почему была выбрана именно такая схема работы с буфером сообщений? Дело в том, что при таком подходе можно спрятать от программиста детали аппаратной реализации. С помощью буфера сообщений можно передавать данные между задачами, исполняющимися на одном ядре, можно передавать сообщения между разными процессорными ядрами в одном корпусе. Если постараться, то можно реализовать нечто вроде DMA, передавая содержимое буфера между процессорами на общей шине. В общем случае программист может даже не знать где находится адресат сообщения — соседняя thread на этом же ядре, другое вычислительное ядро (core), соседний процессор на многопроцессорной плате или удалённый узел кластера, общающийся с задачей через proxy-функцию. Т.е. вот такой интерфейс, а детали его реализации скрыты.
Отличия между системными и прикладными задачами на уровне железа не вводятся.
Cообщениями могут обмениваться только разные задачи. В пределах задачи используются подрограммы, как в традиционных процессорах.
3. Наверное мне неоюходимо исправить статью, чтобы исключить эту двойственность толкования — абсолютные адреса не используются в командах условных и безусловных переходов и вызовах функций. Обращение к памяти по абсолютному адресу, разумеется, необходимо и оно осуществляется с помиощью регистров общего назначения (значение регистра это абсолютный адрес).
Самый большой антагонизм, который встретился при работе с ПЛИС, возник при попытке поместить всю работу в один такт. Вначале (от незнания и отстутствия опыта) это даже как-то удалось, но в результате работало очень нестабильно. Т.е. была попытка после выборки команды сразу произвести её разбор, выбрать аргументы из регистрового файла, выполнить инструкцию и поместить результат назад. Вопреки всему такой подход даже как-то работал, но при любом чихе всё рассыпалось. Даже понижение тактовой частоты не очень помогало. Прилось на время отказаться от одного такта и разложить операции на более простые. Как результат — теперь непонятно от чего разработчики конкурирующих устройств снижают тактовую частоту — если разложить на стадии, то можно не задумываться о переходных процессах и работать на максимальной частоте, заявленной производителем ПЛИС.
Т.е. проект в текущем его состоянии весьма прост. А помещвть всё в один такт придётся с помощью конвейера, которого сейчас нет в устройстве. Конвейер не поддерживается не только из за сложности или лени, а потому что ограниченный объем логических элементов хочется использовать для других целей. Но со временем, если архитектура заинтересует разработчиков, можно будет подумать и о конвейере.
ПЛИС, в которую можно зашить нормальный микроконтроллер(зачем, кстати) обойдётся слишком дорого для хобби
Т.е. чтобы разработчик решил использовать что-то нетрадиционное, для этого нужны очень веские причины. Собственно я и хотел узнать эти причины. На вопрос «зачем» ответить не готов, наоборот — мне было бы интересно какие преимущества могли бы повлиять на решение выбора микроконтроллера. Или хотя бы узнать с какими проблемами Вы столкнулись при использовании STM32.
В «стандартном» G-code реагировать на события нельзя, реакцию должен обрабатывать софт, который выполняет G-code.
Опасаюсь показаться назойливым, а нет ли другого аналогичного протокола, который реализует поддержку внешних событий? Т.е для станка обратная связь не обязательна, а вот для манипулятора, который мог бы поместить болванку в станок и извлечь готовую деталь, обратная связь необходима.
Бывает так, что хобби перерастает в успешную компанию. Скорее наоборот — если в истории компании не замешано хобби, то шансов на успех комании очень мало.
И всё же меня больше всего волнует вопрос — насколько сильно Вы привзяаны к STM32? Что могло бы Вас заставить использовать MIPS-совместимый контроллер или какой-либо экзотический, но со сравнивыми возможностями. Поясню свой интерес — как раз для таких (и более сложных решений) планирую предложить ни с чем несовместимый микроконтроллер в ПЛИС. Поэтому Ваше мнение очень важно чтобы хотя бы оценить шансы своего проекта.
И попутный вопрос — а как быть с обратной связью? Поддерживает ли синтаксис G-code реагирование на сигналы с датчиков?
Разрешите полюбопытствовать, какие бывают требования к скорости контроллера? Чем руководствуются создатели таких станков при выборе микроконтроллера и софта на него? Большая ли конкуренция? Есть ли какие-то САПР и библиотеки для микроконтроллеров? Остались ли ещё где-то рабочие станки с ЧПУ на перфоленте и нет ли спроса на замену управляющего оборудования для таких станков.
Интересный проект. Спасибо. Сам хотел сделать нечто подобное, но не на видеовыход, а в ANSI-терминал. Проблема проявилась в отсутствии компилятора. То есть на ПЛИС я реализовал оригинальный процессор, а компилятора к нему нет. Можно было бы переписать Си код на ассемблере, но есть дела и поважнее.
Собственно, мой комментарий не для того чтобы похвастаться или похвалить автора, а в надежде узнать название двух самых популярных в мире плат с FPGA — самую популярную с Altera на борту и самую популярную с Xilinx.
Требования к устройству:
не менее 10000 Altera LE
не менее 400 Кбит внутренней памяти (встроенная в ПЛИС)
желательно от 4 мбайт SDRAM на борту платы
частота не менее 100 Мгц
бюджет от $100 до $150
Чем популярнее плата у разработчиков, тем лучше. Кажется, что название Terasic DE1 слышал уже неоднократно. Возможно одна из самых популярных? Но $250 уже нормальные деньги, которые вот так просто из семейного бюджета не вытащишь.
Ведь, наверняка, были более ранние цивилизации, которые сумели бы до нас долететь, выражаясь примитивным языком.
А почему именно к нам? Может быть они пока друг к другу в гости летают.
Кстати, возник такой вопрос. Допустим, земляне отправили корабль к другой звезде, где ожидали встретить планету земного типа. Допустим, такая планета нашлась. Что бы было более предпочтительнее — чтобы на этой планете была рузмная жизнь или нет? Иными словами, что важнее для человечества — найти братьев по разуму или место для колонизации? Для простоты ответа и по морально-этическим соображениям исключим возможность колонизации планеты с разумной жизнью.
Иероглифы у китайцев и японцев, а у корейцев Хангыль. При некоторой тренировке вполне можно научиться читать. Жаль, такое чтение никак не приблизит к пониманию написанного. Хотя, некоторые слова, особенно в компьютерной тематике, напрямую завимствованы из иностранных языков — если знаешь корейский алфавит, то в некоторых случаях можно догадаться что написано. Например, 기계 코드 Гугл переводит как «Machine Code». Судя по всему слово «Код» заимствовано, потому что звучит похоже.
Идея заключается в том, что программе в общем случае не нужно знать адрес библиотеки для передачи ей управления. Программа обменивается сообщениями, при этом не происходит явной передачи управления. Соответственно, вместо адреса точки входа в библиотечную функцию, вызвающей программе необходимо знать ID задачи и ID запроса. При этом нет разницы, где расположена библиотечная функция — в соседнем потоке, на другом ядре или вообще, реализована аппаратно.
Системные сервисы / пользовательские процессы будут выполняться на нём же. Малое количество ОЗУ в этой прошивке объясняется тем, что используется только внутренняя память ПЛИС, а внешнее ОЗУ ещё не задействовано.
Прежде всего аппаратный планировщик и средства для переключения контекста. Для начала в едином адресном пространстве, без виртуальной памяти.
Добавятся инструкции захвата и освобождения буфера сообщений. Добавится самая главная инструкция, ради которой всё это затвевлось — «Inter Process Communication». Пока что есть мысли реализовать эту инструкцию через микрокод. Видите, даже мненмонику ей ещё не придумали — аббревиатура IPC будет не очень удачной, поскольку среди электроников аббревиатура IPC имеет устоявшееся значеие «Instructions Per Cycle».
Есть идея спрятать «удалённую сторону» за инструкцией обмена сообщениями — в общем случае задача, выполняющая обмен сообщениями, не должна знать и видеть разницу с кем она обменивается сообщениями — с другой задачей или с устройством. Если удастся реализовать такую прозрачность, то дальнейшее будущее проекта видится в радужном свете.
Наконец, управление задачами и адресными пространствами планируется реализовать с помощью сообщений планировщику.
Коневейер пока не использовали. Есть некоторые идеи относительно конвейера, есть даже мысли об одновременном исполнении нескольких инструкций, поместившихся на 40-битную шину, но сейчас нам более интересно движение в сторону микроядра — довольно новая область, которой пока никто серьёзно не занимался.
О преимуществах системы команд не готов спорить — в настоящий момент реализовано минимальное подмножество, достаточное для практического применения. Но в силу минимализма она проиграет по эффективности другим системам команд. Однако, система команд спроективроана так, что может быть безболезненно расширена. В принципе, система команд проектировалась с учётом двух требований — простота разбора и расширяемость.
Наконец, что касается компилятора, то тут всё сложно — его научили лексическому и синтаксическому разбору, но до генерации кода руки не дошли. В общем, о компиляторе я пока не готов говорить — это половина компилятора. С другой стороны — есть несколько сторонних разработчиков, котрые пишут компиляторы. У нас есть взаимный интерес и при удачных обстоятельствах эти разрааботчики могли бы добавить поддержку нашего процессора в свои продукты.
Что касается архитектуры Sparc, то, похоже, она гораздо привлекательнее для реализации микроядра L4, чем архитектура x86. Проблема в том, что сейчас архитектура Sparc превратилась в экзотическую и вести разработку под неё не имеет смысла.
Вы очень точно описали проблему блокировок при использовании синхронных сообщений. Но в этой слабости и сила решения. Если обработчику сообщения понадобится полчаса на то, чтобы дойти до инструкции ожидания сообщения, то этот обработчик неправильно спроектирован. Любой обработчик обязан максимально быстро обработать входящее сообщение и снова войти в состояние ожидания. Нормальное состояние системы когда все обработчики забокированы в ожидании входящих сообщений. Любое входящее сообщение провоцирует «цепную реакцию» обмена сообщениями, которая в конечном счёте приводит к последующей блокировке в ожидании следующего события. Во время ожидания процессор находится в режиме низкого энергопотребеления. А чтобы прогаммистам не было грустно и тоскливо пользоваться этим, то им будет предложено API, решающее проблемы блокировок.
Обмен данными произвольного размера это важная часть спецификации L4, которое предлагает две вещи — «строки» (блоки памяти) и операции маппинга. В случае «строк» происходит их физическое копирование между задачами и их оптимально использовать для передачи небольших порций данных между адресными пространствами. Для передачи больших объемов памяти спецификация предлагает мапинг универсальных страниц виртуальной памяти — регион памяти, который описывается с помощью нескольких универсальных виртуальных страниц, можно передать в сообщении с помощью операции «маппинга» или «гранта» (прошу прощения за транслитерацию — пока не могу подобрать эквивалентных русскоязычных терминов) в обеих случаяъ область памяти, описываемая универсальными страницами виртуальной памяти, отображается в адресное пространство процесса получателя сообщения, но в случае гранта эти страницы убираются из адресного пространства источника сообщения. Это интересная возможность, но её удастся реализовать не раньше чем заработает передача «простых» сообщений. В нынешнем виде устройство не оперирует понятием адресных пространств и не имеет вирутальной памяти.
Инструкция idle действительно не очень нужна. Сейчас она используется для отладки устройства.
Монетизация по типу fabless компаний — продажа IP блоков и, возможно, лицензий. А вот как прийти к монетизации это сложный вопрос. Доработка и развитие устройства, убеждение разработчиков в преимуществах архитектуры, формирование сильной команды и формиравние комьюнити — вот это всё, помноженное на время, и есть путь к монетизации. Кстати, сейчас хороший момент для публикации в прессе — многие издания готовы опубликовать технические материалы — хороший вариант убеждения разработчиков.
Наконец, есть резервный вариант — перевести все материалы на английский язык и продвигать архитектуру за рубежом.
Кстати, с интересом наблюдаю за Вашими проектами — Марсоход2 удивительное устройство, о котором раньше можно было только мечтать.
Иначе говоря, любая система строится как множество взаимодействующих субъектов (задач, слушающих сообщения, обрабатывающих сообщения каким-то образом и затем отвечающих на эти сообщения).
2. Буфер не один, иначе он полностью теряет смысл. В идеальном случае количество буферов равно количеству задач. Но для большинства применений оптимальное количество буферов может быть половиной от количества задач. Почему была выбрана именно такая схема работы с буфером сообщений? Дело в том, что при таком подходе можно спрятать от программиста детали аппаратной реализации. С помощью буфера сообщений можно передавать данные между задачами, исполняющимися на одном ядре, можно передавать сообщения между разными процессорными ядрами в одном корпусе. Если постараться, то можно реализовать нечто вроде DMA, передавая содержимое буфера между процессорами на общей шине. В общем случае программист может даже не знать где находится адресат сообщения — соседняя thread на этом же ядре, другое вычислительное ядро (core), соседний процессор на многопроцессорной плате или удалённый узел кластера, общающийся с задачей через proxy-функцию. Т.е. вот такой интерфейс, а детали его реализации скрыты.
Отличия между системными и прикладными задачами на уровне железа не вводятся.
Cообщениями могут обмениваться только разные задачи. В пределах задачи используются подрограммы, как в традиционных процессорах.
3. Наверное мне неоюходимо исправить статью, чтобы исключить эту двойственность толкования — абсолютные адреса не используются в командах условных и безусловных переходов и вызовах функций. Обращение к памяти по абсолютному адресу, разумеется, необходимо и оно осуществляется с помиощью регистров общего назначения (значение регистра это абсолютный адрес).
Т.е. проект в текущем его состоянии весьма прост. А помещвть всё в один такт придётся с помощью конвейера, которого сейчас нет в устройстве. Конвейер не поддерживается не только из за сложности или лени, а потому что ограниченный объем логических элементов хочется использовать для других целей. Но со временем, если архитектура заинтересует разработчиков, можно будет подумать и о конвейере.
Т.е. чтобы разработчик решил использовать что-то нетрадиционное, для этого нужны очень веские причины. Собственно я и хотел узнать эти причины. На вопрос «зачем» ответить не готов, наоборот — мне было бы интересно какие преимущества могли бы повлиять на решение выбора микроконтроллера. Или хотя бы узнать с какими проблемами Вы столкнулись при использовании STM32.
Опасаюсь показаться назойливым, а нет ли другого аналогичного протокола, который реализует поддержку внешних событий? Т.е для станка обратная связь не обязательна, а вот для манипулятора, который мог бы поместить болванку в станок и извлечь готовую деталь, обратная связь необходима.
И всё же меня больше всего волнует вопрос — насколько сильно Вы привзяаны к STM32? Что могло бы Вас заставить использовать MIPS-совместимый контроллер или какой-либо экзотический, но со сравнивыми возможностями. Поясню свой интерес — как раз для таких (и более сложных решений) планирую предложить ни с чем несовместимый микроконтроллер в ПЛИС. Поэтому Ваше мнение очень важно чтобы хотя бы оценить шансы своего проекта.
И попутный вопрос — а как быть с обратной связью? Поддерживает ли синтаксис G-code реагирование на сигналы с датчиков?
Разрешите полюбопытствовать, какие бывают требования к скорости контроллера? Чем руководствуются создатели таких станков при выборе микроконтроллера и софта на него? Большая ли конкуренция? Есть ли какие-то САПР и библиотеки для микроконтроллеров? Остались ли ещё где-то рабочие станки с ЧПУ на перфоленте и нет ли спроса на замену управляющего оборудования для таких станков.
Собственно, мой комментарий не для того чтобы похвастаться или похвалить автора, а в надежде узнать название двух самых популярных в мире плат с FPGA — самую популярную с Altera на борту и самую популярную с Xilinx.
Требования к устройству:
Чем популярнее плата у разработчиков, тем лучше. Кажется, что название Terasic DE1 слышал уже неоднократно. Возможно одна из самых популярных? Но $250 уже нормальные деньги, которые вот так просто из семейного бюджета не вытащишь.
Имхо, это ключевая особенность для понимания архитектуры.
А почему именно к нам? Может быть они пока друг к другу в гости летают.
Кстати, возник такой вопрос. Допустим, земляне отправили корабль к другой звезде, где ожидали встретить планету земного типа. Допустим, такая планета нашлась. Что бы было более предпочтительнее — чтобы на этой планете была рузмная жизнь или нет? Иными словами, что важнее для человечества — найти братьев по разуму или место для колонизации? Для простоты ответа и по морально-этическим соображениям исключим возможность колонизации планеты с разумной жизнью.
Тот, кто в своё время активно пользовался UUCP протоколом, смотрит на такие адреса с бооольшим недоверием.
Идея заключается в том, что программе в общем случае не нужно знать адрес библиотеки для передачи ей управления. Программа обменивается сообщениями, при этом не происходит явной передачи управления. Соответственно, вместо адреса точки входа в библиотечную функцию, вызвающей программе необходимо знать ID задачи и ID запроса. При этом нет разницы, где расположена библиотечная функция — в соседнем потоке, на другом ядре или вообще, реализована аппаратно.
Добавятся инструкции захвата и освобождения буфера сообщений. Добавится самая главная инструкция, ради которой всё это затвевлось — «Inter Process Communication». Пока что есть мысли реализовать эту инструкцию через микрокод. Видите, даже мненмонику ей ещё не придумали — аббревиатура IPC будет не очень удачной, поскольку среди электроников аббревиатура IPC имеет устоявшееся значеие «Instructions Per Cycle».
Есть идея спрятать «удалённую сторону» за инструкцией обмена сообщениями — в общем случае задача, выполняющая обмен сообщениями, не должна знать и видеть разницу с кем она обменивается сообщениями — с другой задачей или с устройством. Если удастся реализовать такую прозрачность, то дальнейшее будущее проекта видится в радужном свете.
Наконец, управление задачами и адресными пространствами планируется реализовать с помощью сообщений планировщику.
Вот такие планы на будущее.
О преимуществах системы команд не готов спорить — в настоящий момент реализовано минимальное подмножество, достаточное для практического применения. Но в силу минимализма она проиграет по эффективности другим системам команд. Однако, система команд спроективроана так, что может быть безболезненно расширена. В принципе, система команд проектировалась с учётом двух требований — простота разбора и расширяемость.
Наконец, что касается компилятора, то тут всё сложно — его научили лексическому и синтаксическому разбору, но до генерации кода руки не дошли. В общем, о компиляторе я пока не готов говорить — это половина компилятора. С другой стороны — есть несколько сторонних разработчиков, котрые пишут компиляторы. У нас есть взаимный интерес и при удачных обстоятельствах эти разрааботчики могли бы добавить поддержку нашего процессора в свои продукты.