Я придумал новый микропроцессор

скучно.

к счастью, на разработку обратили внимание на одном из специализированных форумов

Пруф где?

http://primula.l4os.ru/cpu_design_part_2/

имелась в виду ссылка на спецфорум. на электрониксе ветка есть?

Начнем с самого простого: зачем? Какова цель проекта? Чем этот процессор будет отличаться от существующих?

Я мало что там понял, но интересно ::)

На электроникс пока рано ломиться - имхо, там слишком серьёзные люди. (Сказано не в обиду лоровцам) Пока там не пиарился, но вопросы задаю. Например вот мой вопрос - http://electronix.ru/forum/index.php?showtopic=118934

Начнем с самого простого: зачем? Какова цель проекта? Чем этот процессор будет отличаться от существующих?

Цель проекта - сделать микропорцессор с аппаратной поддержкой микроядра L4, т.е. поместить микроядро непосредственно в процессоре.

Чтобы ответить на второй вопрос, придётся сделать лирическое отступление. Я довольно недавно занялся Verilog, поэтому вместо доработки готовых процессоров с opencores.org решил потренироваться на своём собственном - модифицировать чужой код мне показалось сложнее, чем сделать «с нуля». Конечно, перед началом пришлось внимательно ознакомиться с дизайном где-то десятка корок и почитать про шину WishBone.

Теперь я готов ответить чем это будет отличаться. В результате должен быть создан микропроцессор с микроядром на борту. Это конечная цель проекта.

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

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

2. Хитрая работа со стеком - архитектура не поддерживает регистр Stack Pointer, вместо этого его заменяет обычный регистр, используемый по соглашению.

3. Один из ответов дан по ссылке - есть RISC процессоры, поддерживающие условный вызов подпрограмм, но мне не известны CISC процессоры, обладающие такой возможностью. Возможно они есть, в природе, тогда этот пункт можно вычернкуть.

4. Процессор ориентирован на позиционно независимый код. Возможно, я не первый, но в этом дизайне позиционно-независимость поставлена во главу угла.

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

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

а, вспомнил.

Сказано не в обиду лоровцам

ты думаешь там никого с лора нет? :)

ты думаешь там никого с лора нет? :)

Конечно есть. Иначе бы периодически не задавал тут вопросы о HDL. Это было в сторону тех лоровцев, кто далёк от электроники.

На чём печатаешь прототипы?

поместить микроядро непосредственно в процессоре

То есть сделать процессор программируемым?

ну так дай ссылку на один из специализированных форумов

2. Хитрая работа со стеком - архитектура не поддерживает регистр Stack Pointer, вместо этого его заменяет обычный регистр, используемый по соглашению.

А что тут хитрого-то? В старые времена это было в порядке вещей. Взять тот же PDP11 - там регистр стека ничем не отличался от остальных регистров, за исключением привязки его к командам jsr и rts. А в твоем процессоре команда call и аппаратные прерывания куда будут заносить адрес возврата?

А слабо сделать процессор вобще без аппаратной поддержки стека? :) Как в IBM S/360 (она же ЕС ЭВМ) например.

3. Один из ответов дан по ссылке - есть RISC процессоры, поддерживающие условный вызов подпрограмм, но мне не известны CISC процессоры, обладающие такой возможностью. Возможно они есть, в природе, тогда этот пункт можно вычернкуть.

Да тот же Z80 имеет дохрена команд условного вызова подпрограмм, и при этом вполне себе CISC.

«Исходники» OpenSPARC на Verilog тебе в помощь

Хотите challenge - их есть у меня.

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

Есть идея, что лучше больше команд одной длины, чем меньше, но разной.

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

Ну круто. Правда, если это соглашение всегда R1, то ... ну Вы поняли.

Пункт 3 вычеркнули по приведеной причине.

Процессор ориентирован на позиционно независимый код.

Зачем? Есть случаи, когда все программы статичны.

Давай, ЛОР, больше драмы и агрессии - вспомни Bolgen ОС и десяток школьников, которые «блистали» здесь со времени твоего появления. Докажи, что ты «торт».

Да кому ты со своим процессором нужен?

Думал, что это будет ckotinko или qulinxao

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

Зачем разная длинна команд? Это только усложняет железку. Да и если охото ускорить выполнение программ, то лучше многоканальный контроллер памяти использовать.

2. Хитрая работа со стеком - архитектура не поддерживает регистр Stack Pointer, вместо этого его заменяет обычный регистр, используемый по соглашению.

В чём преимущества?

4. Процессор ориентирован на позиционно независимый код. Возможно, я не первый, но в этом дизайне позиционно-независимость поставлена во главу угла.

Хорошо конечно. А есть возможность каждому процессу обладать своей «картой памяти»? Есть защита памяти от других процессов?

Я придумал новый микропроцессор

он зелёный и шевелится

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

А какие-нибудь способы связи с вами есть?

Цель проекта - сделать микропорцессор с аппаратной поддержкой микроядра L4, т.е. поместить микроядро непосредственно в процессоре.

Ну а дальше что? Практическое использование предусматривается, или это чистый jff или чья-то диссертация?

Проект «Xameleon» - российская микроядерная операционная система

http://l4os.ru/about

http://l4os.ru/license
«Исходный код системы и/или её подсистем, если это не оговорено отдельно, не распространяется и является собственностью их разработчиков.»

http://primula.l4os.ru/about/
«Добро пожаловать на сайт разработчиков компилятора Primula C!
Мы — команда энтузиастов, работающая над созданием оригинального компилятора языка Си.
Наша цель — создать лицензионно чистый, простой и легко переносимый компилятор для использования в проекте Хамелеон.»

Ты хоть киллер-фичи опиши.

На чём печатаешь прототипы?

Извини, я не понял вопрос. С удовольствием отвечу, если сформулируешь его иначе.

То есть сделать процессор программируемым?

Любой процессор и так программируемый :)

Подразумевается реализация в процессоре:

1. Cредств для многозадачности.

2. Cредств передачи синхронных сообщений между задачами.

3. Аппапартный планировщик задач.

4. Универсальные виртуальные страницы (размер 1024 * 2^N).

За PDP-11 спасибо. Некоторые идеи PDP-11 меня влохновляют.

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

А слабо сделать процессор вобще без аппаратной поддержки стека? :) Как в IBM S/360 (она же ЕС ЭВМ) например.

Мне - слабо.

Хмм, «меня терзают смутные сомнения».

Есть идея, что лучше больше команд одной длины, чем меньше, но разной.

VLIW пока не взлетел.

В чём преимущества?

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

Хорошо конечно. А есть возможность каждому процессу обладать своей «картой памяти»? Есть защита памяти от других процессов?

В нынешнем состоянии есть только декодер команд, исполнительное устройство и ALU. Они не оперируруют понятием виртуальной или сегментной памяти. Чуть выше них должен быть MMU, c поддержкой универсальных страниц (универсальные, потому что имеют размер 1024 * 2^N).

А какие-нибудь способы связи с вами есть?

Разумеется - да. И они практически навиду.

Подразумевается реализация в процессоре:

1

2

3

4

/me в ужасе оглядывается вокруг - неужели 80-е вернулись?

Я надеюсь, коллектив разработчиков этой вундервафли слышал о iAPX432 и проекте BiiN?

tailgunner - мой любимый оппонент. :)

Ну а дальше что?

Дальше это пойдёт в плату http://marsohod.org/index.php/howtostart/marsohod2

Так же есть идея раздать спеки и исходники процессора всем желающим на условиях некоммерческого использования. Раздать без аппаратного микроядра, а только «классический» процессор. О коммерческом использовании говорить пока рано. Об апаратном микроядре - тоже рано.

Упс. На остальные вопросы постараюсь ответить вечером, бо супруга претендует на внимание.

С удовольствием отвечу, если сформулируешь его иначе.

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

man fpga

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

Есть предложения.

1) Вместо того что бы делать разную длину команд, почему бы не сделать аппаратный сопроцессор который будет сжимать и распаковывать двоичный код. Благо оперативная память дешёвая. А компактный код может понадобиться для загрузчиков ОС.

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

а что, fpga уже не «железо»?

Можешь выложить фотки изделий?

Некоторые эксперименты ставились вот на этой плате:
http://marsohod.org/images/stories/plata2/plata_c3.jpg
http://marsohod.org/images/stories/c3/marsohod2/marsohod2.jpg

 ПЛИС Cyclone III EP3C10E144C8 компании Альтера.

       а) Логических элементов - 10320;
       б) Память - 414Кбит;
       с) Встроенных умножителей - 23;
       д) Количество PLL - 2.

Микросхема SDRAM MT48LC4M16A2-75 компании Micron. 
Четыре банка по 1,048,576 шестнадцатиразрядных слова. Итого, 64Мбита (или 8Мбайт, что то же самое).

Мне особо не с чем сравнивать, поскольку с другими FPGA дело не имел, но эта плата пока вполне устраивает. Надеюсь, я правильно понял вопрос.

годно вбросил, молодец. Слово «вбросил» могло было быть заменено на «сделал», добавь ты ссылки в верхний пост.

1) Вместо того что бы делать разную длину команд, почему бы не сделать аппаратный сопроцессор который будет сжимать и распаковывать двоичный код. Благо оперативная память дешёвая. А компактный код может понадобиться для загрузчиков ОС.

Нечто подобное рассматривалось. Точнее, рассматривалась идея системы команд в виде битового стрима, в котором длина команд могла бы быть не кратной 8 битам. Но это слишком смело. Ресурсов на такие исследования нет.

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

Оптимальность такого подхода, а именно большого регистрового окна, доказывал уважаемый специалист с форума IXBT. Авторитет этого человека подсказывает, что здравый смысл в этой идее есть.

Пока рано открывать «все карты», но эта идея заимствована для буфера сообщений.

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

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

Ожидаемый профит, как я понимаю, скорость?

Вообще, интересная тема.

VLIW пока не взлетел.

Глухой со слепым? Причем тут 'large instruction"? Я говорил про одинаковую длину, элементарно parse легче делать. PowerPC или RISC в догонку.

Ожидаемый профит в низкой латентности и в очень дешёвом переключении задач. За остальные параметры ничего не могу сказать, они зависят от многих факторов.

Ясно одно - соревноваться с процессорами, в которых используется распараллеливаение и предсказание переходов, смысла нет. Это суровая правда, с которой пришлось смириться. Однако, если бы прилетел добрый волшебник и процессор стал популярным, то в далёкой перспективе можно было бы реализовать и распараллеливание и предсказатели и ещё множество интересных вещей.

зато RISC взлетел. даже в x86

Я говорил про одинаковую длину, элементарно parse легче делать. PowerPC или RISC в догонку.

Чуточку легче, но в архитектуре RISC тоже не всё идеально. Да да да, я слышал, что современные x86 траслируют все команды в микрооперации, которые очень похожи на инструкции RISC.

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

однобайтовые команды 000xxxxx, иначе
двухбайтовые команды 0xxxxxxx
трехбайтовые команды 110xxxxx
четырехбайтовые команды 111xxxxx

Такие вещи легко описываются с помощью комбинаторной логики.

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

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

В остальном - наш диалог может вылиться в спор о RISC vs CISC. Не жалко времени на такой спор?

Потому что инструкции x86 сгруппированы неудачно. По историческим причинам.

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

а что, fpga уже не «железо»?

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