Пассивный процессор или ... Контроллер-маршрутизатор?

Имеем задачу

Код (Text):

1. for(i = 0; i < n; ++ i)
2.     arr_c[i] = arr_b[i] + arr_a[i];

Вот классически процессор работает так:
Считывает ячейку массива A, считывает ячейку массива B, суммирует и результат записывает в ячейку массива C. Повторяет для всех указанных элементов массивов.
Назовём это как Активное процессорное устройство, так-как все данные обрабатывает только сам...

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

Пассивное процессорное устройство представляет из себя некий контроллер-маршрутизатор, к которому подключается некое число сумматоров, логических вентилей, регистров, счётчиков и мультиплексоров. А проще говоря, внешняя ПЛМ, программируемая на-лету.
Следуя алгоритму байт-кода, пассивный процессор производит сцепление соответствующих элементов логической матрицы в соответствии с текущим квантом алгоритма...
(здесь под квантом алгоритма я имею ввиду максимальный участок программы, который можно уместить в прошивке ПЛМ. т.е. если в ПЛМ имеется не более 32 сумматоров, то квант должен содержать не полее 32 операций сложения/вычитания. или не более 1-3 операций умножения/деления параллельного вычисления)

Таким образом, представленный выше for-цикл пассивный процессор обработает так:
Подключает к двум входам сумматора выходы микросхем памяти массивов A и B. Подключает выход сумматора ко входу на массив C. Устанавливает три счётчика-указателя адреса для каждой микросхемы памяти. Устанавливает четвёртый счётчик итерраций на число n... Объединяет тактовые входы всех счётчиков, дополняет их линией задержки для распределения тактов на чтение и на запись...
Начинает цикл тактирования:
Выдаёт строб-фронт на чтение данных массивов A и B;
Выдаёт строб-фронт на запись в массив C;
Выдаёт строб-фронт на инкремент трёх счётчиков и декремент итерратора.
Повторяет цикл, пока счётчик >= 0.
(здесь устройства памяти A B C могут быть как физически независимыми отдельными микросхемами, так и логически независимыми сегментами одной микросхемы памяти, но под управлением соответствующего контроллера)

Таким образом, сам процессор не имет ни АЛУ, ни каких-либо вычислительных средств. Но способен выполнять задачи на порядки быстрее, чем традиционные активные процессоры.
И в к тому же, не используемые в одном кванте элементы ПЛМ могут использовать другими квантами и, тем самым, возможна параллельная работа сразу нескольких потоков.

Скажите: Подобные контроллеры существуют? Ссылки есть на них?

Если же нет (в чём не уверен), давайте разберём возможные трудности и проблемы...

Спасибо!

 

А чем программируемая логика не нравится? Все выше описанные действия она должна выполнять на лету.

 

Вот вроде бы что-то похожее:
http://en.wikipedia.org/wiki/Channel_controller

 

вообщем предлагается под каждый непонятным образом сфантазированный "квант" работы процессора перепрошивать ПЛИС. все детали алу и прочих блоков cpu у тебя функционально будут присутствовать в твоей программе прошивки плиса просто ты будешь их подбрасывать на эту плис по мере необходимости. дикое извращение

не прослеживается мягко говоря

 

Я когда искал инфу про FPGA, видел модельки с интегрированным PCI/PCI-ex контроллером и вроде от Intel готовый продукт для высоко производельных вычислений, где прога комплируется в VHDL, потом прошивается и выполняется с большым % параллелизма.

 

Paguo_86PK
Сформулирую своими мыслями что хотел ты хотел сказать.

Есть вычислительные элементы и каналы. Это активное устройство. Такое на данной момент существует и называется ПЛИС(FPGA).

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

 

Собственно описана работа самого обычного процессора, просто в "велосипедной трактовке" )
Считанные из памяти команды разбиваются на микрооперации (кванты в трактовке Paguo_86PK), которые затем планируются в потоки и поступают на набор АЛУ которых несколько, что позволяет даже на одноядерных процессорах параллелить вычисления.
Если суть предложения Paguo_86PK в том чтобы просто укрупнить этот механизм, т.е. чтобы процесор сначала слеплял несколько команд в один блок (байт код), который затем проделывет тот же путь, то следует вспомнить, что сложные команды loop, jecxz, xchg и т.п. работают значительно медленнее чем их составные аналоги, потому что во втором случае часть работы процессора по разбивке сложной команды на простые уже сделана на этапе программирования/компиляции.

 

суть передал pavia и это очевидно бред

 

Почему непонятным?

Неудивительно! Ну, я же всё тут в двух словах описал...

А если допустить, что ПЛИС использует страничное программирование? Т.е. на одну единицу матрицы приходится не одна ячейка памяти, а несколько. Разбиваем ПЛМ на несколько модулей, программируемый отдельно. Одни и те же вентили "лёгким" переключением страниц превращаются из одного элемента комплекса в другой...

Идеально: На каждую единицу ПЛМ приходится 8192 слов памяти для хранения её режима. Таким образом, вся ПЛИС содержит 8192 слоёв.
Один слой мы программируем под АЛУ. Второй слой - под контроллер магистрали. Третий - под дешифратор. Четвёртый - и т.д...
Что получается: Имеем задачу "эмулировать процессор X". Все процессоры имеют структуру. Тем самым, разбиваем всю его схему на структурно законченые модули. И каждый слой ПЛМ программируется под свою функциональную задачу. Если модуль не умещается на одном слое ПЛМ, разбиваем его на два подслоя и более.
Переключение слоёв ПЛИС производит за такт-два. Практически мгновенно вся ПЛИС переключается с одной схемы на другую.

Пассивный процессор работает следующим образом:
Никакой оптимизации на лету он не производит!
Первое, он программирует ПЛИС. Каждый слой ПЛМ прошивается в соответствии с "подпрограммами" (VHDL таблицами). На это требуется время.
Второе, схема каждого слоя ПЛМ имеет свой набор внешних вентилей ввода-вывода. Условно назовём их портами.
Третье, когда все слои ПЛМ прошиты, начинается интерпретация программы. Каждая код операции - код слоя ПЛМ. Операнды операции - входы и выходы слоя ПЛМ, т.е. порты.

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

Здесь скорость пассивного процессора уже стала очевидной.

Недостатки:
ПЛИС должна иметь избыточно превышающую ёмкость памяти. От 16 страниц и более. Очень дорого.
Программирование пассивного процессора - чрезвычайно сложная задача. Необходимо корректно и согласовано расставить все "порты", чтобы как можно большее число модулей могли просто состыковываться на уровне ввода-вывода.
А если некоторые модули разбиты на несколько подмодулей по слоям, необходимо не только верно обеспечить их состыковку, но и корректно расчитать алгоритм тактирования и число подитерраций.

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

 

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

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

в любом случае перекачивание 2 мегабит маски у вас займет больше, чем выполнение 10ка лишних команд

 

Paguo_86PK
Современные процессоры давным давно имеют не одно АЛУ а кучу исполнительных блоков (почти то что ты называешь ПЛИС). Планировщик микроопераций (МОП-ов) это твой "программатор" ПЛИС, который и определяет в какой комбинации нужно соединить или распараллелить исполнительные блоки. Трэйс-кэш это память ПЛИС, которая помнит комбинации исполнительных блоков на уровне организации циклов.
Понятно что исполнительные блоки чем мельче и больше по количеству, тем больше гибкость и возможность распараллеливания. Но это требует навороченности планировщика (программатора). А его навороченность ограничена тепловыделением и "принципом равной производительности" - если возможностей распараллеливания будет столь много что планировщик не будет успевать поставлять нужное количество команд и данных, то толку от этой возможности будет не много ) Потому и процесс измельчения исполнительных блоков и усложнения планировщика идёт не "революционно", а по мере появления технических возможностей

 

Я в курсе. Не думаю, что многое здесь стало для меня новостью...
Заниматься процессорными секциями ещё отец предлагал. Давно очень...

Тут речь идёт о другом...

Распешу по пунктам:
1) Допустим, имеется ПЛИС, выпускаемая для нужд этого процессора и программируемая достаточно быстро: Сама ПЛИС выполнена как сопроцессор. По команде процессора она загружает массив из общей памяти в свою. И не маленькими там битами-байтами, а 128/256-ти разрядными словами;
2) Страничная память ПЛИС может за один-два такта переключаться. Вся логика ПЛМ тем самым переорганизовывается. Все логические блок-схемы грузятся в страницы ОЗУ в самом начале. А потом только переключаются. Так, например мы в первую страницу прошили счётчики тактов и логику для формирования видео сигнала. А во вторую страницу прошили формирователь адреса видеопамяти и дешифратор. Тогда для работы схемы понадобится два-четыре такта на квант времени. Т.е. растр будет переключаться к следующему пикселу каждый четвёртый такт;
3) Благодаря страничной организации ПЛИС, вся схема может работать рекурсивно. Т.е. все порты замкнуты на себя. Думаю, это надо проиллюстрировать:

Код (Text):

1. Сначала прошьём память ПЛМ двумя страницами:
2.  
3. Страница #1:            Страница #2:
4. Двоечный счётчик        Логический
5. тактов.                 элемент три-И.
6. Layer #1:             │ Layer #2:
7. PORT1┌─┬───┬─┐  PORT2 │ PORT1      PORT2
8. █────┤C│CT2│1├────█   │       ┌───┐
9.      ├─┤   │2├──────█ │   █───┤&  │
10. █────┤R│   │4├────█   │ █─────┤   ├────█
11.      │ │   │8├──────█ │   █───┤   │
12.      └─┴───┴─┘        │       └───┘
13.  
14. Затем, пассивным алгоритмом счепим две страницы
15. ПЛМ так, чтобы получилась одна целая ПЛИС:
16. PORT1┌─┬───┬─┐  PORT2
17. █────┤C│CT2│1├────█           ┌───┐
18.      ├─┤   │2├────────────────┤&  │
19. ┌────┤R│   │4├────────────────┤   ├────┐
20. │    │ │   │8├────────────────┤   │    │
21. │    └─┴───┴─┘                └───┘    │
22. └──────────────────────────────────────┘
23.  
24. Алгоритм:
25. do {
26.   Layer1.port1 = Layer2.port2 ^ 1; // Подключаем выход лог.И ко входу сброса счётчика. И тактируем.
27.   Layer2.port1 = Layer1.port2;     // Подключаем выходы счётчика ко входам лог.И
28. } while(TRUE);                     // Бесконечный цикл

Здесь на работу схемы будет уходить 4 такта.
Следует подметить: Память ПЛМ должна хранить не только несколько страниц прошивки, но и "помнить" состояние каждого узла.

В общем, задача очень сложная. Я давно это понимаю. Ещё когда делал первые наброски.
Во-первых, найти мультистраничную ПЛИС - дело, сами знаете какое;
Во-вторых, сам процессор - лишь набор мультиплексеров. А машинный код - что-то абстрактное и туманное...

 

Paguo_86PK

Если очень хочется поэкспериентировать самому то делать это имхо следует не на ширпотребных ПЛИС, и процессорах, которые для таких экспериментов естественно не предназначены, а на своём эмуляторе, где ты запросто реализуешь любую логику (уж что-что, а логические вентили эмулируются элементарно, впрочем как и их "сложные" комбинации типа сумматоров и умножителей И машинный код тоже можешь свой сделать - тут по соседству как раз тема про "оптокоды" )

Я это в первом приближении вижу так - взять набор крупных исполнительных элементов: сумматор, умножитель, булевы операции, операций с памятью и т.д. (как будто они уже прошиты в ПЛИС), построить таблицу соответствия моп-ов и комбинаций исполнителей - это уже будет рабочий каркас эмулятора, а дальше уже постепенно двигаться в сторону измельчения блоков и распараллеливания их работы.

 

Кстати ещё:

Если 3 параллельных умножения это более менее реальная ситуация в "обычной" программе, то 32 параллельных сложения это уже экзотика, которой место не среди "обычных" команд, а среди специализированных векторных операций ) Но в любом случае даже для распараллеливания 3х умножений программист должен подвергнуть программу низкоуровневой оптимизации, заточенной под возможности распараллеливания конкретного процессора. Задача заставить планировщик "оптимизировать на лету", обнаруживая неочевидные возможности параллельного выполнения команд явно запредельная для современной техники, тем более что в большинстве случаев для этого нужно корректировать алгоритм.
Тема интересна как раз в том плане, чтобы определить потенциальные возможности такого "гиперраспараллеленного" процессора и класс задач на которых он будет эффективнее "обычного".
Уже понятно что "обычную" не заточенную под него программу он выполнять быстрее не сможет - большинство его возможностей просто окажется "за бортом" последовательной логики программы. Так что интересно как раз выяснить в каких случаях целесообразно специально разрабатывать параллельные алгоритмы под такие процессоры.
Так что для экспериментов однозначно эмулятор. Пытаться использовать готовую ПЛИС, это всё равно что из детского конструктора собирать прототип детали предназначенной для изготовления на 3d фрезерном станке с ЧПУ )

 

Спасибо! Эмуляторов i8080A и i80x86 я уже понаписал достаточно!
И опыт имею в этом деле более-менее не скудный...

Мне всегда было интересно заниматься тремя задачами:
1) Возможность реализации процессора с "интуитивно" ясной системой команд;
2) Возможность реализации процессора, который сам исполняет открытый текстовый листинг;
3) Возможность реализации процессора, строющего хоть мегасхему спутника Земли.

Итак, в эмуляции по этим всем трём пунктам я пришёл к:
1) теме, где был набросок + эмулятор в js-html. А также разработал первое правило-табу кодов команд:

Код (Text):

1. 00 - BREAK ; Байт нуля везде указывает на конец. И тут он прерывает подпрограмму;
2. 80 - NOP   ; 0x80 = -128. А как известно, -128, -32768 и т.д. практически переполнение. Буквально, невыполнение;
3. FF - HALT  ; Антипод BREAK. С разницей, что возвращает TRUE-статус подпрограммы

2) Тут я попотел хорошо. Были и модели, читающие из памяти по 128 битов и с помощью 16-ти масочных ПЗУ определяющих класс выражения и его длину. Но, прошивки для ПЗУ я так и не расчитал, а вариант разбора по байтам был очень медленным. Однако...
Появился вариант с тремя инструкциями: 128 кодов под NOP, 64 - под загрузку Value, и 64 - под загрузку Command. Оперирует почти с открытым листингом, но сжатым по простому алгоритму. Если подключить к реальной модели процессора всего три логических элемента-дешифратора, можно управлять двигателями ЛОГО-черепашки и Пером. А команды - соответствующие: LEFT RIGHT и т.д.
Однако реализован пока вьювер листингов, чтобы прикинуть степень сложности процессора;
3) Ну, это типу посвещена данная тема...

В общем.
Спасибо!
За внимание и помощь...

 

"Таким образом, сам процессор .... способен выполнять задачи на порядки быстрее, чем традиционные активные процессоры"

Похоже, ты хочешь сделать "программный автомат" на базе ПЛИС. Для работы он должен тактироваться внешним генератором. Известные мне ПЛИС работают на частотах существенно меньших, чем современные CPU х86, а цена ПЛИС на большое число ячеек довольно высока. Поэтому для классических вычислений использовать ПЛИС имеет смысл только в качестве опытного образца для отладки алгоритмов будущего изделия.

ПЛИС эффективны для задач с жесткими временными параметрами, например, если длительность входных сигналов или точность выдачи выходных сигналов меньше, чем время реакции классического CPU. Изменять алгоритм работы прошитой ПЛИС в некотором объеме возможно, если предусмотреть в проекте конфигурационные регистры, динамически записываемые внешним процессором.

 

MikDay

Это всего-лишь рабочая гипотеза ТС )
Чтобы она соответствовала реальности нужно не только сделать такую "суперпараллельную" машинку, но ещё и заточить под неё систему комманд и адаптировать программы.
Например, нужно проссумировать массив из N значений - большинство современных программистов (как и их предшественники, написавшие существующие программы) поступят примерно так:

Код (Text):

1. mov esi, offset array
2. mov ecx, [N]
3. xor eax, eax
4. @@:
5.    add eax, dword ptr [esi]
6.    add esi, 4
7.    sub ecx, 1
8. jnz @B

Суперпараллельный "пассивный" процессор имеющий к примеру 100 каналов суммирования встретив такую конструкцию, будет по прежнему работать в одноканальном режиме и не даст совсем никакого выигрыша, поскольку планировщик/"программатор" не сможет угадать в этом цикле возможность применения параллельной логики, особенно с учётом того, что в большинстве случаев приведённый код будет ещё и захламлён "hilevel мусором" или в цикл кроме суммирования может быть встроен ещё какой-нибудь дополнительный функционал.
Чтобы задействовать параллельность нужно изменить логику суммирования в программе, например так:
A[1] + A[2]; A[3] + A[4]; .... A[N-1] + A[N] - первый заход
(A[1] + A[2]) + (A[3] + A[4]) ... - второй заход и т.д.
Такую конструкцию планировщик уже сможет "распараллелить", хотя лучше предусмотреть специальную команду
суммирования массива, чтобы планировщик уже сам параллелил вычисления, а не "угадывал" задумку программиста.
Поэтому имхо такую разработку нужно начинать не с экспериментов с ПЛИС и даже не с её эмуляции, а с анализа широко применяемых алгоритмов на предмет возможности и целесообразности переведения их в "параллельную логику работы". Если таких возможностей будет много (в чём я лично не уверен, но пока всерьёз этим не займёшься точно не определишь) тогда разрабатывать систему команд, заточенную под реализацию этих возможностей, а уже потом эмулировать и реализовывать в железе. Но может оказаться и что "распараллеливающихся" алгоритмов критичных к быстродействию будет раз-два и обчёлся, тогда "суперпроцессор" не даст никакого выигрыша не только на существующих программах, но и на специально заточенных под него программах тоже

 

Сразу видно...

Первым делом, первым делом - программисты
Ну, а хардварщики, хардварщики - потом!

Это я к тому, что "пассивный" процессор задуман ни как замена процессорам-"активистам" с классическим программированием. Нет...
Прежде всего, да, как заметил MikDay, он на подобии "клеточного автомата": в определённый квант времени ПЛИС работает как один логический комплекс, в другой квант - как второй, третий комплекс и т.д.

Т.е. имем задачу эмулировать ZX-Spectrum:
В первую страницу ПЛМ прошиваем схему синхрогенератора для генерации ТВ-растра;
Во вторую страницу ПЛМ зашиваем дешифратор и формирователь адреса с мультиплексированием;
В третью страницу ПЛМ прошьём регистры периферии: Border, Ear, Tape-In/Out и т.д...
Т.е. разбиваем всю электронную схему Синклера на несколько функционально законченных логических блоков. А затем "пассивным" ходом только переключаемся между блоками и передаём логические уровни: От блока синхрогенератора к дешифратору и на реальный Z80; От Z80 и дешифратора к формирователю адреса; От формирователя адреса к реальным микросхемам ОЗУ/ПЗУ и к блоку периферии; От периферии и памяти к Z80 блоку синхросмеси... И т.д.

Тем самым, на полноценную эмуляцию Синклера будет уходить до 10-20 тактов пассивного хода. Никаких вычислений не производится. Просто за 5-10 шагов образуется целая схема средней или высокой интеграции при сравнительно малой ёмкости ПЛИС!

А вы говорите код подгонять, оптимизировать, распараллеливать... Ничего подобного!
Надеюсь суть задумки 100% прояснилась.

 

Наоборот запуталась )
ZX-Spectrum в самом конце своей истории существовал в виде CPU Z80 + ПЛМ (вся обвеска кроме памяти в одной микросхеме), уже не помню как энта машинка называлась но никакого фантастического быстродействия этот вариант схемотехнического решения не имел )

 

Причём тут это? O_o
Какое отношение может иметь "фантастическое" быстродействие к реализации ПЛМ?
Ведь речь идёт о простой реализации...

В моей же теме говориться о псевдо-ПЛМ программировании. Когда узлы, явно представляющие копию реальных-электронных не реализуются программно, а прошиваются в ПЛМ 1:1! Кесарю - касарево так сказать...

Я уже сказал. MikDay очень хорошо высказал мнение. Очень близко...