Я придумал новый микропроцессор. Часть II

В чем смысл размусоливать времянку по тактам и где блок-схема пайплайна?
Ну или хотя бы перечисление стадий конвейера.

А где графический сопроцессор?

Три стадии - выборка, декодирование и выполнение. Правда условно, поскольку выборка сделана отдельным модулем, а декодирование и исполнение реализованы в одном модуле, но разнесены по тактам.

Это даже не процессор, а голое ядро без кэшей, периферии и всего такого прочего. Графический сопроцессор где-то там далеко далеко в будущем.

Крузис потянет? Ато i7 тормозит.

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

Прочитал по диагонали. Нууу эээ круто :).

Что за симулятор используется? И какова частота «процессора»? 50MHz? Сужу по шкале времени.

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

Что за симулятор используется?

ModelSim от Mentor Graphics, который идёт прицепом к Altera Quartus. Пока отлаживаю только логику, а накручивать частоту буду потом.

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

новый микропроцессор

Ты ещё старый не собрал.

В чем смысл аппаратного микроядра?

Аффтар, ответь, распиши чотко и по пунктам, как обалденно зашибенно аппаратное микроядро. Кого, в какой прикладной области, и за счет чего конкретно оно порвёт. Или оно сразу во всех областях безоговорочно рулить собралось (за счет чего?)? Пока эта рациональ не сформулирована ясно и не продана читателю, твоё ожесточенное пердоленье верилога никому не интересно.

Прослушал ролик про аппаратный планировщик, не убедительно ни разу. Где численные прикидки, сколько % пефоманса ты собрался наэкономить в сравнении с более традиционным переключением контекстов? http://wiki.osdev.org/Context_Switching

Посмотрел видео «Введение в планировщик „Эверест“» и «Микропроцессор Эверест». Как-то очень несвязанно.

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

Не понял как дерево в планировщике связано с его аппаратностью. Нельзя сделать такой же программный планировщик? Можно подробнее о пользе дерева вообще?
Вот у нас есть кучка задач с приоритетами, каждая задача получает время процессора пропорционо приоритету. Если задача встает в ожидании чего-то, то контекст переключается на следующую. Это такой тривиальный планировщик на пальцах. А теперь с деревом. Задачи одного уровня получают процессорное время на том же принципе, что и выше? А вложенные задачи получают хрен знает сколько, в зависимости от «настрония» задачи родителя? Т.е. тут не только особый процессор, особое ядро ОС, но и приложения уровня пользователя должны быть написаны хитрым образом? Получил квант времени, используй только половину! «Пятилетка за три года»?

Это вообще для систем общего назначения или что-то узкоспециальное?

Напомнило https://youtu.be/35zLnS3fXeA

Аффтар, ответь, распиши чотко и по пунктам, как обалденно зашибенно аппаратное микроядро. Кого, в какой прикладной области, и за счет чего конкретно оно порвёт.

Но зачем? Те, кто работает в этих областях (мелкий эмбеддед), и сами понимают. А остальным это всё неинтересно.

О! Я вспомнил где слышал о вас и о ваших проектах.

От ankh1989

Удачи вам в ваших начинаниях, ребята! :)

У меня пока впечатление, что мы имеем дело с каноническим ненужно™. Хотелось бы это впечатление рассеять

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

Да мне самому видео не нравится - опыта разговоров на камеру нет, поэтому волнуюсь и заикаюсь. Что касается преимуществ, то доказывать собираюсь на работающем примере. Т.ч. пока это некоторый proposal.

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

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

Не понял как дерево в планировщике связано с его аппаратностью. Нельзя сделать такой же программный планировщик?

Конечно можно! Но наиболее эффективен он будет на системах использующих синхронные сообщения.

Можно подробнее о пользе дерева вообще?

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

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

Именно так.

А вложенные задачи получают хрен знает сколько, в зависимости от «настрония» задачи родителя?

Именно так.

Т.е. тут не только особый процессор, особое ядро ОС, но и приложения уровня пользователя должны быть написаны хитрым образом?

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

Получил квант времени, используй только половину! «Пятилетка за три года»?

В принципе, все современные популярные многозадачные системы используют этот принцип. Иначе бы загрузка процессора была бы 100%.

Это вообще для систем общего назначения или что-то узкоспециальное?

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

Спасибо! Мы работали вместе с ankh1989 в компании Fast Reports. Он талантливый программист и мне приятно что он упоминал о проекте.

Вообще ничего не понимаю в потрохах микропроцессоров, но всегда было интересно, почему почти не делают стековые процессоры?

Теоретически они же должны быть очень простыми? Вот тут http://excamera.com/sphinx/fpga-j1.html пишут что всего «200 lines of Verilog».

Еще пишут что получается высокая плотность кода. «A complete system including the TCP/IP stack fits in under 8K bytes.»

Для самоделок должно же быть самое то? Даже в одно лицо можно сделать и железку и какой-нибудь С к ней.

alman, у вас здесь не видно компилятора: http://primula.l4os.ru/downloads/ . Это так и задумано или что-то сломалось?

Теоретически они же должны быть очень простыми? Вот тут http://excamera.com/sphinx/fpga-j1.html пишут что всего «200 lines of Verilog».

По статье по ссылке мало информации об устройстве. С моей точки зрения это конкурент. Хотелось бы сравнить архитектуры.

alman, у вас здесь не видно компилятора: http://primula.l4os.ru/downloads/ . Это так и задумано или что-то сломалось?

У нас «два компилятора» и ни один из них пока не умеет генерировать код. Есть наработки для lcc и есть свой синтаксический анализатор, а до кодогенератора руки пока не дошли. Но не исключен вариант что кто-то быстрее напишет свой компилятор под систему команд «Эверест». Интерес к проекту растёт. Намедни появилась новая статья о системе команд - http://everest.l4os.ru/hot_return/

А как процессор (обычный, Intel, скажем) определяет, где инструкция, а где данные? Всегда этот вопрос интересовал.

А как процессор (обычный, Intel, скажем) определяет, где инструкция, а где данные?

В архитектуре фон Неймана код и данные ничем не отличаются, это просто какие-то байты в памяти.

«Обычный Intel» при запуске прыгает на предопределенный адрес, считая что это код и начинает его исполнять. Потом уже, в процессе работы, может пометить кусок памяти как данные или как код. При некоректном обращении к этим кускам будет генерироваться «general protection fault» ( https://en.wikipedia.org/wiki/General_protection_fault )

Это общие данные. А хотелось бы конкретики.

Скорее всего внутри современных процессоров непосредственно в ядро инструкции и данные по разным шинам попадают из кэшей кода и данных. Согласен с vmx - процессор стартует с адреса памяти, который by design указывает на код. Дальше уже ответственность кода чтобы управление не передалось на данные. С точки зрения памяти ей всё равно что она выставляет на шину данных - код или данные. А процессора сам отслеживает что и куда он в данный момент считывает или записывает. Это если не вдаваться глубоко в внутренности устройства.

А хотелось бы конкретики.

Конкретно в двух словах не расскажешь. Чего стоят только несколько уровней кэшей.

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

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

На osdev есть вводная статья: http://wiki.osdev.org/System_Initialization_(x86)

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

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

Конкретная конкретика есть в Intel 64 and IA-32 Architectures Software Developer's Manual ( http://www.intel.com/content/www/us/en/processors/architectures-software-deve... ). Разбавленная - на том же osdev.org есть немного

Так может он и не стремится сделать супер перф проц, а преследует какие-то другие цели.
С тобой где-нибудь кроме лора общаться можно, мне бы процессоры пообсуждать.

dm.leontiev7@gmail.com например.

просто скажем так идея-то здравая: запилить в железе ядро mach L4 мне в принципе нравится. но! этого не достаточно. но идея ок.

О закладках и не только - http://everest.l4os.ru/fourth_way/

Текущий статус проекта - http://everest.l4os.ru/towards_fpga/