Я пишу суперскалярный процессор на языке verilog. Решился выпустить старую версию кода под лицензией GPL v2. Если хотите, можете поддержать.
Старая версия может выполнять до 6 инструкций за такт, имеетса вне-очередное выполнение с полу-раздельными диспечерами (по одному на 2 инструкции). Пока работает только ALU и переходы, нет инструкций памяти, но есть порты для памяти на диспечерах.
Вообще-то, процессор будет поддерживать и свою RISC систему комманд, и x86/64 через трансляцию. Ето потому, что под x86/64 много софтуера. Разумеетса, x86/64 будет работать медленнее чем нативная система комманд. Своя архитектура такая, что при трасляции не надо жонглировать флагами.
Понятно. То есть трансляция из x86/64 динамическая (в процессоре), а не статическая (в программном трансляторе)?
В планах развивать старый, у которого до 6 инструкций за такт или тот, у которого до 9?
Я, конечно, не всё знаю - но может быть вместо встроенной в чип динамической трансляции было бы лучше написать, помимо статического двоичного транслятора, скажем, бэкенд для LLVM, чтобы в итоге под Heptane компилировались исходники C/C++ (и какие там ещё языки под LLVM есть), а не только готовые x86/64? Просто их промежуточный язык (LLVM IR) аналогичен ассемблеру, по сути это [строго типизированный] RISC.
Ну еще есть планы на порт GCC или LLVM, но я не знаю насколько ето сложно. Наверно не так уж, если взять за основу какойто другой RISC процессор. Правда FPU я планирую довольно необычный, чтоб изпользовать все возможности надо будет много мучитьса с GCC. работа идет над 9. должен работать на 45нм и меньше.
А есть какие-нибудь подробности о новом варианте процессора (9-issue)? Как я понимаю, 9 - это пиковое значение IPC... И ещё: сколько стадий у нового конвейера?
Ну вообще-то свобождать старую версию пока отказался. По новой версии есть сайт. http://www.heptane.co.uk Там есть диаграма integer back-end. Стадий 10, цена перехода при простом сложении или вычитании гдето 13-14, если посложнее - может быть гораздо больше. Нащет верификации - можно было бы разделить на несколько FPGA когда будет работать, но такие платы стоят очень дорого.
Елементов не так много, старая версия была гдето 120000. Но ето только синтез. Беда в том, что реестры с многими портами и диспечеры жрут много провода, и ето ведет к тому что нельзя упользотворить все логические елементы. Ну, в принцыпе, если сделать с менше портов и делать переклююение по времени (т е один логический цыкл - несколько физических), тогда может и войдет в один high-end FPGA. Только без последнего уровня кеша, конечно. Ну тогда надо будет отдельно тестировать диспечеры и реестры. И конечно нельзя будет отладит последний уровень кеша и многоядерность.
Интересно, конечно... Но хоть основное бы узнать. Архитектура набора команд (ISA) у нового процессора - регистр-регистр? Все регистры - общего назначения? Что такое AGU? Какая разрядность по адресу и данным? Переключение между двумя нитями не подорвёт эффективность кэша? Какая организация и размер кэша данных первого уровня?
Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти. Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.
goran d пишет: Разрядность данных и адреса - 64 бит. Чтение-отдельно, вычисления-отдельно. AGU ето адресный генератор для памяти (Address Generator Unit). Вычисляет адреса в память и делает трансляцию виртуальной памяти. Если одна нить блокирует по чтению из DRAM то другая продолжит работать. Если блокирует по записи в DRAM, тогда обе нити будут ждать. Кеш данных л1 256kb 8-way. Не торопитесь говорить что такой размер л1 не возможен, HP PA-RISC имел больше.
Т.е. при чтении из DRAM сохраняется контекст блокированной нити и загружается контекст для другой? А сколько конвейеров (ядер)? Кэш данных L1, как я понимаю, 4К * 8 * 64 бит?
Цитата
Alfred пишет: а причем здесь новости космонавтики ?
Центральный компонент современной системы управления ступенью ракеты-носителя или космического аппарата.
Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре. Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный.
goran d пишет: Пришла в голову хорошая идея. Вместо того, чтоб клонировать x86 gcc , изменю порт gcc предназначенный для RISC-V. RISC-V не имеет флагов состояния, а използует сравнение-переход в одной инструкции. Что будет и в моем процессоре. Флаги оставлю как в x86 для совместимости! Получаетса, у меня почти готовый GCC! Правда очень урезаный.
Для начала пойдёт. А вообще - зачем двоичная совместимость с x86, почему компиляции мало? Т.е. ради чего так "связывать себе руки"?