Разное.
Отличная штука - эти морские коктейли. Пожарил с лучком и умял с хлебом. ;)
На работе приключилась неприятность. Началась она с теста dhrystone, который не ассемблировался, а окончательно оформилась вот здесь, на второй, третьей и четвертой ссылке.
По дороге домой вот, что подумалось.
Сперва - про умножители.
Самый простой вариант умножителя - столбиком. Берём трехвходовой сумматор (входы x,y и incarry) с двумя выходами (sum и outcarry) и собираем их в линеечку. На x подаем биты множимого a[i], логически умноженные (AND) на b[j], на y - разряды частично накапленной суммы, на incarry - переносы (outcarry) из предыдущих разрядов накопленной суммы.
Как-то вот так:
a a a a
* * * * b
+ + + +
|\ a |\ a |\ a |\ a
| \ * | \ * | \ * | \ * b
| \|/ \|/ \|/ \|
| + + + +
| |\ a |\ a |\ a |\ a
| | \ * | \ * | \ * | \ * b
| | \|/ \|/ \|/ \|
| | + + + +
| | |\ a |\ a |\ a |\ a
| | | \ * | \ * | \ * | \ * b
| | | \|/ \|/ \|/ \|
| | | + + + +
| | | | с у м м а т о р
| | | | | | | \
s s s s s s s s
0 1 2 3 4 5 6 7Где у символа + два входа - это всё равно трехвходовой сумматор, только один из входов посажен на 0. "с у м м а т о р" - это обычный сумматор с групповым переносом, стандартная схема, в нашем случае - 4 бита + 4 бита. Для нормальных процессоров это, соответственно, не 4, а 32 бита.
Получается, что самые младшие биты мы можем получить быстрее, чем полный результат, примерно на такт процессора.
Это наталкивает на мысль использовать один и тот же умножитель в двух вариантах - быстром и полном. Однако если мы будем писать в регистровый файл, то нам надо будет провести три шины - 2 для полного и одну для быстрого, - поскольку быстрый вариант заканчивается быстрее, он может прийти одновременно с результатом полного варианта, что создаёт конфликт по выходу и самый простой путь его разрешения - это использование разных линий для разных результатов.
В случае TTA архитектуры мы тоже нуждаемся в трех шинах, но не в регистровый файл - что уменьшает его сложность. А алгоритмы раздачи инструкция в TTA, судя по рекламе, справляются с наличием в одному функциональном узле нескольких устройств с разной задержкой.
Кстати. Если я всё правильно понимаю, площадь регистрового файла растёт, как B*N*(Ww+Wr)2, B - ширина регистра в битах, N - количество регистров, Wr и Ww - количество шин чтения и записи. Из-за этого трудно построить VLIW, поскольку там каждая команда должна читать и писать в RF. Из-за этого тоже, если точно. ;)
И ещё кстати - с другими типами умножителей это может и не пройти. Например, есть более эффективная схема для умножения чисел со знаком, но она начинает суммировать со старших разрядов множителя b, и поэтому бесполезна. Забавный пример, как что-то неэффективное может оказаться полезным. ;)
На работе приключилась неприятность. Началась она с теста dhrystone, который не ассемблировался, а окончательно оформилась вот здесь, на второй, третьей и четвертой ссылке.
По дороге домой вот, что подумалось.
Сперва - про умножители.
Самый простой вариант умножителя - столбиком. Берём трехвходовой сумматор (входы x,y и incarry) с двумя выходами (sum и outcarry) и собираем их в линеечку. На x подаем биты множимого a[i], логически умноженные (AND) на b[j], на y - разряды частично накапленной суммы, на incarry - переносы (outcarry) из предыдущих разрядов накопленной суммы.
Как-то вот так:
a a a a
* * * * b
+ + + +
|\ a |\ a |\ a |\ a
| \ * | \ * | \ * | \ * b
| \|/ \|/ \|/ \|
| + + + +
| |\ a |\ a |\ a |\ a
| | \ * | \ * | \ * | \ * b
| | \|/ \|/ \|/ \|
| | + + + +
| | |\ a |\ a |\ a |\ a
| | | \ * | \ * | \ * | \ * b
| | | \|/ \|/ \|/ \|
| | | + + + +
| | | | с у м м а т о р
| | | | | | | \
s s s s s s s s
0 1 2 3 4 5 6 7Где у символа + два входа - это всё равно трехвходовой сумматор, только один из входов посажен на 0. "с у м м а т о р" - это обычный сумматор с групповым переносом, стандартная схема, в нашем случае - 4 бита + 4 бита. Для нормальных процессоров это, соответственно, не 4, а 32 бита.
Получается, что самые младшие биты мы можем получить быстрее, чем полный результат, примерно на такт процессора.
Это наталкивает на мысль использовать один и тот же умножитель в двух вариантах - быстром и полном. Однако если мы будем писать в регистровый файл, то нам надо будет провести три шины - 2 для полного и одну для быстрого, - поскольку быстрый вариант заканчивается быстрее, он может прийти одновременно с результатом полного варианта, что создаёт конфликт по выходу и самый простой путь его разрешения - это использование разных линий для разных результатов.
В случае TTA архитектуры мы тоже нуждаемся в трех шинах, но не в регистровый файл - что уменьшает его сложность. А алгоритмы раздачи инструкция в TTA, судя по рекламе, справляются с наличием в одному функциональном узле нескольких устройств с разной задержкой.
Кстати. Если я всё правильно понимаю, площадь регистрового файла растёт, как B*N*(Ww+Wr)2, B - ширина регистра в битах, N - количество регистров, Wr и Ww - количество шин чтения и записи. Из-за этого трудно построить VLIW, поскольку там каждая команда должна читать и писать в RF. Из-за этого тоже, если точно. ;)
И ещё кстати - с другими типами умножителей это может и не пройти. Например, есть более эффективная схема для умножения чисел со знаком, но она начинает суммировать со старших разрядов множителя b, и поэтому бесполезна. Забавный пример, как что-то неэффективное может оказаться полезным. ;)