На мой взгляд, система команд процессоров x86 имеет нереализованый потенциал к расширению набора инструкций. К примеру, префиксы REPE/REPNE используются лишь как дополнение к MOVS/CMPS/STOS/LODS/SCAS, а это всего пять команд! Тем самым, потеряно общирное поле остальных применений этих префиксов. При нужде в новых, расширенных командах разработчики всё скинули на "многострадальный" префикс 0F как в мусорную кучу, вместо того, чтобы расширить область применения готовых и узко специализированных префиксов LOCK/REPx. А это почти 5 сотен новых команд! Ниже я привожу таблицу с примером расширения области применения префиксов REP: Код (Text): Возможный код: Многострадальный 0F префикс: F2 00/02 |0F FC PADDB F2 01/03 |0F FE PADDW F2 08/0A |0F EB POR F2 09/0B |0F ?? --- F2 10/12 |0F DC PADDUSB F2 11/13 |0F DD PADDUSW F2 18/1A |0F D8 PSUBUSB F2 19/1B |0F D9 PSUBUSW F2 20/22 |0F DB PAND F2 21/23 |0F DF PANDN F2 28/2A |0F F8 PSUBB F2 29/2B |0F F9 PSUBW F2 30/32 |0F EF PXOR F2 31/33 |0F ?? PXORN F2 38/3A |0F ?? --- F2 39/3B |0F ?? --- F3 00/02 |0F FC PADDB F3 01/03 |0F FE PADDW F3 08/0A |0F EB POR F3 09/0B |0F ?? --- F3 10/12 |0F EC PADDSB F3 11/13 |0F ED PADDSW F3 18/1A |0F E8 PSUBUSB F3 19/1B |0F E9 PSUBUSW F3 20/22 |0F DB PAND F3 21/23 |0F DF PANDN F3 28/2A |0F F8 PSUBB F3 29/2B |0F F9 PSUBW F3 30/32 |0F EF PXOR F3 31/33 |0F ?? PXORN F3 38/3A |0F ?? --- F3 39/3B |0F ?? --- Вы когда-нибудь встречали код программ, где операции переходов использовали бы "запрещённые" точки? А ведь это тоже огромная область к расширению команд, без скидывания их на многострадальный 0F к тому же. Причём, число байтов никак тут не изменилось, а логический смысл, напротив, сохранился и расширился. Смотрим: Код (Text): Не используем: Вместо этого многострадальный 0F: 70 FE |0F 80 JO 70 FF |0F 90 SETO 71 FE |0F 81 JNO 71 FF |0F 91 SETNO 72 FE |0F 82 JB 72 FF |0F 92 SETB 73 FE |0F 83 JNB 73 FF |0F 93 SETNB 74 FE |0F 84 JE 74 FF |0F 94 SETE 75 FE |0F 85 JNE 75 FF |0F 95 SETNE 76 FE |0F 86 JBE 76 FF |0F 96 SETBE 77 FE |0F 87 JNBE 77 FF |0F 97 SETNBE 78 FE |0F 88 JS 78 FF |0F 98 SETS 79 FE |0F 89 JNS 79 FF |0F 99 SETNS 7A FE |0F 8A JP 7A FF |0F 9A SETP 7B FE |0F 8B JNP 7B FF |0F 9B SETNP 7C FE |0F 8C JL 7C FF |0F 9C SETL 7D FE |0F 8D JNL 7D FF |0F 9D SETNL 7E FE |0F 8E JLE 7E FF |0F 9E SETLE 7F FE |0F 8F JNLE 7F FF |0F 9F SETNLE или (Очевиден выигрыш в один байт!): Код (Text): Не используем: Вместо этого многострадальный 0F: 66 70 |66 0F 80 JO 66 71 |66 0F 81 JNO 66 72 |66 0F 82 JB 66 73 |66 0F 83 JNB 66 74 |66 0F 84 JE 66 75 |66 0F 85 JNE 66 76 |66 0F 86 JBE 66 77 |66 0F 87 JNBE 66 78 |66 0F 88 JS 66 79 |66 0F 89 JNS 66 7A |66 0F 8A JP 66 7B |66 0F 8B JNP 66 7C |66 0F 8C JL 66 7D |66 0F 8D JNL 66 7E |66 0F 8E JLE 66 7F |66 0F 8F JNLE 67 70 |0F 80 JO 67 71 |0F 81 JNO 67 72 |0F 82 JB 67 73 |0F 83 JNB 67 74 |0F 84 JE 67 75 |0F 85 JNE 67 76 |0F 86 JBE 67 77 |0F 87 JNBE 67 78 |0F 88 JS 67 79 |0F 89 JNS 67 7A |0F 8A JP 67 7B |0F 8B JNP 67 7C |0F 8C JL 67 7D |0F 8D JNL 67 7E |0F 8E JLE 67 7F |0F 8F JNLE Ещё бы хотел заметить, что префикс LOCK и тормознутая команда WAIT обыкновенно используются довольно редко, а значит могли бы иметь не один байт инструкции и не "засорять" собой всю систему команд. Посмотрите на пример, многое логично и имеется ещё десяток новых возможностей: Код (Text): Не используем: А могло бы означать: E0 FF |F2 REPNE E1 FF |F3 REPE E2 FF |?? E3 FE |9B WAIT E3 FF |F0 LOCK E8 FD FF |?? E8 FE FF |FA CLI E8 FF FF |FB STI E8 FB FF FF FF|?? E8 FC FF FF FF|?? E8 FD FF FF FF|?? E8 FE FF FF FF|?? E8 FF FF FF FF|?? E9 FD FF |?? E9 FE FF |?? E9 FF FF |?? EB FF |HLT И на последок. Немалый выигрыш в вычислениях был бы достигнут, если нам только расширили область оперирования с половинками 32-битных регистров. К примеру: Код (Text): Игнорируется: А могло бы означать: 66 86 D5 |-- XCHG EDL, ECH or XCHG DX, ECH 66 88 C6 |-- MOV EDH, EAL or MOV EDH, AX 66 B4 12 34 |-- MOV EAH, 0x3412 Думаю, некоторые скажут, что всё выше описанное - бред, а мне заняться нечем и я дурака валаю. Другие скажут, что я умудрился запутать и без того попутанную, сложную систему команд x86. Третьи посоветуют заняться чем-то более простым... На счёт простоты. Мне удалось разработать теоритическую модель процессора (так же имеется эмулятор) с интуитивно(!) понятной системой команд. А это почти что уникальная особенность процессора. Т.е. кодирование программы не требует чтобы постоянно подглядывали в систему команд. Один байт - одна инструкция, это есть во многих подобных процессорах. Но, сам байт инструкции имеет обоснованный код и легко запоминается. Например, вот несколько инструкций из его набора: Код (Text): Операция: Краткое описание: 00 HALT |Ноль - признак конца всего: строк, таблиц... Здесь 00 - как RET/HALT 09 SKIP+9|Пропустить +9 следующих байтов команд 12 CHAR+2|Загрузить 1 байт (символ) из ячейки +2 25 SLAB+5|Загрузить 2 байта (слог) из ячейки +5 4D WORD-3|Загрузить 4 байта (два слога = уже слово) из ячейки -3 (-3 = 0xD) A3 LOAD%3|Загрузить Arg%3 BE SAVE-2|Выгрузить данные в ячейку #2 дна (-2 = 0xE): -1..-7:дно; +1..+7:верх FE SKIP-2|Перейти на две команды назад (-2 = 0xFE)
Ну тут явно с размерами какаято ересь, если я правильно понял MOV EAH, 0x3412 то EAH это байт старшей части регистра, и че тут получается мы с такой мнемоникой в байт можем поместить ворд? или как здесь тожесамое XCHG DX, ECH А вообще, еслиб было необходимо чтото оптимизировать или добавить функционал, то интел бы зделал все что нужно.
Ну, ереси нету. Смотрите: если AX = AH.AL т.е. R16X = R8H.R8L тогда EAX = EAH.EAL т.е. R32X = R16H.R16L где EAL - биты 0..15 EAX, а EAH - биты 16..31 можно RAX = RAH.RAL т.е. R64X = R32H.R32L где RAL - биты 0..31 RAX, а RAH - биты 32..63 где EAH и EAL - 16-битные половинки EAX, а не 8-битные а RAH и RAL - 32-битные половинки так, обмен старших 16 бит с младшими происходит ROL EAX,16 тогда как это можно записать как XCHG EAH,EAL если всмотреться, то 8-битных манипуляций гораздо больше 16-битных и 32-битных. Какрас EAH и EAL - их восполняют... и если вдуматься и поизучать фрагменты программ, можно увидеть, что это многое бы упростило
Нет, ну естественно, если взять и перетряхнуть весь нажитый машинный/бинарный опыт и начать с нуля, то с точки зрения кодирования, естественно кодировать наиболее вероятные (часто встречающиеся) команды наименьшими символами будет выгодно, а то что сейчас неполностью используется - так это не проблема для создателей, ибо денюжки и так в карман капають - пипл хавает, а лишний байт, другой, третий - по барабану, всё и так предвыборется и сполнится, ведь не даром терабайт покорили (тоже за счёт ведь юзеров), чтобы там и хранить эти самые маленькие недостатки большой и сложной, но работающей архитекруты.
