Поиск  Пользователи  Правила  Войти
Страницы: 1 2 След.
RSS
Мой процессор
 
#1
0  
03.02.2016 22:54:16
Я пишу суперскалярный процессор на языке verilog.  Решился выпустить старую версию кода под лицензией GPL v2. Если хотите, можете поддержать.

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

https://www.kickstarter.com/projects/678823173/heptane-cpu-old-version-release-as-gpl
 
 
 
#2
0  
04.02.2016 22:58:27
Горан,
а почему выбрана система команд от x86/64 (как я понимаю, с внутренней трансляцией в "родную" RISC)?
 
 
 
#3
0  
05.02.2016 11:56:17
Вообще-то, процессор будет поддерживать и свою RISC систему комманд, и x86/64 через трансляцию. Ето потому, что под x86/64 много софтуера. Разумеетса, x86/64 будет работать медленнее чем нативная система комманд. Своя архитектура такая, что при трасляции не надо жонглировать флагами.
Изменено: goran d - 05.02.2016 12:15:24
 
 
 
#4
0  
05.02.2016 14:59:21
Понятно.
То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?

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

Я, конечно, не всё знаю - но может быть вместо встроенной в чип динамической трансляции было бы лучше написать, помимо статического двоичного транслятора, скажем, бэкенд для LLVM, чтобы в итоге под Heptane компилировались исходники C/C++ (и какие там ещё языки под LLVM есть), а не только готовые x86/64? Просто их промежуточный язык (LLVM IR) аналогичен ассемблеру, по сути это [строго типизированный] RISC.  :)
 
 
 
#5
0  
05.02.2016 15:40:56
Ну еще есть планы на порт GCC или LLVM,  но я не знаю насколько ето сложно. Наверно не так уж, если взять за основу какойто другой RISC процессор. Правда FPU я планирую довольно необычный, чтоб изпользовать все возможности надо будет много мучитьса с GCC. работа идет над 9. должен работать на 45нм и меньше.
Изменено: goran d - 05.02.2016 15:50:59
 
 
 
#6
0  
05.02.2016 23:45:14
А есть какие-нибудь подробности о новом варианте процессора (9-issue)? Как я понимаю, 9 - это пиковое значение IPC... И ещё: сколько стадий у нового конвейера?
 
 
 
#7
0  
06.02.2016 11:30:13
Цитата
svmich пишет:
То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?

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

ps: хотя само начинание вполне благое. Разве что с верификацией вопросы.
Изменено: Theoristos - 06.02.2016 11:30:55
 
 
 
#8
0  
06.02.2016 13:42:48
Ну вообще-то свобождать старую версию пока отказался. По новой версии есть сайт. http://www.heptane.co.uk
Там есть диаграма integer back-end.
Стадий 10, цена перехода при простом сложении или вычитании гдето 13-14, если посложнее - может быть гораздо больше.
Нащет верификации - можно было бы разделить на несколько FPGA когда будет работать, но такие платы стоят очень дорого.
 
 
 
#9
0  
06.02.2016 13:54:55
А сколько логических элементов оно примерно стоит?
 
 
 
#10
0  
06.02.2016 14:38:10
Елементов не так много, старая версия была гдето 120000. Но ето только синтез. Беда в том, что реестры с многими портами и диспечеры жрут много провода, и ето ведет к тому что нельзя упользотворить все логические елементы. Ну, в принцыпе, если сделать с менше портов и делать переклююение по времени (т е один логический цыкл - несколько физических), тогда может и войдет в один high-end FPGA. Только без последнего уровня кеша, конечно. Ну тогда надо будет отдельно тестировать диспечеры и реестры. И конечно нельзя будет отладит последний уровень кеша и многоядерность.
Изменено: goran d - 06.02.2016 14:39:18
 
 
 
#11
0  
06.02.2016 18:58:35
Забыл посмотреть на параметры софременных FPGA. Похоже, что уже и два ядра может быть вместятса на одну.
http://www.xilinx.com/support/documentation/selection-guides/ultrascale-fpga-product-selection-guide.pdf#VU

xvcu190 Наверно хватит и на двух ядерный с кешем.
Изменено: goran d - 06.02.2016 18:58:52
 
 
 
#12
0  
06.02.2016 23:24:37
Интересно, конечно... Но хоть основное бы узнать. Архитектура набора команд (ISA) у нового процессора - регистр-регистр? Все регистры - общего назначения? Что такое AGU? Какая разрядность по адресу и данным? Переключение между двумя нитями не подорвёт эффективность кэша? Какая организация и размер кэша данных первого уровня?
 
 
 
#13
0  
07.02.2016 11:20:44
Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти.
Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.
 
 
 
#14
0  
08.02.2016 13:32:30
а причем здесь новости космонавтики ?
 
 
 
#15
0  
09.02.2016 21:52:23
Цитата
goran d пишет:
Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти.
Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.
Т.е. при чтении из DRAM сохраняется контекст блокированной нити и загружается контекст для другой? А сколько конвейеров (ядер)?
Кэш данных L1, как я понимаю, 4К * 8 * 64 бит?


Цитата
Alfred пишет:
а причем здесь новости космонавтики ?
Центральный компонент современной системы управления ступенью ракеты-носителя или космического аппарата.
Изменено: svmich - 09.02.2016 21:55:52
 
 
 
#16
0  
12.02.2016 20:22:57
Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре.  Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный. :(
 
 
 
#17
0  
12.02.2016 22:49:27
Цитата
goran d пишет:
Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре. Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный.  :(
Для начала пойдёт. А вообще - зачем двоичная совместимость с x86, почему компиляции мало? Т.е. ради чего так "связывать себе руки"?
 
 
 
#18
0  
12.02.2016 23:13:07
del
Изменено: goran d - 13.02.2016 23:06:46
 
 
 
#19
0  
22.02.2016 18:27:25
Отказался от RISV. Оказываетса, переделавать x86_64 target для gcc не так уж и сложно. Уже добился отсуствия операндов с памятью для сложения.
 
 
 
#20
0  
16.04.2016 14:00:17
дел
Изменено: goran d - 16.04.2016 17:10:52
 
 
 
Страницы: 1 2 След.
Читают тему (гостей: 3)
Журнал Новости Форум Фото Статьи Книги