Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Ага! А ты 68*** проц знаешь? Или PDP/Электроника-60? Вот, где коллекция способов адресации! 05.07.05 04:00 Число просмотров: 3518
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
в 68*** все регистры, кроме аккумулятора, если мне память не изменяет являются специальными, для реализации разных способов адресации. И очень удобно - для доступа ксложным структурам данных, особенно, в ДБ.
|
|
<theory>
|
Тут у народа за пивом мысль сформировалась: использование регистров в современных микропроцессорах это анахронизм? 01.07.05 11:48
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 01.07.05 11:49 Количество правок: 1
|
При современных размерах кэша не проще ли пользовать просто ссылки на память, и вообще исключить регистровые операции из набора инструкций?
И оптимизировать компиляцию под размеры кэша первого-второго уровней?
Или это пивной бред? ;-)
|
|
HP-PA 05.07.05 10:15
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 05.07.05 10:30 Количество правок: 1
|
Это уже было сделано в варианте когда вместо регистров есть верхушка стэка (стэковые процессоры). В "чистом виде" регистров остается три - PC, SP и флаги. Опционально вводятся псевдо-регистры, номер "регистра" как-бы определяет смещение от верхушки стэка.
Одна из наиболее удачных реализаций (насколько мне известно) - HP-PA, это RISC-процессор с отображением регистров на память. Часть виртуальных регистров (с меньшими номерами) на самом деле реальные, а процессор автоматически поддерживает когерентность. В последних моделях кажется используется переименование и фактически получается как-бы "регистровый кэш".
В результате это RISC с как-бы очень большим кол-вом регистров, но с "чемоданом батареек" в виде блока кеширования этих "регистров" и специфических трудностей при автоматической генерации оптимального кода. Одна из проблем - первоначальная (в циклах) трудно-отличимость для CPU "регистров", которые компилятор (или asm-программист) использует как счетчики/индексы от всего прочего. Фактически, для "регистров" необходимо вводить команды вида prefech и store-non-temporal/store-purge, а чтобы быть не хуже других - тоже самое и для не-регистровых данных (для косвенной адресации).
В итоге, как ни стараются компилятор и процессор, в целом получается хоть немного, но медленнее чем "классический" RISC с набором "обычных" регистров.
|
|
Мысля конечно интересная, но неприменимая на практике 02.07.05 13:13
Автор: amirul@home Статус: Незарегистрированный пользователь
|
> При современных размерах кэша не проще ли пользовать просто
> ссылки на память, и вообще исключить регистровые операции
> из набора инструкций?
И дело тут совсем не в размере и скорости кеша. А в размере инструкции. На код операции нам надо порядка 5 бит (естественно нужно выделить один код на расширение кода, а так 31 код на самые частые арифметико-логические команды и команду копирования/ветвления/перехода и пр должно хватить), на метод адресации (не заставлять же всех пользоваться непосредственной адресацией) - еще КАК МИНИМУМ 3 бита на каждый аргумент (будем считать, что результат операции ложится в первый аргумент). Ну и по 32 бита на каждый аргумент. Итого 10 байт на самую простую команду (что будет в 64-битной архитектуре даже подумать страшно). Только на то, чтобы эту команду считать и декодировать будет уходить туева хуча времени. Кроме этого такие команды будут не по детски засирать кеш команд и в несколько раз уменьшать его эффективность.
Стековая машина, как и машина тьюринга (которые вроде бы решают проблему с огромными аргументами) - очень удобный способ формализации алгоритмов, для математического исследования, но уж никак не для эффективной работы.
Короче, можешь считать регистровую память кешем нулевого уровня, для управления которым прогаммисту дана бОльшая свобода, чем в случае остальных кешей. На мой взгляд правильно развивается RISC - увеличение количества регистров (не помню, но уже в G3 их кажется было 256 - могу и ошибаться), что практически полностью избавляет программиста от необходимости частого обращения к памяти: все текущие данные закачиваются в кеш (нулевого уровня), там идет обработка (следует отметить, что для адресации любого элемента этой памяти нужно всего 8 бит) - после обработки результат выгружается обратно в память
|
|
Всегда для доступа к регистру требуется меньше такта процессора. Для доступа к памяти при наилучшем раскладе - 1, чаще - больше. Кроме того, при работе с регистрами за один такт могут выполняться несколько команд одновременно, а с памятью - нет. 01.07.05 15:50
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
|
Даёши переименование адресов памяти 01.07.05 13:09
Автор: Serge3leo Статус: Незарегистрированный пользователь
|
> При современных размерах кэша не проще ли пользовать просто
> ссылки на память, и вообще исключить регистровые операции
> из набора инструкций?
А что, есть такое направление - стековые машины. Однако доступ к регистрам несколько быстрее доступа к кэш памяти.
|
| |
Кэш первого уровня работает на частоте проца. Предположим, он равен 16 килобайтам. Это всё равно, что массив 32-разрядных регистров из 4096 элементов. Нет? 01.07.05 14:26
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | |
Для начала следует заметить, что регистры - это логические... 03.07.05 12:55
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 03.07.05 12:59 Количество правок: 2
|
Для начала следует заметить, что регистры - это логические устройства. Самое элементрарное из них - регистр хранения, он по сути похож на одну ячейку памяти. Чуть более сложные регистры - счетчики, сумматоры, регистры сдвига... Они, кроме того как могут просто хранить данные как оперативка, еще могут выполнять определенные действия. Нельзя же реализовать процессор без регистров.
Эта мысль могла прийти в голову не после пива, а после того как программист пересел программировать на 80386 процессор после 80286. Там (на 386) можно писать "cmp var1, var2", в отличии от 286, где это действие должно быть представлено двумя инструкциями "mov ax, var1" и "cmp ax, var2". Хуже дело будет обстоять с "add var1, var2". Здесь потребуется три инструкции "mov ax, var1", "add ax, var2" и "mov var1, ax". Причем на еще более старых процессорах кроме как ax (аккумулятором) никаким другим регистором и пользоваться нельзя было.
Вся беда в том, что современный процессор, выполняя инструкцию "add var1, var2" все равно загрузит в свой сумматор первый операнд, в другой регистр загрузит второй операнд, сложит и запишет результат в первый операнд. Этого не произойдет, если операндами будут регистры. Даже предположив, что на инкрементирование счетчика инструкций, извлечение и вычисление адресов операндов времени не тратится, регистровая операция может выполнится за один такт, что не произойдет при работе с памятью, поскольку хоть по одному такту на выборку из кэша и запись в кэш потратить придется.
"Оптимизировать под размер кэша" какого процессора? Программа должна прекрасно работать на любом процессоре, и на П-4 и на Целероне. Да и у П4 тоже разные объемы кэша могут встречаться. Это чтож получится - написали программу под П-4ЕЕ и работать она будет только у счастливых олигархов - обладателей соотв. процессора.
Если кэша 1 Мег - адресацию использовать 20 разрядную или округлить до 32? А если 2 мега - 21 разряд?
А как быть с переключением процессов на многозадачных ОС? Много раз в секунду кэш туда-сюда трансферить? И как это делать?
|
| | | |
Можно по другому. 04.07.05 12:37
Автор: Den <Денис Т.> Статус: The Elderman
|
Выделяем место в кеше на 64 регистра размерностью 64бит. На адресацию каждого из 64 регистров требуется 6 бит + 2 бита режима адресации, к примеру:
00 - QWORD
01 - LOW DWORD
10 - LOW WORD
11 - LOW BYTE
Итого 8 бит на адрессацию 64-х регистров общего назнчения -512байт кеша. По-моему такого кол-ва регистров за глаза и за уши.
|
|
Если использовать часть кеша как набор регистров, то можно попробовать согласиться. 01.07.05 12:44
Автор: Den <Денис Т.> Статус: The Elderman
|
> При современных размерах кэша не проще ли пользовать просто
> ссылки на память, и вообще исключить регистровые операции
> из набора инструкций?
Думаю, не проще. Регистровые операции все-таки намного быстрее, чем операции с памятью через кеш.
Я склонен считать анахронизмом мнемоническое именование регистров в компиляторах под x86.
> И оптимизировать компиляцию под размеры кэша
> первого-второго уровней?
Это не просто...
По сути получатся почти регистровые операции, но более трудозатратные для самого проца. Придеться интерпретировать каждую команду намного раньше выполнения и до выполнения успевать скешировать необходимые данные, к которым обращается команда и ко всему прочему где-то хранить информацию о привязке места кеша данных к конкретной операции.
>
> Или это пивной бред? ;-)
|
| |
не всеже регистры пока быстрее :) 01.07.05 14:16
Автор: vaborg <Israel Vaborg> Статус: Elderman
|
но оптимизацию ИМХО надо вест не в сторону
компилятора а чтобы программы(модули) умещались
в кеши. Тем более что мне кажется размера кеша
увеличивается с каждым годом так что через лет 5 он будет сопоставим
с оперативной памятью.
|
| | |
Регистры имеют спец. назначение 04.07.05 04:24
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
Аккумулятор, 2-го операнда, базовый, индексный и т.п. даже, если они и являются оп сути универсальными, как EBX, ECX, все равно, каждый обычно используется для какой-то одной цели, преимущественно, для ускорения адресации.
|
| | | |
ИМХО, это тоже анахронизм за некоторым исключением. 04.07.05 12:28
Автор: Den <Денис Т.> Статус: The Elderman
|
|
за исключением сегментных регистров, регистров SP, BP, регистра указателя инструкции и тому подобных.
|
| | | | |
Ага! А ты 68*** проц знаешь? Или PDP/Электроника-60? Вот, где коллекция способов адресации! 05.07.05 04:00
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
в 68*** все регистры, кроме аккумулятора, если мне память не изменяет являются специальными, для реализации разных способов адресации. И очень удобно - для доступа ксложным структурам данных, особенно, в ДБ.
|
| | | | | |
8 адресных регистров и 8 регистров данных 05.07.05 16:47
Автор: amirul <Serge> Статус: The Elderman
|
> в 68*** все регистры, кроме аккумулятора, если мне память
Аккумулятора нет. Все регистры данных могут участвовать во всех АЛУ-шных операциях.
Все адресные регистры тоже могут участвовать во всех способах адресации (в том числе и постинкрементные и предекрементные - те, которые используются для реализации стека). Правда один адресный (a7) регистр таки отличается от других: во первых при вызове подпрограмм именно он используется в качестве стека для сохранения адреса возврата (для всех остальных стековых операций вполне можно пользоваться любыми другими адресными регистрами) и во-вторых он имеет копию (a7') - для супервайзорского режима (то есть адресных регистров на самом деле 9, но пара a7-a7' никогда не может быть впечатана одновременно: есть отдельная команда для ручной смены стеков и стеки меняются сами при переходах юзер<->супервайзер)
> не изменяет являются специальными, для реализации разных
> способов адресации. И очень удобно - для доступа ксложным
> структурам данных, особенно, в ДБ.
Вообще 680x0 для меня до сих пор остаются идеалом CISC процессоров. И не только по системе команд. MMU, система прерываний и вообще все там просто мечта идиота.
|
| | | | | | |
Угу, регистров должно быть достаточно много и все они должны быть РОН (регистрами общего назначения). И видов адресаций тоже куча (непосредственные, индексные, косвенные, относительно/абсолютные, инкрементно/декриментные, ...). 05.07.05 19:02
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 05.07.05 19:04 Количество правок: 1
|
|
|
| | | | | | | |
В 68020 было 18 методов адресации насколько я помню 06.07.05 12:45
Автор: amirul <Serge> Статус: The Elderman
|
|
Но вообще CISC удобна скорее для человека, чем для машины, а человек уже практически давно не имеет дела с ассемблером. Как по мне - будущее за RISC-ами (а там глядишь и их что нибудь вытеснит). Хотя бы тот факт, что RISC-и с довольно небольшими потерями эмулируют CISC-и, а CISC-и при эмуляции RISC-ов тормозят безбожно, говорит сам за себя.
|
| | | | | | | | |
Была у меня идея - МИСК-мультипроцессор 07.07.05 06:30
Автор: Zef <Alloo Zef> Статус: Elderman
Отредактировано 07.07.05 06:32 Количество правок: 1
|
(Minimal Instruction Set) Году в 94-м, еще до массового появления в России 386-х. Суть: несколько (4/8/16) одинаковых АЛУ с регистром на выходе, соединенных по принципу "каждый с каждым - одновременно" (т.е. каждое РАЛУ может передавать предыдущий результат другому одновременно с выполнением текущей операции) на одном кристалле. Операций с памятью - нет, в место них команды: "передать в шину адреса", "читать/писать в шину данных". Шина команд со своей шиной адресов отдельно от шины адресов/данных для операндов. Ширина команды постоянная и пропорциональна числу РАЛУ. Собсно, она и состоит из 4/8/16 команд для каждого из них. Набор команд РАЛУ абсолютно минимален (И, ИЛИ, НЕ, +, -, сдвиг с переносом /без, пересылка).
Такая фигня может исполнять за один такт столько операций, сколько в ней РАЛУ. При этом имеет минимальное количество вентилей на кристалле и может быть реализована по какой-нить серхбыстродействующей (GaAs, сверхпроводники и т.п.) технологии с малой степенью интеграции.
Программирование целесообразно сделать двухуровневым: на шину команд посадить интерпретер Java-кода, который читать с шины данных.
|
| | | | | | | | | |
примерно так работают исполнительнные ядра u-ops 07.07.05 13:00
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 07.07.05 13:01 Количество правок: 1
|
Примерно так работают исполнительные ядра u-ops, например в P4. Но в чистом виде МИСК (если разобраться) ничего не дает.
Есть оптимальное соотношение между кол-ом регистров CPU, кол-вом АЛУ-команд на такт и скоростью обмена с RAM. Для разных задач это соотношение (пропорция) сильно отличается. Если немножко посидеть с карандашом, то легко увидеть, что "тощий" МИСК (мало регистров и АЛУ) грузит шину, но мало что делает. "Толстый" МИСК может очень много, но реально его сложно нагрузить (если счетчик команд один). Получается, что из абстрактного МИСК выходит три варианта:
1) "Тощий" вариант - что-то похожее на микроконтроллер или PIC;
2) "Толстый" вариант - что-то похожее на Cray c его V-цепочками регистров или специализированный "числогрыз", например GPU;
3) "Средний" вариант, 2-4 АЛУ и в два-четыре раза больше регистров;
Далее, длина МИСК-команды непосредственно зависит от кол-ва регистров, самих АЛУ и АЛУ-операций. Причем запись/чтение данных - две команды (получить адрес и произвести обмен). Если еще раз взять карандаш, то будет видно, что трафик команд (для большинства задач) превышает трафик данных. И в результате (если нужен не специализированный, а "универсальный" процессор) придется делать блок декодирования команд, МИСК в "чистом виде" на этом кончиться.
|
| | | | | | | | | |
Раскритикую! 07.07.05 11:31
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 07.07.05 11:32 Количество правок: 1
|
Раскритикую!
Несколько АЛУ - больше размер всего кристала, больше тепловыделение, результат нулевой.
Допустим нужно посчитать 2+2*2. Два АЛУ в каскаде, в каждое загоняем по 2 по шине данных и операции умножения и сложения по командам. Первое АЛУ выдас 4 не менее, чем за 1 такт. Что будет складывать с двойкой второе АЛУ? "Мусор". Хорошо, если умножение будет выполнено без микрокода, да еще за 1 такт.
Сколько АЛУ в каскаде, столько и тактов на столько операций. Синхроимпульсы на каждый (необязательно), но разрешение на выполнение (готовность данных на выходе предыдущего) должно идти от предыдущего к последующему. Ну и зачем тогда много АЛУ, если и одно будет команды за один такт выполнять.
> Такая фигня может исполнять за один такт столько операций,
> сколько в ней РАЛУ. При этом имеет минимальное количество
> вентилей на кристалле и может быть реализована по
> какой-нить серхбыстродействующей (GaAs, сверхпроводники и
> т.п.) технологии с малой степенью интеграции.
>
> Программирование целесообразно сделать двухуровневым: на
> шину команд посадить интерпретер Java-кода, который читать
> с шины данных.
|
| | | | | | | | | | |
Сударь, вы заблуждаетесь ; в современных процессорах за один такт могут исполняться несколько операций паралельно. RTFM, plz. example: I586-- mov eax, ebx; mov edx, ecx == 1 такт. 07.07.05 18:10
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 07.07.05 18:11 Количество правок: 1
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
