информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetЗа кого нас держат?Портрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hardware
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Немного офтоп 04.10.06 15:18  Число просмотров: 2704
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> И вообще, за процессорами с изменяемым набором инструкций
> большое будущее ;-)
Насколько я понимаю, "процессоры с изменяемым набором инструкций" это обычное RISC-ядро + эмулятор системы команд на микрокоде (фактически RISC маш. коде). Я вот тоже думаю, что 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 <Denis> Статус: 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 <Denis> Статус: The Elderman
<"чистая" ссылка>
:) И плюс еще пара миллионов ранзисторов... 04.10.06 12:58  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
1






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


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