>> Дык и вопроса никакого не было. И "умеют кодить" это тоже не вопрос.
> полагаю, те кому он адресован - вопрос бы увидели.Полагать то можно, а что бы утверждать, необходим опыт успешного поиска.
> Если бы в принципе существовали в природе,
Недавно искал исходники Magic Divider и нашёл в ЖЖ Свина (он сам себя так называет). https://the-svin.livejournal.com/43593.html
Тот самый The Svin, кто прочёл первую книжку Криски (упокой Господи его душу) Касперски и п̶о̶с̶о̶в̶е̶т̶о̶в̶а̶л̶ ̶т̶о̶м̶у̶ ̶п̶и̶с̶а̶т̶ь̶ ̶д̶а̶м̶с̶к̶и̶е̶ ̶р̶о̶м̶а̶н̶ы выкатил несколько страниц исправлений по поводу поля Mod/RM в опкодах IA-32 (Криска в переиздание книжки материал скопи-пастил, но про Свина почему-то в благодарностях забыл, за что собственно его и называют -- Крыськой). Не знаю, как Свин относится к ARM и Linux, и вообще он не кодер. Мыслит не на уровне мнемоник, а битовыми полями опкодов. Ну и запросто может сочинить любую главу из Генри С. Уоррена младшего. Если я умею что-то сверх мигания пикселями на экране Спектрума -- это ему спасибо.
> не говоря уж про опеннет.
https://www.opennet.ru/~Урри упоминал здесь, что занимался оптимизацией какого-то кодека как раз для ARM.
> Ну ок, мне надо бы попробовать спортировать кусок непонятного (для меня) кода
> r8 на r7 (ну или x86-64, но это явно не легче).
> Для простоты предположим что ассемблерного. Использует neon (или как там называется
> 64битный аналог) Есть ли вообще документация, способная в этом помочь, и
> насколько реально ее понять за разумное время?
Набор команд должен быть документирован и открыт. ARM ещё в начале 0х присылал мне компакт-диск со всеми доками и инструментами (правда, не понадобился). По времени, что бы читать код для новой архитектуры, потребуется от дня (реверс простейшей прошивки AVR) до недели (дольше вряд ли есть смысл этим заниматься -- пора идти мести улицу). Но что бы эффективно писать, желателен опыт.
По "мультимедиа-расширениям" (оговорюсь, с ними не работал, потому могу наврать) -- они на всех архитектурах внедряются для одних задач, стало быть и инструкции должны быть в определённой мере унифицированы на уровне интринсиков (мнемоник).
Кстати, на Android-x86 эмулируют какие-то из команд SSEx на предыдущем поколении, ловят "навалидный опкод" и исполняют замену.
>> А суперскалярные ныне все производительные процессоры
> у risc (во всяком случае, канонического) суперскалярности быть не должно - одна
> команда- один такт. Префетч не в счет.
Так тут ветка началась с того, что ныне всё отошло от канонов и смешалось.
>> Этот другой признак так же как и упомянутый мною является следствием из цели RISC -- упрощение декодера.
> не декодера. Декодер у того же DEC vax прост как палка. Можешь
> в уме декодировать. Но это cisc.
> Умеющий что-то вроде add %r1,(%r2)+ - как это чисто технически можно было
> бы выполнить за один такт, не используя промежуточную память?
Для этого надо нарисовать схему простейшего процессора и понять, что регистров в нём несколько поболее, чем именованных (доступных как адресанды команд). И что ежели тупо брать 3 бита и адресовать по ним одну из 8ми условных ИР22 -- это немножко проще, чем выставить выход одного из регистров на ША и считать ШД в какой-то 9-й регистр, а потом его использовать. В последнем случае блок декодера из одного дешифратора разрастается в "исполнительное устройство".
>> Ну так и ссылка не на "тогда".
> различие cisc/risc - это именно "тогда". Для современных чудоидей существует отдельная
> терминология, для каждой своя.
Вспомнился шрифт, который заменяет каждое buzzword на "bullshit". :)
