информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsПортрет посетителяЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hardware
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
RISC заглох, потому что люди предпочитают эволюцинный метод развития революционному 04.10.06 21:16  Число просмотров: 3223
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> В общем, истина где-то рядом. Но побеждают пока
> суперскаляры с CISC, с огромными кэшами, с "предсказанием"
> ветвлений и всякими другими ухищрениями и костылями.

Предсказать ветвления для RISC-овых инструкций гораздо проще, потому что сами инструкции проще, огромный кэш никто не мешает сделать и на RISC, а длиннющие конвейеры - это фактически разбирание одной CISC инструкции на кучу мелких RISC субинструкций (в первом приближении, потому как сами RISC инструкции тоже можно запихать в конвейер, хотя он и будет значительно короче CISC-ового). RISC вряд ли победит просто потому, что ОЧЕНЬ трудно преодолевать инерцию.
<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
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach