Как правило, не вполне , модель программирования не всегда точно эквивалентна. Вам нужно проверить оба комплекта документов, если вы хотите быть на 100% уверенными.
https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64
например. bsf / bsr : Документы Intel говорят, что они оставляют пункт назначения неопределенным, AMD говорит, что он оставляет его неизменным на нуле. Но на практике Intel делает это с микроархитектурной зависимостью от выходного регистра. Эта ложная зависимость заражала lzcnt / tzcnt до Skylake, а popcnt все еще на Intel, но не на AMD. Но пока Intel не придет к выводу на бумаге, что они будут продолжать , заставляя свои HW вести себя таким образом, компиляторы не воспользуются этим преимуществом, и мы, возможно, не должны делать это и вручную. (Википедия, похоже, говорит, что в Intel старшие 32 бита места назначения могут быть неопределенными, а не обнуленными, для bsf eax, ecx для Intel, хотя. Так что это не совсем то же самое, что всегда писать EAX.)
Это особенно важно для кода ядра, привилегированное поведение команд может иметь более тонкие различия. Я думаю, что семантика аннулирования TLB в основном совпадает, например, в обоих случаях гарантируется, что вам не нужно аннулировать TLB после изменения недействительной записи на действительную. Таким образом, x86 запрещает «отрицательное кеширование», поэтому реализация, которая хотела бы сделать это, должна была бы отслеживать хранилища таблиц страниц для согласованности.
Возможно, что-то непреднамеренное, например, у Intel и AMD есть разные ошибки для sysret с неканоническими адресами x86-64, что делает его небезопасным для использования после того, как системный вызов ptrace мог изменить сохраненный RIP. Потенциальная ошибка GP может произойти в режиме ядра после переключения на пользовательский стек , когда управление ядром передается другому потоку пользовательского пространства из того же процесса, который может изменять эту память стека. (https://blog.xenproject.org/2012/06/13/the-intel-sysret-privilege-escalation/) Вот почему Linux всегда использует iret, за исключением быстрого пути общего случая, когда сохраненные регистры известны-чисты. комментариев в entry_64.S в исходном коде ядра суммируются
Гарантии атомарности для невыровненных кэшированных загрузок / хранилищ более слабые для AMD: границы размером до 8 байт могут иметь значение для x86-64 из-за AMD. Почему целочисленное присваивание для естественно выровненной переменной atomic в x86? охватывает общее подмножество этого.
Размер строки кэша никогда не был официально стандартизирован. На практике процессоры Intel и AMD используют 64-байтовые строки, и это может быть запрошено во время выполнения, используя CPUID одинаково для обоих.
AFAIK, правила порядка памяти идентичны как минимум для WB, и, вероятно, для других типов, включая WC и взаимодействие с LFENCE / SFENCE / MFENCE, против lock add. Хотя Intel не четко документирует, если lock и xchg должны отличаться от mfence. Но вы спрашиваете о самой модели программирования, а не только о том, что документы говорят на бумаге. См. Имеет ли блокировка xchg такое же поведение, как и у mfence? и В чем разница в логике и производительности между LOCK XCHG и MOV + MFENCE?
IDK о AMD, но загрузка NT WC может измениться с lock add / xchg на Intel (но я думаю, что они не должны с MFENCE, и именно поэтому обновление кода Intel должно было усилить MFENCE на Skylake чтобы заблокировать OoO exec, как и другой эффект LFENCE, чтобы вообще предотвратить последующую загрузку в трубе.) Ответ @ Bee по первой ссылке упоминает об этом, и смотрите в нижней части этого . При тестировании реального оборудования всегда трудно сказать, что такое поведение, гарантированное в будущем, и что является лишь деталями реализации, и именно здесь появляются руководства.