Приглашаю обсудить новую архитектуру

[waleri]

Сообщение от almandrykin

процессор начинает оперировать понятиями "задача" и "сообщение". (В перспективе и адресными пространствами)

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

[almandrykin]

Сообщение от waleri

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

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

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

Желаете расширить понятие сообщения? Только через разработку протокола. Но я опасаюсь что полная и дословная реализация спецификации L4X2 полностью бы покрыла все необходимые варианты расширений. А для некоторых задач такая реализация оказалась бы избыточной.

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

[ZuBy]

Я думаю она больше подходит для статьи Хабра, там много образованных и повернутых на таких вопросах. Найдете много решении в коментах

[Smitt&Wesson]

Сообщение от waleri

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

Угу. А без железа куда? Трах-бох-тибидох? Ну-ну. Сейчас большинство так думают.
Все микросхемы, черти делают, а программы - гномики пишут.
Это я к тому, что и моя жена так думает.

[p51x]

Сообщение от almandrykin

как и нет понятия прерывния. Внутренние прерывания по инструкции заменяются сообщениями, а внешние прерывания от устройств тоже транслируются в сообщения.

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

Сообщение от almandrykin

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

А смысл таких прерываний в проце? Как оно прервет поток тяжелой операции, гуя? Что с контекстом делать?

Сообщение от almandrykin

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

Т.е. у вас будет доп. арбитр устройств? Его настраивать можно?

Сообщение от almandrykin

Помимо этого инструкции RECV и SEND заменяют инструкцию x86 HLT. Когда все задачи блокированы в ожидании сообщений, то процессор переходит в режим низкого энергопотребления.

Т.е. еще повредаун по своему усмотрению?

Сообщение от almandrykin

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

И как она подождет? Кто считать тики будет? А если задачу надо приостановить?

P.S. Поясните момент:

Сообщение от almandrykin

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

[almandrykin]

Сообщение от p51x

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

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

Со временем входа в обработчик несколько сложнее. Минимальное время входа в обработчик возможно только при двух условиях - если обработчик готов его обработать (ожидает сообщение с помощью инструкции RECV) и если в момент прихода прерывания не выполняется задач с более высоким приоритетом. При выполнении этих условий вход в обработчик произойдёт практически мгновенно - я надеюсь уложиться в несколько тактов.

А смысл таких прерываний в проце? Как оно прервет поток тяжелой операции, гуя? Что с контекстом делать?

Хороший вопрос. Тут надо иметь в виду тонкий момент, что прервать процесс может только планировщик или сам процесс, выполнив инструкцию SEND, RECV или IDLE. В идеальной системе прерывание процесса планировщиком не нужно, поскольку задача сама должна отдать своё время операционной системе, т.е. в идеальной системе инструкций SEND и RECV было бы вполне достаточно. Разумеется, реальные программы далеки от идеальных, поэтому их периодически придётся прерывать с помощью планировщика. По моим расчётам такой подход будет работать даже для высокопроизводительных вычислений - внимательный читатель мог заметить, что система команд "Эверест" не имеет ни одной инструкции для операций с плавающей запятой. Предполагается использование одного или нескольких внешних "теговых" математических сопроцессоров. В этом случае основной процессор по прежнему большую часть времени проводит в ожидании, делегировав "числодробильные" задачи дополнительным устройствам.

Т.е. у вас будет доп. арбитр устройств? Его настраивать можно?

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


/* превысил размер сообщения. продолжение в следующем сообщении */

[almandrykin]

Т.е. еще повредаун по своему усмотрению?

И как она подождет? Кто считать тики будет? А если задачу надо приостановить?

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

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

Хочу отметить, что из дерева планирования можно построить разные алгоритмы планирования - в граничных условиях дерево может вырождаться в список задач с равными приоритетами или иерархический список. Ещё хочу подчеркнуть что дерево приоритетов обязано быть независимо от порядка старта задач - приоритет задачи (прежде всего позиция задачи в дереве планировния) должен выбираться исходя из класса задачи и запрошенного приоритета - например, драйвер, которому нужна realtime реакция на прерывния, должен быть иметь парентом планировщик, а какая-нибудь фоновая задача, работающая во время простоя, должна быть где-то внизу дерева планирования.

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

[p51x]

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

О, а это разве не аппаратный таймер? Не... совсем не он, ведь вы ж обещали без них.

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

Т.е. механизма прерываний у вас в проце нет, вы используете FPGA стандартный.

При возникновении события процессор мгновенно входит в планировщик (сейчас это сделано с помощью перекоммутации регистров общего назначения и счётчика команд)

Т.е. о контексте вы пока не думали, поэтому и "мгновенно", просто на фпга нашлись еще регистры, кроме ваших изначальных.

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

А если у меня ожидается тяжелая и требуемая быстрой обработки задача, я буду вынужден ждать пока проц проснется из повердайна и разгонится до нормальных частот?

а затем ответным сообщение передаёт управление обратно задаче

Т.е. не переключает задачи, а посылает сообщение типа "можешь поработать"? А если задача плюнет на сообщение "подожди"?

[Smitt&Wesson]

Уже пятая страница, а новой архитектуры так и не твидно. Может её и вовсе нет, а ТС нас за-нос водит?

[almandrykin]

Сообщение от p51x

О, а это разве не аппаратный таймер? Не... совсем не он, ведь вы ж обещали без них.

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

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

Т.е. механизма прерываний у вас в проце нет, вы используете FPGA стандартный.

В FPGA нет понятия прерываний. Вообще. Это абстракция более высокого уровня. В моём случае прерывания реализуются через вход в планировщик, который посылает сообщение обработчику этого прерывания.

Т.е. о контексте вы пока не думали, поэтому и "мгновенно", просто на фпга нашлись еще регистры, кроме ваших изначальных.

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

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

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

А если у меня ожидается тяжелая и требуемая быстрой обработки задача, я буду вынужден ждать пока проц проснется из повердайна и разгонится до нормальных частот?

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

Т.е. не переключает задачи, а посылает сообщение типа "можешь поработать"? А если задача плюнет на сообщение "подожди"?

Всё в руках программиста. Установить факт передачи сообщения можно по статусу выполнения инструкции SEND. Она заблокируется до тех пор, пока не сообщение не будет принято удаленной стороной или до ошибки или до таймаута. Но это лишь означает сообщение принято, но никак не означает что оно обработано. Имено для этого после передачи сообщения нужно слушать ответ, который вернёт результат и статус запроса. Задача может "плевать" на любые сообщения и в случае ошибка даже попытаться съесть 100% процессорного времени. К счастью, если это не задача ядра ОС, на общее поведение и время отклика такая задача не повлияет никак, ибо съест время простоя, в котором процессор экономит электроэнергию. Если же ошибка будет в задаче с выссоким приоритетом, то да - такое поведение навредит системе. Но я хочу сказать пустой бесконечный цикл в драйвере устройства заблокирует любую десктопную ОС - и самый современный Windows, и самый популярный дистрибутив Linux.