С удивлением обнаружил, что в 64 bit моде xor edx,edx обнуляет не только edx, а весь rdx. Коллеги, где про это почитать можно?
wsd Обнаружил экспериментально отладчиком под OpenSuse x86_64. Надеюсь, что это не глюк процессора (в моем случае Core 2 Duo), а 64-битное белое пятно в моем ассемблерном опыте. Вот и интересуюсь доками, где это хоть как-то упомянуто.
Ну так тебе и ответили. В Intel® 64 and IA-32 Architectures Software Developer's Manual про это написано. http://www.intel.com/products/processor/manuals/ Есть аналогичные мануалы от AMD, в них тоже написано. Это не баг, так задумано.
Gray Совсем скоро ты сможешь обнаружить, что верхняя часть 64-х битного регистра обнуляется не только при XOR, а при любой арифметической/битовой операции с 32-х битным регистром.
Разумеется, прежде чем написать в форум, я пару часов шерстил эти интеловские доки, но, увы, так и не нашел ничего на эту тему. Хотелось бы более конкретной ссылки, а не банального RTFM.
cppasm Благодарствую. Вы мне очень помогли. t00x Скорее не так задумано, а так получилось. Ведь остались занятыми более длинные дублирующие опкоды (xor rax,rax... xor rbx,rbx и т.д. ) Если бы так задумывалось, то было бы логично нагрузить эти опкоды другой функциональностью. Например обнулением пар регистров. Когда-то подобное "так задумано" звучало в оправдание существования двух опкодов для int 3 (CC и CD 03)... и двух вариантов начала заголовка EXE файла (MZ и ZM)
Gray 1.1. инструкция xor rax, rax логически _не_дублирует_ xor eax, eax... в явном виде. 1.2. сделали 2 разных опкода для одного аппарного действия. 2.1. CC и CD 03 - две разные инструкции.
t00x Поясню, что я имел в виду. Сначала немного истории в вольном изложении Давным-давно, когда компьютеры были большими, а гибкие диски действительно гибкими... Занимались сотрудники интела разработкой супер-пупер крутого кристалла для процессора 8086. И уже почти вся архитектура была сваяна, как вдруг, некто Джон хлопнул себя по лбу и сказал: "Мужики, а прерывание для отладчика надо было бы сделать однобайтовым! Как у нас это CD 03 на границе сегмента будет работать, а?" Почесали репу мужики и ответствовали: "Не беда, мы сейчас в декодер команд добавим однобайтовый опкод СС. Ну а внутрях будет она делать тоже самое, что и CD 03". И сделали 2 разных опкода для одного аппарного действия.... Вот так оно "получилось". А действительно разными CC и CD 03 стали лишь в более старших процессорах с появлением протектед-моды и сопутствующих ей прелестей. Вот тогда Интел и стал с гордостью говорить: "Так и задумано"
Gray Нет, именно так и задумывалось. Причины две. Первая, идеологическая - 64-битный режим введен в первую очередь для увеличения размера адресуемой памяти, а вот размера операнда в 32-бита вполне хватает для подавляющего числа задач. Поэтому в 64-битном режиме размер операнда по умолчанию по прежнему равен 32 битам и соот-но для адресации 64-битных регистров (включая расширенные R8-R15) юзаются префиксы REX, "злоупотребление" которыми может привести к заметному увеличению объема программы, и соотв-но не рекоменудется юзать 64-битные и расширенные регистры без особой на то необходимости. Вторая, техническая - сохранение старших битов при изменении частичных (partial) регистров в современных компах (с их out-of-order исполнением и переименованием регистров) является серьезным гемором и решается по разному. В P6 (включая Core 2) для операций с частичными регистрами отводятся отдельные темп-регистры и старшие части просто игнорируются (лежат в своих темп-регистрах) до тех пор пока операция не уйдет в отставку - отсюда с одной строны отсутствие ложной зависимости младших частей от старших, а с другой стороны серьезные штрафы (partial register stall), если после частичного изменения сразу происходит обращение к целому. P4 и атлоны на каждой частичной операции копируют старшие биты из целого регистра, что требует доп."телодвижений" и вводит ложную зависимость части от целого. Посему в 64-битном режиме решили отказаться от этой "порочной практики" и при операциях с младшими 32-битами не гонять каждый раз неиспользуемые старшие 32-бита, а просто обнулять их. В свете рассмотренной выше "32-битной идеологии 64-битного режима" это является вполне логичным и оправданным PS: "Загрузить другой функциональностью" xor rax,rax нельзя, т.к. он отличается от xor eax,eax только префиксом, также как и xor ax,ax
leo Очень убедительные резоны. Даже спорить не хочется Спасибо. t00x Как подсказывает мне моя склеротическая память, брекпоинт на прерывании был и в еще более древних процессорах... чуть ли не в 8080.
