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

Ещё поправочка (когда наконец вернётся редактирование?) по экономии транзисторов - для 32 разрядного случая в последовательном (б) варианте суммирования всегда эффективно используется 34 разряда (33 за счёт сдвига + 1 перенос), соответсвенно старшие разряды в младших сумматорах можно не реализовывать совсем, а младшие разряды старших сумматоров заменять проводниками, которые вполне успешно выполняют операцию "прибавить 0" ). В древовидном (а) варианте - в первом слое эффективны те же 34 разряда, но можно не реализовывать и младшие и старшие разряды там где они не нужны, т.е. не заменять транзисторы проводниками, а не использовать разряды совсем. Зато в последующих слоях количество эффективных суммирований возрастает, а в последнем слое суммирование становится полноценным 64 разрядным, т.е. имеем меньший расход "перемычек", которые тоже место в кристалле занимают, но больший расход транзисторов, хотя на фоне полученного выигрыша по скорости, "перерасход" транзисторов совсем маленький )

 

?

 

Мдя-яяя. Одну ночь телефон не работал у меня, а напостили тут!.. ))

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

Тут Вы меня убили!!!
Когда-то на смену ТТЛ пришли КМОП. Я считал КМОП достаточно сейчас развитой. А что, база сменилась? Похоже я сильно отстал. Дайте ссылку на описание новых полупроводников!

Вот именно!
Начинаю писать эмулятор и практически сразу возникает большая загвоздка! Просчёт есть типо в загрузке операций или операндов. Тут у меня полная лажа все 15 лет!

P.S.: В попытках выйти за рамки вычислительного программирования первым появился ПРОЛОГ как я помню.
Вот, пусть это и дурость, но этим "пассивным" я пытаюсь разработать общую концепцию не вычисляющего процессора. А вы эмулятор говорите! )
У меня нормальной концепции то нет...

Есть, правда, как уже сказал выше, два проекта. Вычислений там, кхм, почти нет. Но, и применения тоже)))))))))))))))))

 

Вот давай с этого и начнём )
Как я понимаю первый пост этого топика на примере того же умножения:
"Активный процессор" это процессор не имеющий аппартного умножителя и вынужденный огранизовывать сдвиги и сложения последовательно в цикле - естественно это медленно, зато транзисторы экономятся )

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

Именно так и работают современные процессоры, за исключением простейших вроде микроконтроллерных.
т.е. ответ на вопросы:
>> Подобные контроллеры существуют?
Конечно да
>> Ссылки есть на них?
http://www.intel.com/
http://www.amd.com/
и т.п

Или есть ещё идеи по совершенствованию схемы работы современных процессоров?

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

 

Не знаю, не знаю...
"Пассивным" я занялся какбы на "досуге"...

И он работает несколько иначе. Ща в двух словах опишу снова его принцип действия так:
Имеем n-ное число чёрных ящиков, содержимое которых - загадка. Входные и выходные данные никак не анализируются, так-как они просто неизвестного формата и тоже загадка. Но, ящики какрас совместимы;
Дана задача, читать некий набор инструкций и на каждом цикле активировать один ящик, анализировать статус и по нему определять следующий ящик с передачей данных ему;
Т.е. принцип АТС: сцепляет двух абонентов, а на каких языках они говорят - не имеет никакого значения! А "пассивная" программа - лишь набор правил: Абонент №x вызывает №y...

Можно, например, генератор белого шума сцепить с частотомером. И т.д.

Увы, есть.
Как я уже говорил. Меня привлекает ещё префиксная система команд:

Код (Text):

1. assembler:
2. ; Sample 1
3. ADD   ; Сложение в стеке как в Forth
4. ; Sample 2
5. SRC_1 ; Префикс регистра №1
6. ADD   ; Сложение стека с регистром №1
7. ; Sample 3
8. DST_1 ; Префикс регистра №1
9. ADD   ; Сложение регистра №1 со стеком
10. ; Sample 4
11. SRC_1 ; Префикс регистра №1
12. DST_2 ; Префикс регистра №2
13. ADD   ; Сложение регистра №1 с регистром №2 и помещение результата в стек
14. ; Sample 5
15. DST_1 ; Префикс регистра №1
16. SRC_2 ; Префикс регистра №2
17. ADD   ; Сложение регистра №1 с регистром №2 и помещение результата в регистр №1

Как видно, вариаций уйма. И везде используются префиксы. Конвейер команд получается простейщим. Кодов команд очень мало.
Но, тут проблема: Так-как непосредственные данные при таком подходе "этически" запрещены, требуется уйма таблиц и массивов. Причём со сложной иерархией. А это сильно усложняет модуль загрузки непосредственных данных. А реализация эмулятора "споткнулась" именно на этом модуле!

Но, больше всего привлекает процессор с текстовым набором команд. Например:

Код (Text):

1. 52 45 53 45 54 ; Все коды ниже 0x80 - NOP и дешифратор игнорирует. Здесь слово RESET
2. C5             ; C5 - Буквально означает Command из 5-ти букв
3. 44 4F 42 45 45 50 05 4C 4F 4F 50 ; Здесь буквально DO BEEP 0x05 LOOP
4. C2             ; C2 - Читает 2 символа команды. Т.е. DO. И DO сбрасывает счётчик
5. C4             ; C4 - Буквально Command из 4-х букв, следующих за DO, а значит BEEP
6. D1             ; D1 - Буквально Data из 1-го байта. А за DO BEEP следует байт 0x05
7. C4             ; C4 - читает 4 символа, а значит LOOP, который инкремирует счётчик и сверяет с загруженным числом 5

тем самым программа - практически читабильный текст, легко декодируемый для редактирования!
(конечно всякие Cx Dx и т.д. здесь для доходчивости. На деле же несколько иначе: Так-как все данные всегда < 128, команды Cx..Fx несут и старшие биты на каждый байт...
Эмулятора нет. Есть лишь вьювер таких "листингов". А в эмуляции проблема с тем, что "черезчур" широкий набор команд и аляписто...

 

Y_Mur

Не забывай, что умножение в совр.процах полностью конвееризовано, т.е. запуск новой операции может происходить в каждом такте. Поэтому скорее всего ступени разделены регистрами-защелками и соотв-но тактирование используется для фиксации промежуточных рез-тов для обеспечения конвееризации.
Неконвееризованная схема умножения с нефиксированной латентностью (по-видимому) использовалась в 486, который поддерживал "сокращенное" умножение в зависимости от размера\значения множителя. В современных процах такой фичи нет, т.к. фикс-ю латентность, во-первых, проще учесть при планировании, во-вторых, досрочная установка флага готовности по любому не позволит запускать зависимую операцию ранее 3-4 тактов, если учесть стадии планирования и диспатча

 

Разбираемся дальше:

Имхо вполне адекватное описание работы планировщика микроопераций в современном процессоре )
Он как раз разбирая заданный поток asm инструкций по кодам операций определяют какой блок задействовать и он естественно не имеет понятия о внутреннем устройстве блоков, и об их внутреннем формате данных, например для целочисленнного и FPU умножителей формат данных разный, но планировщик знает о них только размер word, dword, qword, tword и всё. Ответ он тоже получает только в виде флага/таймаута готовности, а данные результата сам не анализирует - только знает куда их дальше направить.

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

т.е. предусмотрен набор из 256 регистров? Имхо неплохая мысль ). Но если их меньше, то тратить целый байт на кодировку 5-10 регистров не рационально.
Кстати не понятно чем префиксы лучше чем коды регистров после кода операций?

По поводу текстового формата имхо совсем извращение - набор команд должен быть предельно лаконичен, чтобы не перегружать кэш и не усложнять работу кодоанализатора.

 

leo
Хорошее замечание по деталям, но речь там шла не о возможности досрочного завершения умножения, а о том, что логика работы рассмотренного древовидного умножителя явно не имеет черырёх "этапов" требующих отдельных тактов, т.е. работа самого умножителя однотактная - на границе очередного такта происходит защёлкивание результата в выходном регистре и замена входных данных на новые. С учётом большой латентности умножения это вполне можно делать "одновременно", т.е. по одному тактовому фронту.
Внутренняя же работа умножителя тактирования уже не требует. А 4 такта фигурирующие в мануалах это такты планировщика, а не умножителя и именно четыре их потому что время необходимое умножителю в ~4 раза больше времени отводимому планировщиком на самые быстрые операции (например mov reg, reg).

 

leo

Только сейчас дошло - ты хочешь сказать что даже один умножитель может работать в режиме конвейера и самостоятельно "параллелить" сразу 4 умножения находящихся в разных стадиях? Т.е. получается несмотря на отсутствие "естественных причин" для дробления работы умножителя на такты это дробление вводят "искусственно" для достижения конвейеризации - здорово!
Но это в общем, только дополняет, а не опровергает то что я написал постом выше )

 

Y_Mur

Ему и этого не нужно.
Планировщику нужно знать только на какой блок направить микрооперацию, плюс "каким-то образом" определять готовность самого мопа к исполнению и готовность блока принять этот моп. Как я уже упомянул, ориентироваться только на обратные связи с установкой флага готовности нельзя, т.к. из-за задержки петли обратной связи быстрые зависимые операции не смогут выполняться в каждом такте. Поэтому для быстрых операций планировщик сам должен знать их латентность, чтобы выпускать зависимую операцию через фикс.число тактов не дожидаясь установки флага. Плюс он должен сам учитывать throughput исп.блока, чтобы посылать быстрые независимые операции в каждом такте на ALU или каждые 2 такта на какие-нить FPU\MMX\SSE (в P4). Ну а медленные операции\блоки типа fdiv\fsqrt ес-но работают по флагам готовности
Резюме: для максимального быстродействия "маршрутизатор" должен знать latency и throughput исп.блоков, чтобы посылать операции на исполнение с упреждением, не дожидаясь установки флагов готовности

 

Да, это наз-ся full pipelined

Ес-но

 

Y_Mur
Блин, перескочил на след.страницу. Не забудь на пред.заглянуть - дополнение\уточнение к работе планировщика

 

leo
Замечательные дополнения/уточнения которые имхо хорошо демонстрируют базовую мысль - современный планировщик и есть тот самый "Пассивный процессор или ... Контроллер-маршрутизатор" который предложен ТС к обсуждению )

 

offtop
Застрявшая мысля в догонку: fdiv в совр.процах является half-pipelined, т.е. исполнение разделено на 2 стадии и соотв-но throughput fdiv вдвое меньше ее латентности. Но если fdiv реализована "аппаратно" (одна микрооперация), то целочисленные div\idiv - микропрограммно, и соотв-но куча мопов div просто забивает весь конвеер и не дает выполниться другим независимым операциям, пока для них не освободиться место в очереди планировщика

 

Неплохая мысль? Ну, может быть. Хотя дальнейщие детали могут её испортить.
Нет, не совсем 256.

Идея довольно-таки "древняя" и я её в подробностях опишу.
Префиксы нужны для того, чтобы команды имели фиксированный размер. Так проще для дешифратора: Есть блок дешифрации команд, есть блок дешифрации префиксо.
Префиксы - не совсем то, что вы думает. Да, был первый вариант, где были префиксы. Но, потом я поступил иначе. А имено:
1) Имеется Instruction Pointer дешифратора команд;
2) Имеется Register Pointer дешифратора префиксов;
3) Имеется Procedure Pointer стека процедурных возвратов;
4) Имеется Stream Pointer стека фреймов данных;
5) Имеется Table Pointer на непосредственные данные.
А теперь подробнее:
Операция MOV REG067, [REG014] кодируется таким образом, что RP указывает на байты 67 и 14, а IP указывает на код команды MOV. Т.е. программа представляется уже двойным потоком.
При вызове функции все данные накапливаются в SP стеке, а точка возврата - в PP. Далее, IP естественно устанавливается на начало процедуры и в TP адрес копируется также. Так-как IP работает на инкремент, а TP - на декремент, то точка входа в функцию является и источником оп-кода, и источником данных. Т.е.

Код (Text):

1. ; Фунция записи из памяти в регистр. Язык ассемблера
2. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
3. Func1:
4.     mov r17,[r19]
5. ; Внутреннее представление оп-кода. Язык суб-ассемблера
6. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
7. Func1:
8.     dst r17
9.     src [r19]
10.     mov
11. ; Уровень машинного кода
12. ;;;;;;;;;;;;;;;;;;;;;;;;;
13.     dd  19 + CPU_MEM_SRC
14.     dd  17 + CPU_REG_DST
15. Func1: ; IP = &Func1
16.     func; TP = IP - 1
17.     mov
18. ; void CPU_mov(void) {
19. ;     R1 = *(-- TP);
20. ;     R2 = *(-- TP);
21. ....................

Короче, организация машинного кода с одной стороны простейщая, а с другой - путанницы много. Уж слишком много стеков и иерархий...

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

 

Кстати. Один из самых первых вариантов процессора был таким:

Код (Text):

1. Коды 00..17 являются привелегированными. Ядро OS через них управляет ядром процессора. Тогда как прикладным задачам эти коды позволяют просто вызывать OS-API.
2. 00000000 HALT     Останов
3. 0000nnnn SYS01-15 Вызов функции OS
4. 00010nnn DEF0-7   Вызов предопределённой операции ПЛИС
5. Коды 18..1F - префиксы, управляют триггерами системы команд. Так, коды 20..FF меняют своё назначение, смотря каким блоком они обрабатываются.
6. 00011000 BASE     Блок центра
7. 00011001 MATH     Блок АЛУ
8. 00011010 DATA     Блок обмена данными
9. 00011011 CALL     Блок ветвлений
10. 00011100 BIOS     Исключения на функции OS
11. 00011101 TASK     Исключения на функции утилит
12. 00011110 UNIT     Блок исключений драйверов
13. 00011111 FILE     Блок ассоциативного ЗУ и файловой системы
14. Указание одного префикса переключают страницу команд на один цикл. Указание более одного префикса переключают страницу на все циклы. Например:
15. 1A          DATA           ; Префикс страницы данных
16. A8 15 D6 F8 LOAD 0x815D6F8 ; Загрузка в стек
17. 1B          CALL           ; Префикс страницы вызовов
18. 19          MATH           ; Префикс страницы АЛУ. Два префикса вподряд - первый станет основным
19. A8 15       AND  0x815     ; Операция "И" АЛУ
20. A8 15 D6 F8 CALL 0x815D6F8 ; Вызов подпрограммы
21. B8 15 E6 00 JMP  0x815E600 ; Переход
22. Как видно, здесь A8 имеет много значений взависимости от префикса. Хочу ещё заметить, что многие младшие тетрады операций являются расширением операнда:
23. A0 12 34 56 CALL 0x0123456
24. A1 12 34 56 CALL 0x1123456
25. A2 12 34 56 CALL 0x2123456
26. ..........................
27. AE 12 34 56 CALL 0xE123456
28. AF 12 34 56 CALL 0xF123456
29. Что позволяет длине команд быть немного короче, но охватывать до 256 млн. опкодов.
30. 1F          FILE
31. 1F          FILE           ; Префиксы FILE позволяют работать с файловой системой практически "прозрачно"
32. F1 00 15 D6 FIND 0x10015D6 ; Найти файл, маска которого находится по указанному адресу
33. A9 17       OPEN 0x9, 0x17 ; Открыть файл для чтения (0x17), используя регистр REG09
34. AD          READ           ; Прочитать данные файла

И, честно говоря, данный вариант оставался основным практически 6 лет

 

Paguo_86PK

Никакого табу тут нет - просто мысли у тебя изложены шибко сумбурно и невнятно, потому имхо и ответного интереса к ним нет

Я так понимаю эта мысль "выросла" из древнего архитектурного решения - собрать регистры в регистровый стек, а все операции делать только на его вершине - такое решение действительно резко упрощает схемотехнику, т.к. регистры не нужно адресовать совсем, соответсвенно и система команд и её обработчик резко упрощаются. Но у него есть и серьёзные недостатки:
- недостаточная гибкость - часто бывает данные уже есть в регистровом стеке но не на вершине и "дотянуться" до них нельзя - приходится заново грузить из памяти;
- такая архитектура заточена под последовательную логику работы и не допускает распараллеливания независимых операций.
Поэтому в современных процессорах архитектура основанная на регистровом стеке применяется в усовершенствованом виде (FPU), в ней есть не только операции на вершине регистрового стека, но и операции "вершина - произвольный регистр" и ещё ряд полезных дополнений.
Думаю можно проанализировать и обсудить возможность перевода в эту архитектуру, не только FPU, а и CPU, но строить на основе этого архитектурного решения такую систему кодирования команд:

имхо ни чем не оправданное извращение, ни каких плюсов я в нём не вижу. Упрощения кодоанализатора это явно не даёт, скорее наоборот - гораздо логичнее по опкоду определять наличие, количество и способ представления операндов и не нужны никакие извращённые взаимозависимые указатели.

 

Но, я ведь тоже создавал подобную тему...
Освежу материал:

Код (Text):

1. ...
2. 72 FF -> REPC  ; Расширение оригинальной инструкции
3. 72 FE -> SKPC  ; Пропустить одну инструкцию, если CF
4. 73 FF -> REPNC ; Расширение оригинальной инструкции
5. 73 FE -> SKPNC ; Пропустить одну инструкцию, если !CF
6. 74 FF -> REPE  ; Дубликат оригинальной инструкции
7. 74 FE -> SKPE  ; Пропустить одну инструкцию, если ZF
8. 75 FF -> REPNE ; Дубликат оригинальной инструкции
9. 75 FE -> SKPNE ; Пропустить одну инструкцию, если !ZF
10. ...

Кстати. В своих процессорах я огромное внимание уделял ещё и "опциональным флагам", и пропуску 1-7 инструкций. Т.е. флаговый регистр имеет 4-6 бита, которые никак не изменяются. Однако программа сама их может установить/снять, условно перейти и т.д. В некоторых случаях в x86 порою не хватает этого, и даже 1-2 таких флага были бы очень полезны. С условием, что установить/снять/проверить их тоже легко. Например:

Код (Text):

1. 78 FF -> SKP1  ; Пропустить одну инструкцию, если опциональный флаг №1 установлен
2. 79 FF -> SKPN1 ; Пропустить одну инструкцию, если опциональный флаг №1 снят
3. 7A FF -> SKP2  ; Пропустить одну инструкцию, если опциональный флаг №2 установлен
4. 7B FF -> SKPN2 ; Пропустить одну инструкцию, если опциональный флаг №2 снят
5. ... и т.д.

Потом, всё-таки некоторые "зачатки" ПЛИС должны появиться в процессоре. Так, для x86 в команде LEA помимо суммы иногда очень не помешала бы и разность. Или даже логика!
И напоследок. Желательно бы иметь хотябы скудненький набор для работы с Ассоциативным ЗУ. Всякие бы словари, переводчики и т.д. гораздо быстрее стали бы работать. А также перекодировку массивов. Не жалкой XLAT, а
;ESI - таблица xlat,
;EDI - строка,
;ECX - размер,
REP XLAT - циклическое XLATB всех символов
REP 0x66 XLAT - циклическое XLATW (utf-16)
...

 

Кстати, буквально недавно начал бегло изучать 68000. Интересно, что некоторые принципы его архитектуры использовались и мною. Например, адресные регистры. Только у меня они то включались в концепцию, то исключались...

Думаю, стоит попросить у вас совета. Сейчас такое сумасшедшее время, что все, кому не лень, разрыбатывают свою OS. У кого опыта побольше - свой комп. А у кого и времени навалом - свой проц...
В моём случае я проходил все эти "круги ада" и понял то, что в разработках процессоров я никак не могу вырваться за рамки RISC. А также, довести идею до "живой" эмуляции.

На данный момент я никак не могу разобраться с таким вариантом процессора:
Адресуемая память - 16 разрядов - 64кб. Доступные регистры - до 7-ми 32-битных с проекцией вне. Операции вызова подпрограммы и возврата не оперируют стеком. Итак...
1) Регистры подключаются внешние до 7 штук. Тут огромная проблема. необходим непосредственный доступ к регистрам процессора для схем АЛУ и т.д.:
Во-первых, если выводить их из процессора наружу, получится 7*32 = около 224 выводов!
Во-вторых, если подключить до семи внешних последовательно, то процессор не сможет напрямую обратиться к любому из них;
2) Указатель инструкции IP - 128-разрядный. Это нужно для следующего:
Во-первых, все команды переходов сдвигают IP влево на 16 бит. Так, при обращении к подпрограмме её код должен сам извлечь сдвинутый адрес и сохранить в стеке. Без этого можно вложить до 6 подпрограмм друг в друга. Это позволяет максимально упростить схему процессора;
Во-вторых, самые старшие 16 бит IP не сдвигаются и хранят адрес подпрограммы обработки ошибок/исключений. Инструкции BREAK/HALT сдвигают IP вправо, чем достигается возврат из подпрограмм. Если достигнут лимит в 7, соответственно управление получит подпрограмма ошибок/исключений.
Как видно, механизм простой и очень быстрый.
3) Все операции производятся над регистровым стеком. Чтобы ускорить процесс, стек - всегда реальные регистры, а не память. Причём, как сказано выше, до 7-ми регистров могут подключаться внешние, а ещё несколько - всегда внутренние:
Во-первых, для подпрограмм существует 21 регистр: 7 - верхушка стека, 7 - дно стека, и 7 - поле аргументов.

 

Paguo_86PK

а когда было другое?

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