Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Infinity CPU |
|
|
по-моему....проще с компилятором баловаться - он-то штука софтовая....изголяться можно как угодно)
по-моему....проще с компилятором баловаться - он-то штука софтовая....изголяться можно как угодно)
|
|
|
|
Добавлено: Пт ноя 24, 2017 21:23 |
|
|
|
|
|
Заголовок сообщения: |
Re: Infinity CPU |
|
|
Да, с точки зрения получения максимальной частоты лучше, чтобы все крутилось в достаточно компактной области, содержащей LUT и триггеры. Фактически весь основной тракт данных процессора будет сделан строго в ячейках, а если еще привлекать память как операнд, образуется достаточно длинная линия от блока памяти, которая напрашивается на конвейеризацию. Двупортовая память в целом подходит не только для чтения двух операндов, а еще и для записи того, что было сделано предыдущей командой, поэтому один из портов можно отдавать на запись, а вот второй действительно на чтение операнда следующей команды. Есть еще, конечно, вариант с чередованием чет/нечет, для стека это удобно. Тогда можно взять два блока памяти, и использовать для чтения по одному порту от каждого, а вдвоем они как раз будут способны выдать два соседних числа со стека. Но это выглядит уже решением следующего порядка, а на первых порах хочется спроектировать архитектуру системы команд так, чтобы она оптимально подходила к компилятору. Причем, что важно в контексте форума, не просто к компилятору, а к связке инструментов Форт+ЯВУ.
Да, с точки зрения получения максимальной частоты лучше, чтобы все крутилось в достаточно компактной области, содержащей LUT и триггеры. Фактически весь основной тракт данных процессора будет сделан строго в ячейках, а если еще привлекать память как операнд, образуется достаточно длинная линия от блока памяти, которая напрашивается на конвейеризацию. Двупортовая память в целом подходит не только для чтения двух операндов, а еще и для записи того, что было сделано предыдущей командой, поэтому один из портов можно отдавать на запись, а вот второй действительно на чтение операнда следующей команды. Есть еще, конечно, вариант с чередованием чет/нечет, для стека это удобно. Тогда можно взять два блока памяти, и использовать для чтения по одному порту от каждого, а вдвоем они как раз будут способны выдать два соседних числа со стека. Но это выглядит уже решением следующего порядка, а на первых порах хочется спроектировать архитектуру системы команд так, чтобы она оптимально подходила к компилятору. Причем, что важно в контексте форума, не просто к компилятору, а к связке инструментов Форт+ЯВУ.
|
|
|
|
Добавлено: Пт ноя 24, 2017 14:48 |
|
|
|
|
|
Заголовок сообщения: |
Re: Infinity CPU |
|
|
хм... Т.е. с точки зрения повышения скорости лучше иметь два выделенных регистра T, S (top, second) и хвост стека в памяти с регистром-указателем? Или на автомате/фоном кешировать два верхних элемента стека в регистры (память вроде там была двухпортовая, можно делать это в один приём)...
хм... Т.е. с точки зрения повышения скорости лучше иметь два выделенных регистра T, S (top, second) и хвост стека в памяти с регистром-указателем? Или на автомате/фоном кешировать два верхних элемента стека в регистры (память вроде там была двухпортовая, можно делать это в один приём)...
|
|
|
|
Добавлено: Пт ноя 24, 2017 04:42 |
|
|
|
|
|
Заголовок сообщения: |
Infinity CPU |
|
|
Неожиданно образовалось развитие ядра Горыныч. Горыныч оказался полезен тем, что 1. Позволяет без дополнительных затрат делить процессорное время от 1 до 8 потоков выполнения. Для низкоскоростных периферийных устройств запредельная частота работы ядра вобщем-то не требуется, а вот одновременная работа нескольких подпрограмм (или почти одновременная) гораздо полезнее. 2. Горыныч не навязывает именно стековый режим работы. Точнее, при стековой вычислительной модели он вполне программируется на Си-подобной языке (от true-grue), имея соответствующую поддержку, ненужную Форту, но полезную для кода, генерируемого таким компилятором. Технически, в ряду моих ядер, Горыныч был 7-го поколения (если считать именно принципиальные изменения микроархитектуры, а не просто версии). Соответственно, следующая версия - 8-я, а что у нас главное при работе с программами и вообще САПР? Правильно, выбрать имя Ну и чтобы была хотя бы притянутая за уши ассоциация, восьмерка после поворота превратилась в символ бесконечности, после чего проекты в САПР можно называть Infinity. Какой следующий шаг оказалось возможно сделать после Горыныча. Раз в Горыныче поддержан "двойной" режим программирования с точки зрения компилятора, новое ядро логично сделать с поддержкой такого режима в аппаратуре - чтобы при необходимости процессор мог работать как обычный регистровый, не занимаясь лишними перемещениями данных из стека/в стек. Отсюда получилась архитектура с двумя выделенными регистрами данных, которые схемотехнически подключены к памяти данных и могут являться продолжением стека... но могут и не являться. Поэтому та же команда сложения может выполнять два варианта действий: 1. RegA = RegA + RegB 2. A, B -- A+B , с соответствующим изменением указателя стека и догрузкой нового значения B из памяти данных Ожидаемый эффект - некоторое повышение рабочей частоты из-за устранения блока памяти из критического пути. Блоки памяти в ПЛИС вообще достаточно быстрые, но очен любят быть конвейеризованными. Поэтому послать данные из памяти сразу в АЛУ можно, но частота будет... приемлемой. А вот схемотехника, основанная на регистров, позволяет поднять частоту до довольно больших значений. Главное, чтобы из памяти данные поступали сразу в регистры, а не "в регистры через арифметические операции". После завершения составления списка требуемых транзакций будет попробован RTL.
Неожиданно образовалось развитие ядра Горыныч. Горыныч оказался полезен тем, что 1. Позволяет без дополнительных затрат делить процессорное время от 1 до 8 потоков выполнения. Для низкоскоростных периферийных устройств запредельная частота работы ядра вобщем-то не требуется, а вот одновременная работа нескольких подпрограмм (или почти одновременная) гораздо полезнее. 2. Горыныч не навязывает именно стековый режим работы. Точнее, при стековой вычислительной модели он вполне программируется на Си-подобной языке (от true-grue), имея соответствующую поддержку, ненужную Форту, но полезную для кода, генерируемого таким компилятором.
Технически, в ряду моих ядер, Горыныч был 7-го поколения (если считать именно принципиальные изменения микроархитектуры, а не просто версии). Соответственно, следующая версия - 8-я, а что у нас главное при работе с программами и вообще САПР? Правильно, выбрать имя :) Ну и чтобы была хотя бы притянутая за уши ассоциация, восьмерка после поворота превратилась в символ бесконечности, после чего проекты в САПР можно называть Infinity.
Какой следующий шаг оказалось возможно сделать после Горыныча. Раз в Горыныче поддержан "двойной" режим программирования с точки зрения компилятора, новое ядро логично сделать с поддержкой такого режима в аппаратуре - чтобы при необходимости процессор мог работать как обычный регистровый, не занимаясь лишними перемещениями данных из стека/в стек. Отсюда получилась архитектура с двумя выделенными регистрами данных, которые схемотехнически подключены к памяти данных и могут являться продолжением стека... но могут и не являться. Поэтому та же команда сложения может выполнять два варианта действий: 1. RegA = RegA + RegB 2. A, B -- A+B , с соответствующим изменением указателя стека и догрузкой нового значения B из памяти данных
Ожидаемый эффект - некоторое повышение рабочей частоты из-за устранения блока памяти из критического пути. Блоки памяти в ПЛИС вообще достаточно быстрые, но очен любят быть конвейеризованными. Поэтому послать данные из памяти сразу в АЛУ можно, но частота будет... приемлемой. А вот схемотехника, основанная на регистров, позволяет поднять частоту до довольно больших значений. Главное, чтобы из памяти данные поступали сразу в регистры, а не "в регистры через арифметические операции".
После завершения составления списка требуемых транзакций будет попробован RTL.
|
|
|
|
Добавлено: Пт ноя 24, 2017 03:08 |
|
|
|
|