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

Paguo_86PK

Хм - дык и я про то, что прежде чем пытаться что-либо реализовать через аппаратный ускоритель следует разобраться с вопросом насколько часто используется эта конструкция в программах и какой реальный выигрыш от этого можно получить Если ты аппаратно с помощью своей ПЛМ ускоришь в 1000 раз операцию, которая по результатам профилирования занимает 0,01% времени от общего времени работы программы, то общий выигрыш в производительности будет не в 1000 раз, а менее чем на 0,01% ) Если ускоришь в 1000000 раз исполнение половины (по общему времени работы программы) команд процессора, то выигрыш в производительности будет не в 1000000 раз, а менее чем в 2 раза ) А сможешь ли ты аппаратно реализовать на ПЛМ ту часть программы, которая занимает 99,9% времени, это под большим вопросом.
Потому и говорю, что начинать такое исследование следует всё таки с анализа алгоритмов вообще и применимости в них предлагаемого метода аппаратного ускорения в частности

 

Хм...

Во-первых, сейчас очень популярны эмуляторы Dendy, Sega, Sony-PSX, X-Box там и т.д. И везде львиная доля вычислений уходит на эмуляцию аппаратной части: от процессора до видеоконтроллера. Вот эти задачи и возможно переложить на ПЛИС;
Во-вторых, помню лет десять назад появилось такое извращение, как Soft-Modem. Не знаю, как сейчас эта идея и реализация живёт, но слышал, что он хоть и дешевле, но при подвисании системы или проблеме распределения машинного времене такие модемы не могли удерживать связь. Что приводило к дисконнекту. Сейчас эти извращенцы могли бы и ADSL эмулировать программно. А ещё хуже - спутниковый интернет! Бр-ррр...;
А в-третьих, эти исследования я начал ещё в конце прошлого века, или тысячелетия (как хотите)... Но, задача такая сложная для одного человека (меня), что я попытался её изложить в этой теме... Идея эта стара! Ей как минимум, лет 13...

Я помоему говорил, как она родилась? Не помню... Говорил ли...
Тем не менее. Когда я только-только стал знакомиться с вычислительной техникой, то на вопрос, как я понимаю принцип работы процессора, я очень просто ответил:
Считывает команду, дешифрирует, мультиплексорами устанавливает межрегистровые связи или с АЛУ, стробом выполняет, сохраняет результат, а затем мультиплексоры возвращаются в исходное состояние...
Тогда я подумал ещё "какая-то тупейщая интерпретация машинного кода" и стал искать способы "компиляции машинного кода".

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

Но... Один из великих умов цифрового мира говорил, что хоть процессоры и стали мощней в сотни раз, программное обеспечение всё-таки сильно отстаёт.
Знаете, когда я процитировал своими словами подобное, меня все высмеяли. Многие сказали "Ты с ума сошёл? Как такое может быть, если программы сейчас так жрут ресурсы, что новейщий процессор еле справляется!?"...
Я не стал с ними спорить... Правда ведь в другом.

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

Смотрите...

Классическое программирование привело к тому, что некоторые задачи решать до сих пор достаточно ресурсоёмко. Ни графику, ни физику. А простую СУБД потянуть сейчас может не каждый компьютер. Не давно я в чате разговаривал с товарищем. Линуксом я не увлекаюсь, поэтому не помню о чём он говорил, о какой утилите. Но, как я понял, связано наверное с сетью...

Так вот...

Покупаете значит аэрозольный балончик с эмалью. И перед тем, как им воспользоваться, необходимо хорошенко встряхнуть. Чтобы шарики внутри размешали массу. А затем можно хоть графити заниматься!

Это я о чём? А о том же. Все эти MMX / SSE / 3D Now! похожи на те шарики в балончике. Кажется, чем сильнее вы будете ими трясти, ты скорее будет алгоритм. Довольно-таки громоздкая попытка шагать сразу через четыре ступеньки.

Не проще было бы ввести префикс-байт, разрывающий подбайты? Чтобы обыкновенная ADD / SUB / MUL команда работала с подбайтами и подсловами регистра отдельно! Делов то: Разорвать в АЛУ перемычки переносов от старших битов к следующим. И работай хоть с тетрадами!

Но, я отвлёкся...

Помните мою тему. Как ловить радио или даже ТВ без тюнера?
Т.е. тупо на вход микрофона втыкаем антенну и в режиме реального времени программой-эквалайзером отфильтровываем радиочастоты 500кГц или 12мГц... Теоритически, если имеем скоростной АЦП, то можно отфильтровывать программно и первые каналы ТВ...
Вот тут то и вспомнилась очень сильно идея "пассивного" процессора. Который из десятков сумматоров складывает "цифровой контур" или "детекторный приёмник".
Я читал в журнале, как одни инженеры давали задачу разработать цифровую схему для распознавания нескольких сигналов (аккустических чтоли). Ща точно не помню, не хочу наврать. Но, как помню, получившиеся схемы ПЛИС могли распознавать речевые команды Go! и Stop! как бы... Может это "жёлтая" наука? Не в курсе...

Но, суть одна: "пассивным" кодом можно построить такие распознаватели словечек. Свист, хлопок, стук... Одна схема реагирует на один звук. А код лишь 100 раз в секунду меняет прошивку. Т.е. по очереди даёт управление то одной, то другой схеме.

Напоминает Multi Task! Не так ли?
Только вместо программ используются логические электронные узлы. А пассивный процессор лишь выполняет роль ядра.

Не знаю...

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

 

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

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

далее, в целевой микрухе узлы оптимизируются по нужным параметрам и соединяются металом (медью, алюминием), а в плис узлы составляются из мелких частей общего назначения, со средними параметрами. соединения иммитируются логическими элементами, управляемыми памятью с прошивкой. а это все задержки + большое сопротивление не позволяющее поднимать частоту (с одной стороны разогрев, а с другой Tпереключения = Rсоединения * Cзатвора. те, если емкость затвора 1пФ, а сопротивление соединения 1кОм, то предельная частота смены состояний этого затвора < 500МГц. и это только одного последовательного соединения. а у вас будет их там..)

плис != плм. те что юзались в синклерах были на выжигаемых перемычках. это вид пзу. быстродействие у них, как у куска провода

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

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

посему единомышленником вам быть пока не в чем. разве что в научной фантастике и попытках вытесать из дуба спичку

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

 

Извиняюсь. Просто здесь под ПЛМ я имел ввиду саму ПЛИС, но без контроллера, через который она прошивается.

А я и не прошу. Просто к примеру.
То, что компьютеру можно дать задачу, а он расчитает схему ПЛИС.
Сейчас имеются у Xilinx подобные штуки похожие. Трансляторы Java -> ПЛИС.

Брал. Скачал я эмулятор РЛК РАДИО-86РК и мне не понравилась там реализация ВГ75 и ПДП ВТ57. Т.е. на реальном РЛК "неверным" символом в видеопамяти можно было заставить скролить экран. И достаточно сильно!
А в эмуляторе - хоть бы хны.
Я написал свой эмулятор. Первыми функциями были i8257 и i8275. Добился-таки практически 100% адекватной работы. И экран можно было посадить по любому адресу, и растр любого формата сделать. Но...
разрабатывал и тестил всё это на Pentium-90mHz. И когда дело дошло до i8080A, там сильно споткнулся.
Во-первых, хотя все функции разового использования (инициализация ВГ75 и т.д.) были написаны на си, а их функциональные (рендеринг растра) - на _asm { ... }, включая и ядро ВМ80 (всё на ассемблере и адское в отладке), эмулятор не пошёл...
Да, десятки игр играло. И цвет был, и звук (fmod.dll). Но... Некоторые игры, как Krok и Цирк, запускались и висели, не реагируя на клавиши. Бейсики выполняли лишь CLS, PRINT же очень неверно выводил сложение, и вообще почти все операторы выдавали ошибку синтаксиса!
Выловить этот баг в сотнях строк i8080 я так и не смог
Во-вторых, эмуляция ВГ75 жрала много ресурсов (хотя всё в _asm) и всё пахало в 1.5-2 раза медленее реальной машины.
В-третьих, сделал как минимум три релиза на Си (не считая древний мой на Visual Basic 4). Но, хотя ядро процессора каждый раз писал с нуля, ни Цирк, ни Бейсики нигде не работают. Хотя ВМ80 я знаю практически наизусть!
Аж обидно! Экран хорошо эмулируется, а процессор - дерьмово.

Потом, в JavaScript я реализовывал свои идеи с ПЛМ. Почти все идеи процессоров (за исключением "пассивного") я реализовал. И даже на одном из процессоров BIOS свой игрушечный пытался сделать, но запарился с микрокодом. Чем проще команды, тем чудовищней осложняется программирование - это я понял вскоре.

А чем стеклянные ёжики не по душе? ))

Эльбарус обгонял Pentium, хотя и интеграция меньше, и лишь эмулировал Pentium. Отсюда я и сделал вывод, что если всё переводить на электронные узлы, вместо программных, будет на порядки быстрее!

Сам я в свои 19 прорабатывал схему однотактового умножения/деления двух 128-битных чисел. Вышел из-под карандаша МОНСТР из 200 миллионов транзисторов!!!
Я тупо подсчитал число транзисторов на сумматор, умножил на 128 бит, добавил схему мультиплексора (они нужны в деление) и дополнительного кода (сумматоры могли работать и как вычитатели для деления), и умножил на 128...
Схема работает без тактовой частоты. Просто подаёшь на входы числа N и M, а на выходе получаешь или произведение, или частное. Зависит от бита режима.
Но, 200 млн транзисторов! Такую схему ни за что не собрать дома. Да и пока данные по ним дойдут до выхода, пройдёт много сотен нс. А это хуже тактируемых схем...
А ведь на очереди была схема безтактового синуса и квадратного корня.......

 

_basmp_

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

Paguo_86PK

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

 

Мне кажется, что подобную задачу можно решить при помощи простой ПЗУ'шки на 4 МегаБайт (если я в подсчётах не ошибся).

 

Oooops! Ошибся, - "порядки" чисел попутал! :-(

 

Верно. были масочные ПЗУ РТ кажется с таблицами умножения и т.д...
Но, в любом случае и задержка, и интеграция такого множителя/делителя будет нешуточной...

А я просто занимался вариантом с чистой логикой. Вот и получил сотни миллионов.

 

логика двоичного умножения предельно проста - множимое сдвигается столько раз сколько в нём разрядов (эта операция делается параллельно и совсем не требует транзисторов - достаточно проводников), а затем складываются только те сдвиги которые соответсвуют 1 в множителе (для умножения сдвинутого множимого на 1 или 0 достаточно многовходовой схемы И или повторителя с возможностью выключения), например
101110101 * 11001 =
1 * 000000000101110101 +
0 * 000000001011101010 +
0 * 000000010111010100 +
1 * 000000101110101000 +
1 * 000001011101010000 +
0 * 000010111010100000 +
0 * 000101110101000000 +
0 * 001011101010000000 +
0 * 010111010100000000 +
0 * 101110101000000000
Суммировать лучше многоступенчато-параллельно ((D0+D1) + (D2+D3)) + ((D4+D5) + (D6+D7)) и т.д.
Реализовать это без тактирования вполне возможно, но при массовом производстве микросхем, имеющем технологический разброс параметров, любая многоступенчатая схема без тактирования проигрывает в стабильности (технологической повторяемости), а если применять специальные меры стабилизации в виде внутренних задержек с запасом на разброс, то можно и запросто проиграть по быстродействию тактированному варианту - поэтому он везде и используется.

 

Маленькая поправка - в самом умножителе ступеней схемы мало и тактирование внутри умножителя не требуется. Латентность умножения в 4 такта (на современных процессорах) скорее всего просто типовая задержка на стабилизацию многоступенчатого результата, а сам умножитель тактируется только на запуск операции. Результат может получиться и быстрее чем за 4 такта, но статистически полагаться на это нельзя, поэтому для стабильности время задержки и привязано к тактам.

 

А по Вашему логический элемент совсем не имеет транзисторов? О_о

Для справки:
Операции логических "И" и "ИЛИ" требуют как минимум 4 КМОП транзистора на бит;
Операция "ИСКЛЮЧАЮЩЕГО ИЛИ" требуют как минимум 8 КМОП транзисторов на бит;
Примитивный сумматор требует один элемент "И" для генерации бита переноса, и "ИСКЛЮЧАЮЩЕЕ ИЛИ". Итого - 12 CMOS транзисторов;
Полноценный сумматор со входом бита переноса без схемы ускоренного переноса (СУП) требует три элемента "И" (4*3=12 транз.), один элемент "3-ИЛИ" (6 транз), два "ИСКЛЮЧАЮЩЕЕ ИЛИ" (8*2=16 транз.). Итого - 34 транзистора на бит;

На 32 бита сумматора требуется 1088 транзисторов (без СУП). Для перемножения двух 32-разрядных слов потребуется 34816 транзисторов + ещё по 32 элемента "И" на каждый сумматор, чтобы обнулять ненужные биты - 4*32*32=4096 транзисторов. Итого - 38912 транзистора для безтактового перемножения двух 32-битных слов.
Вероятность получения на выходе верного результата получается 38912 * задержку одного транзистора. Если задержка транзистора не более 1нс, результат получится уже спустя 38.912мкс. Тем самым производительность будет составлять около 25699 операций умножения в секунду!!! Очень медлено!!!

Теперь вычислите, сколько транзисторов потребует универсальная схема умножения/деления?
На вскидку: Сумматоры должны уметь работать и как вычитатели. Для чего один операнд на вход нужно пропускать через логическое "НЕ", а также и с выхода сумматора результат пропускать через "НЕ". Тут подходят "ИСКЛЮЧАЮЩИЕ ИЛИ". Итого + 16 транзисторов на бит. Итого уже по 50 транзисторов на бит сумматора/субтрактора. Это раз!
Если при делении во время вычитания произошёл перенос, нужно восстановить вычитаемое. Понадобится мультиплексор. А это - 14 транзисторов на бит. Это два!
Три: Схема умножения/деления должна быть организована в обратном направлении. Так-как при делении вычитают со старших разрядов. Так:
Первый сумматор - на 32 бита.
Второй - на 33.
Третий - на 34 и т.д.
Чтобы все 32 сумматора охватывали вплоть до старшего бита!
Итого: n * (n + 1) / 2 = сумма всех шаров билльярдной пирамиды. Где n - число рядов.

Код (Text):

1.    O
2.   O O
3.  O O O
4. O O O O -> 4 * (4 + 1) / 2 = 4 * 5 / 2 = 10

Не сложно подсчитать теперь всю сумму транзисторов:
32 сумматора по 32 бита и по 50 транзисторов на бит = 51200;
У каждого очередного сумматора прибавляется по разряду. Если у первого - 32 бита, то у 32-го - уже 64 бита.
Пирамидой вычислим: 31 * 32 / 2 = 496 битов * 50 транзисторов = 24800.
Итого 51200 + 24800 = 76000 транзисторов для полноценного умножения двух 32-битных слов в одно 64-битное. Или для деления 64-битного числа на 32-битное.
И всё без тактов.
Подсчитаем производительность при 1нс на транзистор = 13157 операций в секунду! Очень медленно!!!

Но 1нс - это я грубо. Транзисторы же в тысячи раз быстрее. Это я для облегчения счёта.

А теперь все эти вычисления примените к моему 128-битному множителю/делителю. Перемножает для 128-битных в одно 256-битное. Или делит 256-битное на 128-битное...
В 90-ых, когда я и вычислял интеграцию этого устройства, получилось около 200 миллионов транзисторов!!!
Сомневаетесь? На досуге пересчитайте.

А Вы всё говорите

 

И кстати. Вот обоснование:

Код (Text):

1. Умножаем:
2.  
3. 101110101 * 11001 =
4. 0 * 101110101000000000 +
5. 0 * 010111010100000000 +
6. 0 * 001011101010000000 +
7. 0 * 000101110101000000 +
8. 0 * 000010111010100000 +
9. 1 * 000001011101010000 +
10. 1 * 000000101110101000 +
11. 0 * 000000010111010100 +
12. 0 * 000000001011101010 +
13. 1 * 000000000101110101 =
14.     000010010001101101
15.  
16. Тепер
17. разделим
18.  
19. 000010010001101101 / 11001 =
20. 000010010001101101 -
21. 110010000000000000 -> 0
22. 000010010001101101 -
23. 011001000000000000 -> 0
24. 000010010001101101 -
25. 001100100000000000 -> 0
26. 000010010001101101 -
27. 000110010000000000 -> 0
28. 000010010001101101 -
29. 000011001000000000 -> 0
30. 000010010001101101 -
31. 000001100100000000 -> 1
32. 000000101101101101 -
33. 000000110010000000 -> 0
34. 000000101101101101 -
35. 000000011001000000 -> 1
36. 000000010100101101 -
37. 000000001100100000 -> 1
38. 000000001000001101 -
39. 000000000110010000 -> 1
40. 000000000001111101 -
41. 000000000011001000 -> 0
42. 000000000001111101 -
43. 000000000001100100 -> 1
44. 000000000000011001 -
45. 000000000000110010 -> 0
46. 000000000000011001 -
47. 000000000000011001 -> 1
48.  
49. Как теперь видно, схему умножения лучше строить не по принципу
50.  373
51. x 25
52. ----
53. 1865 = 5 * 373 (умножаются единицы)
54. 746  = 2 * 373 (а теперь десятки)
55. ----
56. 9325
57.  
58. а в обратном направлении
59.  373
60. x 25
61. ----
62. 746  = 2 * 373 (сначала старшие: здесь - десятки)
63. 1865 = 5 * 373 (затем младшие: здесь единицы)
64. ----
65. 9325
66.  
67. или даже так:
68.   25
69. x373
70. ----
71. 75   = 3 * 25 (сотни сначала)
72. 175  = 7 * 25 (затем десятки)
73.   75 = 3 * 25 (единицы в конце)
74. ----
75. 9325

Я так умножать начал ещё в школе. Учителя хоть и сердились, но отметку ставить надо же по результату. А он был верным!

А потом я и схему умножителя/делителя так же и построил.

 

сдавал вчера предмет там надо было уметь написать примерно 130 разных схемных методов операции умножения

 

Paguo_86PK
Не выдёргивайте фразы в отрыве от контекста )

Далее:

Это если тупо пристраивать следующий сумматор в хвост предидущему то возможно да, а если соединить их древовидно (рис в аттаче - в дереве номера сумматоров для подсчёта их количества, в нижней строке счётчик слоёв), то задержка для 32 бит = 6 * задержку сумматора + задержка одного слоя элементов & производящих умножение на 0 или 1. Операция сдвига, как я уже подчёркивал "делается параллельно и совсем не требует транзисторов" и соответсвенно не вносит задержки )

А вот смешивать крыс и котлеты не стоит ) Операция деления не допускает древовидного распараллеливания операции вычитания, потому и тормозит на всех камушках по сравнению с умножением неимоверно

И главное по прежнему не понятно - каким боком это всё к пассивному процессору относится и в чём же всё-таки суть его "революционной" идеи?

SashaTalakin
Примеры в студию - желательно с полным сравнительным анализом достоинств и недостатков всех 130 )

 

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

 

Paguo_86PK
Кстати для умножения деревом при переходе к 64 и 128 битам количество транзисторов будет конечно х2 и х4, а вот количество слоёв определяющих задержку увеличиается всего на +1 и +2 слоя сумматоров )

SashaTalakin
Как и следовало предполагать ) - 95% из этих 130 вариантов не имеют практической полезности, а просто чтобы студенты "потренировались" )

 

Paguo_86PK

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

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

Y_Mur
выпуск переконфигурируемых раширений/портов, как определенный взгляд на открытую архитектуру, смысл имеет. и их выпускают под пси, пси-е. средняя минимальная цена ~$500-1000

 

Y_Mur

даже если там отдельные схемы для 1 разрядных, 2ух разрядных итд. это все равно очень много.
присоединяюсь к просьбе об освещении темы о 130 схемах. как минимум хороший пример, чтоб ссылить будет

Paguo_86PK
насчет умножителя, ради интереса попробуйте заимплементить ваш умножитель в вебпаке. интересно, сколько чего выйдет.

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

 

_basmp_

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

 

Я в #34 немного ошибся - для сложения 32х чисел в древовидном варианте достаточно 5, а не 6 слоёв суммирования, а количество сумматоров (а значит и транзисторов) необходимых для древовидного (а) и тупого последовательного (б) вариантов одинаково
Кроме того в обоих вариантах в некоторых разрядах некоторых сумматоров после сдвига всегда будут нули, соответсвенно там можно сэкономить транзисторы и выделение тепла, но в последовательном (б) варианте это можно сделать только в старших разрядах, поскольку младшие всегда заняты накопленным результатом, а в параллельном (а) и в младших и в старших разрядах, т.е. в итоге транзисторов нужно меньше

На рис.: жёлтые ячейки - складываемые числа (64х разрядные так как при умножении разрядность удваивается и происходит это как раз в операции сдвига), зелёные - сумматоры (складывают пары 64х разрядных чисел), синие - слои последоватльного суммирования.