Придумай инструкцию x86!

alpet

Ну это другое дело, раз rsel заранее знает с каким регистром работать. Только я не понял какой моп должен проверять условие и устанавливать тег (и куда кстати) - сам rsel или еще один спец-моп после test ?

И еще остается вопрос с ретайрментом регистров RF[23],RF[24] - вроде как это обычные инструкции и мы имеем право например поставить на них брикпойнт в отладчике, а нам проц вместо вектора покажет значение eax на предыдущей операции

 

leo

rsel - специальный моп, по идее генерится после инструкции с префиксом условного выполнения, но должен вымещатся до тех пор пока не потребуется результат. В данном случае он попадает в трассу команды "mov [edi], eax". Как инвариант - моп (или даже не совсем моп) всегда присутствует во всех не сдвоенных инструкциях, но имхо это замедлит процесс выполнения кода. Тег выставляется, в идеале сразу после сравнения - не зависимо от этого мопа.



Насчет отладки я не подумал. Если сделать rsel как явную инструкцию - все будет просто, при отладке будет всегда видно явное значение, до ее выполнения. Альтернатива - оставить rsel скрытым мопом, но обрабатывать перед вызовом обработчиков прерываний int 1, int3 и исключения GP# || PF# принудительным выполнением rsel (или вообще любого аппаратного прерывания). Судя по всему - второе будет единственно оптимальным вариантом.

 

[шепотом, тихо смываясь]пойду ка я отсюда...[/шепотом, тихо смываясь]

 

[шепотом, шоб модераторы не услышали]semen, куда ты, неужели о смысле жизни рассуждать или о физических парадоксах и софизмах...[/шепотом, шоб модераторы не услышали]

[andante, moderato]Ёшкин кот, куды мир катицца[/грозный взгляд в сторону миравога имперализма]

 

[огляделся, почесал затылок, и пошел дальше отсыпаться]

 

Понадобилась инструкция двухнаправленного сдвига. Вот описание ее:

shft r8-r64/m8-m64, const r8/imm8

В отличии от традиционных сдвигов - направление определяется по знаку счетчика - в случае отрицательных чисел сдвиг выполняется вправо, иначе влево.



Расширение операции - маскировка и сдвиг, удобна для работы с битовыми полями, для извлечения нужных битов:

mskshft r8-r64/m8-m64, const r8-r64, const r8/imm8

Алгоритм:

and param1, param2

<font color="blue]#if param3 > 0</font><!--color-->

shl param1, param3

<font color="blue]#else</font><!--color-->

shr param1, param3

<font color="blue]#eif</font><!--color-->

 

В "Компьютерре" от 11.10.2005 (#609) была опубликована неплохая статья об архитектуре современных камней. Как оказалось условные инструкции, и параллельное выполнение разных веток(инвариантов) кода, уже реализовано соответственно в ARM и Itanium. Видимо смысл прорабатывать это направление имеется.

 

Оказывается большая часть идей уже давно реализованна в разном железе - например два стековых указателя используются в Motorola 6809. Что мешало пойти по этому пути Интел в создании x86 - непонятно...

Вот только с длинными регистрами пока еще не связывался, во всяком случае упоминания о таких архитектурах я не нашел. Наверно когда количество ядер на процессор станет слишком большим, начнут искать возможности использования их избыточной производительности.

 

Меня давно мучает вопрос: присутствует ли в современных процессорах секретная инструкция, сжикающая процессор?

 

Folk Acid, естетсвенно да.

Её код 90h

 

Folk Acid

В процессорах врядли, но иногда сжечь их позвляет чипсет - достаточно выставить частоту и напряжения ядра по максимуму, и загрузить процессор на 100%. Если кулер слабый и аппаратной защиты от перегрева нет, скорее всего проц выйдет из строя попутно расплавив сокет.

 

alpet

Чаго мудрить ACPI изучаешь и будет тебе Армагедец, безо всякой нагрузки!

 

Было бы неплохо ввести условный префикс (как lock repz, repnz) ecc - Execute if cc!

 

3ahyga

Это активно обсуждалось на большей части топа. Специалисты в каменных делах решили что не очень-то это надо. Вобщем вооплощение такой функциональности может быть интересно только для программистов - на уровне железо оно ничего особо неоптимизирует. Хотя по идее - было бы неплохо иметь функцию условного вызова, поскольку в доработке это не особенно сложно, а код позволит писать несколько более компактный.

 

Старая тема, но интересная... поднимем

яб добавил в mmx нечто вроде psrl[w,d,q], psll[w,d,q], только что бы источник влиял не на все, а по отдельности...

hzpsllw 0003000300030003h, 0004000300020001 ;= 00300018000C0006h
hzpsrld 1010101010101010h, 0000000300000006 ;= 0001010100000001h

 

У... Два годика прошло...

Когда в процессорах уже будет поддержка регулярки!?
В x86-ых ввели допотопные XLAT REPcc SCAS STOS CMPS LODS и всё ещё при царе горохе.
Ни ассициативных массивов не поддерживается, ничего. Чем всякие MMX/3DNow! регулярки куда важней на серверах и в переводчиках.

 

Более жирного троллинга я ещё не видел.

 

"Совершенство достигается, не тогда, когда нечего добавить, а когда нечего убрать"

 

А кто говорит о совершенстве?
Эволюция !== Совершенство

 

Это смотря в каком направлении "эволюция"