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

[Stilet]

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

А если мне понадобится попасть в другое адресное пространство? Ну мало ли. Я драйвер и мне нужно и не гребет. Как тогда быть?
И что мне делать если камушек это потребуется в контроллере, где память вся плоская и открытая?

Вот эти инструкции реализованы с помощью макросов

Так всетки - макрос это опкод, или это некая транслируемая команда?

В сокет его не засунуть.

Т.е. бытовой ориентации нет? Только промышленные контроллеры?

в одинаковом объеме памяти мы разместим больше полезного кода за счёт более коротких простых инструкций.

И как это вяжется с утверждением:

Размерность машинных инструкций от 1 до 5 байт.

Какая тут экономия то?
Приведи пример на стандартном ассемблере и твоем с демонстрацией экономии.

[almandrykin]

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

Почему код не трехадресный, например?

Основной причиной выбора двухадресного кода было желание сделать простые инструкции короче. И чтобы код на уровне HDL было как можно проще. Спроектированная система команд довольно просто и вполне оптимально реализуется на Verilog.

Если возникнет необходимость в трехадресных командах, то они будут размещены в области зарезервированных инструкций.

[Smitt&Wesson]

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

Если возникнет необходимость в трехадресных командах, то они будут размещены в области зарезервированных инструкций.

Т.е., вариации на тему аля-ассеблер? Плоско.

[almandrykin]

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

А если мне понадобится попасть в другое адресное пространство? Ну мало ли. Я драйвер и мне нужно и не гребет. Как тогда быть?

К сожалению версии 1.1 не оперирует адресными пространствами. Адресные пространства появятся когла мы реализуем MMU. В отличие от традиционных MMU ожидается что наше будет оперировать универсальными страницами виртуальной памяти. Универсальные страницы, в отличие от традиционных, могут иметь размер, вычисляемый по формуле 1024 * 2^n.

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

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

И что мне делать если камушек это потребуется в контроллере, где память вся плоская и открытая?

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

Так всетки - макрос это опкод, или это некая транслируемая команда?

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

Т.е. бытовой ориентации нет? Только промышленные контроллеры?

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

И как это вяжется с утверждением:
Какая тут экономия то?
Приведи пример на стандартном ассемблере и твоем с демонстрацией экономии.

Пример 1: Экономия на одном обращении к стеку в терминальных функциях. Т.е. функциям, которые никогда не вызывают другие функции и которые нерекурсивны, не нужно сохранять адрес возврата в стеке.

Пример 2: Условный вызов подпрограмм - добавление префикса NOTCH, например, к инструкции условновго перехода, сработает так, как если бы это был условный вызов подпрограммы. Пожалуй, надо пояснить:

; Пример для x86
      jne   label1
      call  subroutine
lablel1:

; Пример для нашей системы команд
      notch
      je   subroutine
lablel1:

Хотя во втором случае эффективность и не столь явная.

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

[Stilet]

или использовать другой микроконтроллер

Ахахах! Ключевое слово - Не покупайте мою продукцию.
Ну и ну.

Пример загрузки константы - макрос LEA выродится в две ассемблерные инструкции

Так где же тут экономия? Вместо одной операции две.

функциям, которые никогда не вызывают другие функции и которые нерекурсивны, не нужно сохранять адрес возврата в стеке.

Э-э-э... Не понял... А куда же они будут возвращать управление?

Хотя во втором случае эффективность и не столь явная.

Не столь явная? Боюсь что я ее в принципе не вижу.

[f.hump]

Зачем? Была необходимость расширишить любой из существующих процессоров некоим специализированным блоком (грубо говоря - сопроцессором, но не математическим. Об это позже). После изучения нескольких десятков проектов ("самопальные" x8086, ARM, Sparc, AVR на http://opencores.org) показалось что добавление "своего сопроцессора" в существующий дизайн по трудозатратам соизмеримо с разработкой процессора с нуля. Т.ч. давайте в этой теме больше не касаться вопроса "зачем".

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

[almandrykin]

Сообщение от Smitt&Wesson

Т.е., вариации на тему аля-ассеблер? Плоско.

Кстати, а в чём привлекательность трёхадресных инструкций? Я без иронии спрашиваю, а хочу понять.

[almandrykin]

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

Так где же тут экономия? Вместо одной операции две.

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

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

Э-э-э... Не понял... А куда же они будут возвращать управление?

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

Не столь явная? Боюсь что я ее в принципе не вижу.

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

Давайте посчитаем сколько байт займёт вот эта конструкция на x86

        jne  label1
        call subroutine
label1:

и сравним вот с этим:

        notch
        je   subroutine

Второй код (в среднем) поместится 4 байта - байт префикса и три байта условный переход. Помимо этого мой вариант не работает со стеком - адрес возврата сохранится в регистре R15.

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

[Stilet]

обязанность по сохранению адреса возврата ложится на программиста или компилятор

Вау... Это такая забота о человеке? Ну дальше мне уже не интересно стало. Желаю удачи. Надеюсь мне на подобных камнях работать никогда не придется.

[almandrykin]

Сообщение от f.hump

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

Цель разработки - поместить в процессор аппаратную реализацию микроядра L4. Т.е. "железка" начинает оперировать понятиями "задача", "сообщение", "адресное пространство".

Собственно, вот несколько слов о системе команд: http://everest.l4os.ru/cpu_commands_map_v1_1/

Если побродите по сайту, надеюсь, найдёте много интересного.

Этот процессор ждёт небольшая операционная система: http://l4os.ru/
Прототипу системы более 10 лет. Именно под неё и делается "железка".

Самая большая проблема в том, чтобы совместить эти проекты - в компиляторе. Система "Хамелеон" с дуру написана с применением классов С++ и очень серьёзно на них ориентирована. Поэтому даже Си-компилятор не решит польностью проблему - переписывать 100000 строк кода с С++ на Си никто не будет.

А вот тут эксперименты с ассемблером - глядя как от нас разбегаются люди при упоминании ассемблера, мы решили сделать его более дружелюбным. Вот что из этого получается: http://everest.l4os.ru/aliases_for_registers/