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

[Vapaamies]

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

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

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

Мож стоит устроить клуб анонимных, э-э-э, программистов для взаимопомощи такого рода? Вы мой проект поругаете/похвалите, я ваш. Голосом по Skype, естественно, ибо всё что можно написать -- уже написано, нужен толчок для следующего этапа. За реквизитами стучаться в личку или на почту.

К вам, Utkin, данное предложение тоже относится. Не помню, предлагал уже или нет.

[Utkin]

Не помню, предлагал уже или нет.

Нет не предлагали. Давайте организуемся . Предупреждаю сразу у меня склочный характер и нестандартный взгляд на вещи

[almandrykin]

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

Мало информации - вопросы будут глупые или повторяться.

К повторениям я уже привык. Когда на один и тот же вопрос отвечаешь 10 раз, сам уже начинаешь понимать

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

Да, спасибо за этот вопрос. Это был сложный выбор из вариантов реализации стека. Самый простой в x86 - регистр SP который автоматически обновляется при операциях работы со стеком. В то же время у RISC процессоров принято использовать так называемый "фрейм вызова", в который вместе с передаваемыми параметрами кладётся и адрес возврата. Для реализации стека был выбран промежуточный вариант - было принято соглашение по которому регистр общего назначения R14 используется как указатель стека, а инструкции PUSH и POP реализованы в виде макросов. Например, ассемблерная инструкция PUSH R2 выродится в следующий код:

0000:   37 e3           ; DEC 	R14, 4 
0002:   60 e2           ; MOV 	(R14), R2

Прерывания? Или какой-то другой механизм?

Сообщения! Аналога x86 инструкции INT в системе команд нет, как и нет понятия прерывния. Внутренние прерывания по инструкции заменяются сообщениями, а внешние прерывания от устройств тоже транслируются в сообщения.

Очень важный момент, отличающий этот процессор от традиционных архитектур - вместо обработчика прерывания работает обычная задача (называйте как хотите - поток, процесс, нить - не суть важно). И прерывание будет обработано этой задачей только тогда, когда задача будет готова его принять - выполнит инструкцию RECV. Выглядит необычно, кому-то покажется неоптимальным, но если разобраться, то такой подход сулит хорошие возможности. Чтобы не быть голословным, приоткрою секрет - инструкция RECV является общей для приёма сообщений от других задач и от внешних устройства. В результате код драйверов устройств значительно упрощается. Помимо этого инструкции RECV и SEND заменяют инструкцию x86 HLT. Когда все задачи блокированы в ожидании сообщений, то процессор переходит в режим низкого энергопотребления. Наконец, эти инструкции полностью заменяют таймеры - например, чтобы выполнить задержку задачи, ей нужно просто подождать некоторое время сообщений от самой себя. Разумеется, ожидающая задача не может послать себе сообщение, поэтому время ожидание будет отдано другим задачам или это время процессор будет "спать", если другие задачи блокированы.

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

[almandrykin]

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

Мож стоит устроить клуб анонимных, э-э-э, программистов для взаимопомощи такого рода? Вы мой проект поругаете/похвалите, я ваш. Голосом по Skype, естественно, ибо всё что можно написать -- уже написано, нужен толчок для следующего этапа. За реквизитами стучаться в личку или на почту.

Не возражаю. Отправил письмо на E-mail.

[Utkin]

Индексные регистры и наименования в стиле Rномер навевают мысли о ранних Эплах...

[waleri]

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

прерывание будет обработано этой задачей только тогда, когда задача будет готова его принять - выполнит инструкцию RECV. Выглядит необычно,

А что тут необычного? Самый обыкновенный кооперативный мультитаскинг, хорошо знакомый нам с времен Win 3.1 и Mac OS 9.

[almandrykin]

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

Индексные регистры и наименования в стиле Rномер навевают мысли о ранних Эплах...

Всё же ближе к вот к этому https://ru.wikipedia.org/wiki/1801BMx

[waleri]

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

Индексные регистры и наименования в стиле Rномер навевают мысли о ранних Эплах...

В ранних Эплах регистры были A, X и Y

[Vapaamies]

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

Не возражаю. Отправил письмо на E-mail.

Я ответил на e-mail, а в этой теме решил пока не отписываться.

[almandrykin]

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

А что тут необычного? Самый обыкновенный кооперативный мультитаскинг, хорошо знакомый нам с времен Win 3.1 и Mac OS 9.

Необычна тут попытка засунуть синхронное микроядро L4 непосредственно в ПЛИС. Т.е. процессор начинает оперировать понятиями "задача" и "сообщение". (В перспективе и адресными пространствами)

А если сравнивать ОС "Хамелеон", то её реализация всё же ближе к ядру Windows NT, чем к надстройке над DOS. Но я бы не хотел поворачивать разговор в эту плоскость - если не возражаете, лучше о процессоре. Тем более что он пока не метит на десктоп и сервера. Скорее микроконтроллер для промышленной автоматики, на котором в отдалённом будущем планируется запустить POSIX совместимую ОС.

Система команд тоже необычна - расширяема и имеет хорошую плотность кода. Инструкции сгрупированы таким образом, чтобы максимально облегчить их разбор и сэкономить на логических элементах ПЛИС. А если обойти ограничение максимальной длины инструкции в 5 байт, то расширять можно до бесконечности. При добавлении новых инструкций плотность кода будет только повышаться.