Мой процессор

Автор goran d, 04.02.2016 00:54:16

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

goran d

Я пишу суперскалярный процессор на языке verilog.  Решился выпустить старую версию кода под лицензией GPL v2. Если хотите, можете поддержать.

Старая версия может выполнять до 6 инструкций за такт, имеетса вне-очередное выполнение с полу-раздельными диспечерами (по одному на 2 инструкции).
Пока работает только ALU и переходы, нет инструкций памяти, но есть порты для памяти на диспечерах.

https://www.kickstarter.com/projects/678823173/heptane-cpu-old-version-release-as-gpl

svmich

Горан,
а почему выбрана система команд от x86/64 (как я понимаю, с внутренней трансляцией в "родную" RISC)?

goran d

#2
Вообще-то, процессор будет поддерживать и свою RISC систему комманд, и x86/64 через трансляцию. Ето потому, что под x86/64 много софтуера. Разумеетса, x86/64 будет работать медленнее чем нативная система комманд. Своя архитектура такая, что при трасляции не надо жонглировать флагами.

svmich

Понятно.
То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?

В планах развивать старый, у которого до 6 инструкций за такт или тот, у которого до 9?

Я, конечно, не всё знаю - но может быть вместо встроенной в чип динамической трансляции было бы лучше написать, помимо статического двоичного транслятора, скажем, бэкенд для LLVM, чтобы в итоге под Heptane компилировались исходники C/C++ (и какие там ещё языки под LLVM есть), а не только готовые x86/64? Просто их промежуточный язык (LLVM IR) аналогичен ассемблеру, по сути это [строго типизированный] RISC.  :)

goran d

#4
Ну еще есть планы на порт GCC или LLVM,  но я не знаю насколько ето сложно. Наверно не так уж, если взять за основу какойто другой RISC процессор. Правда FPU я планирую довольно необычный, чтоб изпользовать все возможности надо будет много мучитьса с GCC. работа идет над 9. должен работать на 45нм и меньше.

svmich

А есть какие-нибудь подробности о новом варианте процессора (9-issue)? Как я понимаю, 9 - это пиковое значение IPC... И ещё: сколько стадий у нового конвейера?

Theoristos

#6
Цитироватьsvmich пишет:
То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?

В планах развивать старый, у которого до 6 инструкций за такт или тот, у которого до 9?
Что-то мне это сильно напоминает. Предлагаю название - Арарат.

ps: хотя само начинание вполне благое. Разве что с верификацией вопросы.

goran d

Ну вообще-то свобождать старую версию пока отказался. По новой версии есть сайт. http://www.heptane.co.uk
Там есть диаграма integer back-end.
Стадий 10, цена перехода при простом сложении или вычитании гдето 13-14, если посложнее - может быть гораздо больше.
Нащет верификации - можно было бы разделить на несколько FPGA когда будет работать, но такие платы стоят очень дорого.

Theoristos

А сколько логических элементов оно примерно стоит?

goran d

#9
Елементов не так много, старая версия была гдето 120000. Но ето только синтез. Беда в том, что реестры с многими портами и диспечеры жрут много провода, и ето ведет к тому что нельзя упользотворить все логические елементы. Ну, в принцыпе, если сделать с менше портов и делать переклююение по времени (т е один логический цыкл - несколько физических), тогда может и войдет в один high-end FPGA. Только без последнего уровня кеша, конечно. Ну тогда надо будет отдельно тестировать диспечеры и реестры. И конечно нельзя будет отладит последний уровень кеша и многоядерность.

goran d

#10
Забыл посмотреть на параметры софременных FPGA. Похоже, что уже и два ядра может быть вместятса на одну.
http://www.xilinx.com/support/documentation/selection-guides/ultrascale-fpga-product-selection-guide.pdf#VU

xvcu190 Наверно хватит и на двух ядерный с кешем.

svmich

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

goran d

Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти.
Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.

Alfred

а причем здесь новости космонавтики ?

svmich

#14
Цитироватьgoran d пишет:
Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти.
Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.
Т.е. при чтении из DRAM сохраняется контекст блокированной нити и загружается контекст для другой? А сколько конвейеров (ядер)?
Кэш данных L1, как я понимаю, 4К * 8 * 64 бит?


ЦитироватьAlfred пишет:
а причем здесь новости космонавтики ?
Центральный компонент современной системы управления ступенью ракеты-носителя или космического аппарата.

goran d

Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре.  Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный. :(

svmich

Цитироватьgoran d пишет:
Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре. Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный.  :(
Для начала пойдёт. А вообще - зачем двоичная совместимость с x86, почему компиляции мало? Т.е. ради чего так "связывать себе руки"?

goran d

#17
del

goran d

Отказался от RISV. Оказываетса, переделавать x86_64 target для gcc не так уж и сложно. Уже добился отсуствия операндов с памятью для сложения.

goran d

#19
дел