> Еще раз.
> Ты сказал, что x86_64 лучше чем i386(i686) потому что:
> - есть относительная адрасация (в отличие от).

Да. Правда про выполнение я приврал - там все-таки номинально относительная адресация есть. Тупая (маленький диапазон смещений), что делает ее трудноюзабельной, но номинально я все-таки не прав. А кроме этого есть еще работа с данными. А вот с этим у х86 все еще хуже. Для тех кто тупит, поясняю: общепринято понимать под относительной адресацией адресацию по смещению относительно текущего значения program counter. По уму должно быть реализовн и для кода и для доступа к данным, иначе без диких костылей в позиционно-независимой программе не обойтись. Особенно смешно с учетом того что в современных реалиях очень желательно чтобы весь код такой и был, чтобы ALSR можно было делать просто и быстро, на радость хакерам (брутфорсить 2^64 адресов, особенно по сети - прикольное занятие).

> но тактируемые в 2 раза чаще)

Тактируется оно одинаково. А огромный там в основном кеш. Сомнительно что замена 32-битных ALU на 64-битные сильно меняет картину.

> Со вторым спорить не стал, хотя там есть один подводный камень -
> вся радость увеличения регистрового пула только писателям компиляторов.

Да в общем то и програмеру, если ему приперло вот в именно этой пяди кода отыграть максимум, так что до асма снизошли - трах с полутора неравноправными регистрами х86 и их постоянным пушпопом совершенно не в кассу. А в кучке 64-битных регистров многое можно посчитать и без пхания промежуточных результатов в стек. В операциях регистр-регистр тормозить просто нечему, так что в лучшем случае регистровая математика пойдет на полной скорости которую вообще в принципе способен развить проц. А х86 неизбежно тормознется лишними пушпопами, которые как ни крути лишние команды, подлежащие выполнению + лишние доступы в память, хотя-бы в кеш. Вариант когда все удалось сделать чисто на регистрах - как правило самый ядреный. В основном потому что процу все регистры доступны в пределах того же такта и без дополнительных условий и оговорок.

> Задача раскидывания переменных по регистрам она порядка NP,
> решается оптимально толко полным перебором,

Теория это здорово, но на практике достаточно посмотреть на то чем отличается х86 ABI от x64 ABI и прикинуть что на х64 вызов типовой функции с 1-2 параметрами и 1 результатом на выход выглядит в виде асма явно менее уныло чем пачка PUSH всего и вся а потом POP всего и вся на х86 ;)

> и если железо поддерживает больше регистров то это немного сглаживает принципиальную
> неоптимальность АЛГОРИТМА ОПРИМИЗАЦИИ КОМПИЛЯТОРА.

Избыточные PUSH + POP не может быть оптимальным, т.к. это не часть логики программы а лишь технический костыль в ситуации когда "пороху^W регистров не хватило". Все переменные программы заведомо не влезут в куцые регистры х86.

Кстати в целом для компилеров (и програмеров :D) идеальным вариантом был бы проц с бесконечным числом регистров. Тогда можно засунуть практически все переменные в регистры и крайне быстро с ними всеми работать, вообще никогда не сохраняя в стек ничего. Правда,  поскольку бесконечное число регистров сделать не получается, компилер вынужденно укладывается в тот бюджт который есть. Чем больше регистров - тем ближе к идеалу, когда все переменные максимально быстрые, а стек вообще насиловать не надо.

> К железу и скорости выполнения это никак не относится.

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

> Но факт есть - если больше регистров, то программы будут быстрее выполняться.
> Поправка только - это не недостаток архитектуры i3(6)86, а недоразвитость
> теории алгоритмов и компиляторов.

Не, извини, дяденька, здравый смысл подсказывает, что если в алгоритме есть 10 переменных с которыми хочется одновременно делать интенсивно математику, хорошо если все 10 попадут в 10 независимых регистров, немедленно доступных процу на том же такте и допускающих математические операции. Тогда с ними удастся поработать быстро и без изгалений. Лобовыми математическими операциями с регистрами. А если регистров будет меньше, придется совершенно непроизводительно тасовать переменные между стеком и регистрами по причине "на всех регистров не хватило". Лишние пушпопы ну совсем никак не могут производительность добавить. На х86 компилеры усираются, пытаясь впихнуть в эту куцую хрень ну хоть чего нибудь. Оптимально раскидывать полтора регистра? Хаха, смешно. На х86 их постоянно приходится "оптимально" сливать в стек и доставать обратно. Чтобы вообще иметь возможность хоть чего-то считать. Ибо если регистр уже занят ценным промежуточным результатом, считать в нем что-то еще без потери результата уже как-то не получится, и надо его сохранить, да?

> Но тут появилась 'относительная адресация'. Все, финиш.

Ага, вот только чей?

> В 4004 и ранних вариантах логики в программируемых калькуляторах еще можно было
> о чем то говорить, но СЕЙЧАС? Это что, троллинг такой?

Архитектура системы команд х86 настолько уныла что вполне заслуживает быть обтролленой. Пережитки идиотизмов чуть ли не времен 8080 лезут из всех щелей. Один из таковых - куцый набор регистров. Все более современные процы давно уже сделали выводы о том как компилерам и програмерам лучше. Ну а интел как обычно.

> Относительная адресация говорит об одном - что у этого процессора в отличие
> от предыдущих
> есть еще один сумматор, который на лету добавляет к адресу содержимое другого
> регистра. Любого.

Спасибо, капитан. Только не "любого" а "program counter", а то что вы упоминаете - это индексированный доступ. А относительная адресация нужна затем чтобы можно было адресовать данные и код относительно текущего места выполнения, сделав блок кода некоей полностью самодостаточной сущностью в памяти. Тогда его просто будет в память вгрузить и просто перенести в другие адреса, в идеальном случае - тупым копированием/загрузкой в желаемое место в адресах. В случае program counter EPIC WIN состоит в том что в командах кодируется только относительное смещение, а программе не надо вообще ничего знать о том в каких вообще адресах происходит дело. Ну, program counter при выполнении неизбежно фигурирует и актуализуется, потому что иначе программа бы не работала. А вот о других регистрах этого не скажешь. А то что вы расписали - это скорее индексированный доступ, но это совсем не то. Потому что базу индекса надо явно задавать где-то. А в случае program counter "база" сама себя задает, и код генерить не сложно (указать "от сих на 60 байтов вперед" - невелика наука) ;)

> Этим изобретением гордились в 60 года, "...

Да, уже тогда некоторые господа придумали кое-что получше чем уродец на костылях с полутора куцыми регистрами. А интел настолько ушибся на своем 8080 и потом 8086, что так и таскал этот куцый набор регистров, чтобы было похоже на выпердыши конца 70-х и начала 80-х прошлого столетия и дальше :))).

> адресацию ! Наши инженеры добавили еще дно уникальное устройство сложения, теперь
> для часто упортебляемой комбинации вы можете сразу выбрать смещение из кода
> операции и ОДНОВРЕМЕННО сложить с базовым регистром, ОТНОСИТЕЛЬНО которого вы и
> адресуетесь"

Ну так в интеле почему-то это не осилили. Только в амд64 появилось.

> Итого - Любая адресация у интела ОТНОСИТЕЛЬНАЯ. Причем минимум ДАВЖДЫ ОТНОСИТЕЛЬНАЯ Любая.
> Из за сегментных регистров, и тем более таблиц виртуальной памяти MMU.

Ага, если не считать такой мелочи что
1) Сегментные регистры кто-то должен явно программировать, в отличие от program counter'а, который актуален "by design".
2) Обычная программа в ring3 вообще ничего не знает ни о каком paging ;)

[del]
> адресация IP не предусмотрена. А ЗАЧЕМ нам адресовать в коде чтото
> относительно регистра программного счетчика?

У него есть одно важное свойство: program counter актуализует себя сам, естественными методами, без заботы программы об этом. Если программа адресуется относительно него - ее можно в любой адрес запихнуть, а она не заметит разницы. Потому что для ее запуска всяко управление будет подано на старт, а потом PC сам же себя и апдейтит. А вот всякие там другие регистры таким полезным свойством не обладают, требуя к себе явного внимания и указания правильной базы в программе :P. Это не относительная а индексированная адресация получается. Только вот базовый адрес надо явно задавать, и программа должна это явно знать, поэтому ни о каком свободном переезде по адресам спич не идет.

> Мы уже не Гарвардскую архитектуру имеем?

Epic fail! В гарвардце такое как раз и было бы невозможно. У совсем злостного гарвардца адресные пространства кода и данных различны, поэтому program counter (описывающий адрес с точки зрения кода) не имеет физического смысла применительно к адресам в пространстве данных. Поэтому в 100% трушном гарвардце относительная адресация в ее обычном виде - а это вообще как? Другое дело что чистокровные гарвардцы по этому поводу довольно мучительны в програминге. Даже сама по себе идея "вгрузим бинарь с диска!" очень плохо ложится на парадигму гарвардца с четким разделением кода и данных. Начинаются всякие костыли "а давайте к коду все-таки можно будет обращаться как к данным?" и прочие веселости.

> У нас что, допотопная Лента Тьюринга? Мы пишем самомодифицирующийся код который
> на лету меняет сам себя? Зачем выбирать данные в трехуровневой сегментноф
> стековой машине с физически разделенной памятью команд и данных отностиельно команд?

Простейший пример зачем это надо я привел: допустим простая, быстрая и безгеморная реализация ALSR.

> Итог - любой интеловский процессор имеет минимум 2 кратно относительную адресацию. Двухкратно,
> а для некоторых случаем и трехкратную.

Агащаз. Федот да не тот. Скорее, это просто индексированная адресация. Только вот она ни разу не помогает писать программу не зависящую от адресов.

> И уж совершенно ненусветная глупость говорить что это как то ускоряет или
> замедляет, с чего собственно началось.

Костылинг который приходится для х86 по этому поводу проводить - определенно замедляет процесс старта программы: при нужде передвинуть программу в новые адреса - патчится все что нельзя заадресовать относительным смещением, а можно только указанием конкретных адресов.