Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
:) И плюс еще пара миллионов ранзисторов... 04.10.06 12:58 Число просмотров: 2900
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
|
<hardware>
|
Почему бы разработчикам процессоров не модифицировать чуть-чуть набор инструкций до криптографического? 04.10.06 11:33
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 04.10.06 11:35 Количество правок: 1
|
Может этот набор еще где-нибудь мог бы пригодиться, хотя я и представить не могу область, где нужно будет оперировать не менее чем 64 разрядными целыми числами.
Модификация простая. Нужно ввести расширенные инструкции ADD, SUB, MUL, DIV. CMP и MOV скорее всего не потребуется, поскольку есть что-то аналогичное "строковое". Этим инструкциям добавляется еще один операнд, определяющий разрядность других операндов, в байтах например. Этот операнд можно сделать даже константой в самой инструкции или регистр, остальные - адрес непосредственный или в регистре. Сама операция элементарно реализуется на микрокоде, как и большинство других.
Преимущества - простота кодирования, компактность кода, отсутствие ошибок программиста при реализации "длинной" арифметики, скорость однозначно будет выше. Причем в зависимости от процессора, точнее разрядности его регистров 32 или 64 будет отличаться и микрокод, и, естественно, скорость. При программной реализации нужно продетектить разрядность (по типу проца) и вызывать нужные функции в зависимости от этого. То есть несколько функций в зависимости от разрядности, плюс накладные расходы на вызов и передачу параметров.
В результате компактный код будет платформонезависимый. Крипрография сейчас используется уже везде, так что, думается, вещь будет полезная.
Как считаете - взоможно ли это, будет ли реализовано, если нет, то почему?
|
|
Хм, или я что-то не догоняю, или приемлимое решение уже давно существует в виде MMX, SSE... 04.10.06 13:16
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
|
Потому что есть грани... 04.10.06 13:04
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 04.10.06 13:05 Количество правок: 1
|
А потом ещё чего-нить включить в процессор... А потом ещё чего-нить...
А потом в нём оказывается куча ненужного хлама, оставленному там "для совместимости". ASC-преобразования, к примеру -))
Это не выход. ИМХО, нужно пользоваться нормальными библиотеками, открывать архитектуру процессора, и давать возможность программисту самому решать, что реализовывать своим собственным микрокодом, если его не устраивают стандартные инструкции процессора.
И вообще, за процессорами с изменяемым набором инструкций большое будущее ;-)
|
| |
Дык ведь включают. Счетчики, уникальные номера, генераторы... 05.10.06 12:57
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 05.10.06 12:59 Количество правок: 2
|
> А потом ещё чего-нить включить в процессор... А потом ещё
> чего-нить...
Дык ведь включают. Счетчики, уникальные номера, генераторы ПСЧ, а SSE уже до четвертого расширения добралось.
> А потом в нём оказывается куча ненужного хлама,
> оставленному там "для совместимости". ASC-преобразования, к
> примеру -))
Это слишком сложная и больная тема. Отказаться от старых инструкций, заменить новыми, полностью поменять уже слишком сложную кодировку...
> Это не выход. ИМХО, нужно пользоваться нормальными
> библиотеками, открывать архитектуру процессора, и давать
> возможность программисту самому решать, что реализовывать
> своим собственным микрокодом, если его не устраивают
> стандартные инструкции процессора.
Вот это интересно! Только возможно ли такое - чтоб интел описал как можно подгружать/модифицировать микрокод, чтоб самому написать или воспользоваться готовой библиотечкой. БИОС однозначно при ПОСТе умеет грузить в проц микрокод. Теоретически никаких паролей не нужно, но что-то наверняка запретит это сделать. Может даже сама ОС. Трудно себе представить, что в много задачной ОС одно из приложений модифицировало несколько инструкций. А что будет если другое приложение попользуется одной из них? Его работа будет непредсказуемой. Или каждый раз при переключении контекстов ОС будет переподгружать микрокод :-).
> И вообще, за процессорами с изменяемым набором инструкций
> большое будущее ;-)
Только как это будет реализовано?
|
| |
Немного офтоп 04.10.06 15:18
Автор: amirul <Serge> Статус: The Elderman
|
> И вообще, за процессорами с изменяемым набором инструкций
> большое будущее ;-)
Насколько я понимаю, "процессоры с изменяемым набором инструкций" это обычное RISC-ядро + эмулятор системы команд на микрокоде (фактически RISC маш. коде). Я вот тоже думаю, что RISC когда нибудь победит, ан что то не выходит у него.
|
| | |
RISC заглох, потому что обычные процессоры оказались эффективней в производительности. 04.10.06 19:05
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 04.10.06 19:08 Количество правок: 1
|
Инструкция в процессоре -- это то что он "умеет" делать, и "сложная" команда выполнит больше элементарных действий прямо в процессоре, там где это происходит быстрее всего. Инструкция -- это "язык" процессора, но язык мёртвый, процессор не обучается элементарным действиям/понятиям, в отличие от людей, которые эффектно применяют местоимения и междометия в своём общении. Помните начало практически любого разговора? "Прикинь", "Представляешь", и проч., в котором мозг предварительно программируется для "представления" ситуации, даются этим новым конструкциям имена ("И вот, этот козёл! ... и т.д ;-)), и дальше общение протекает приятно и ненапряжно с активным использованием местоимений и междометий -))
То же самое делает и программист, "обучая" компьютер предметной области, тупо пишет элементарные функции, бьётся с флагами и счётчиками, но потом, когда создаётся библиотека, пишется дальше легко и приятно... Процессор прекрасно всё исполняет, но вызов далёкой функции это для него шок... С кешем всякие нехорошие вещи происходят... Смена контекста при появлении прерывания это вообще катастрофа, как у Мандельштама "И в висок, ударяет мне вырванный с мясом звонок" -))
В общем, истина где-то рядом. Но побеждают пока суперскаляры с CISC, с огромными кэшами, с "предсказанием" ветвлений и всякими другими ухищрениями и костылями.
|
| | | |
RISC заглох, потому что люди предпочитают эволюцинный метод развития революционному 04.10.06 21:16
Автор: amirul <Serge> Статус: The Elderman
|
> В общем, истина где-то рядом. Но побеждают пока
> суперскаляры с CISC, с огромными кэшами, с "предсказанием"
> ветвлений и всякими другими ухищрениями и костылями.
Предсказать ветвления для RISC-овых инструкций гораздо проще, потому что сами инструкции проще, огромный кэш никто не мешает сделать и на RISC, а длиннющие конвейеры - это фактически разбирание одной CISC инструкции на кучу мелких RISC субинструкций (в первом приближении, потому как сами RISC инструкции тоже можно запихать в конвейер, хотя он и будет значительно короче CISC-ового). RISC вряд ли победит просто потому, что ОЧЕНЬ трудно преодолевать инерцию.
|
| | | | |
Кто сказал, что RISC заглох? 8-0 05.10.06 12:16
Автор: Den <Денис Т.> Статус: The Elderman
|
|
У интелей, начиная то ли с первых, то ли со вторых пней по жизни идет RISC ядро с CISC обвязкой вокруг.
|
| | | | | |
Я тоже это слышал, только про АМД. Вроде как даже в К6 было... 05.10.06 12:31
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> У интелей, начиная то ли с первых, то ли со вторых пней по
> жизни идет RISC ядро с CISC обвязкой вокруг.
Я тоже это слышал, только про АМД. Вроде как даже в К6 было 6 РИСКов, а в Атлонах до 9 увеличили. В принципе это оптимум для умножения 32 разрядных чисел.
|
| | | | |
IMHO всё проще - законы рынка, а не технология или социум 04.10.06 22:57
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Intel делал фиговые, но очень дешевые процессоры, поэтому их и покупали.
Больше систем с этим CPU - больше софта, больше спроса на процессоры. Больше тираж - больше прибыль, больше вложения в развитие/разработку и захват рынка. И так по-кругу...
VAX пот тоже был CISC, но слишком дорогой, и где он теперь...
x86 "всех сделал" не потому что он CISC, а потому что он очень хорошо продаётся и соответственно развивается.
|
| | | | | |
Да что говорить, сама Intel "промахнулась" с Itanium'ами. По крайней мере, очень сложно продвигается... 05.10.06 08:58
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | | | | | |
Погрязли в менталитетах, консерватизме потребителя и массе ПО для x86 05.10.06 12:17
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
|
:) И плюс еще пара миллионов ранзисторов... 04.10.06 12:58
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
