Комментарии 162
… реально от нарушения последовательности подачи питания дохли только ВГ93
Безусловно, что одним из самых лучших процессоров, из сделанных в 70-е, является 8086
Вот не соглашусь.
По сравнению с имеющимися тогда процессорами Motorola 68000 и Zilog 8000, он по многим параметрам хуже:
Сегментные регистры — это не достоинство, а недостаток. Благодаря этим сегментным регистрам, существовало пять различных моделей памяти (кто программировал в конце восьмиидесятых — начале девяностых помнят). Всякие разные диковинные tiny, small, medium, large и huge.
Motorola 68000 и Zilog 8000 напрямую адрестовали, соответственно 16 и 8 мегабайт, в отличии от 1 мегабайта у 8086.
Motorola 68000 и Zilog 8000 имели два режима работы — пользовательский и симтемный, что позволяло строить защищенные системы. В 8086 такого не было.
- Ну и наконец, система команд — у Motorola 68000 и Zilog 8000 она была более продвинутой, практически любая команда могла использовать любой регистр, в отличие от 8086 со всеми этими AX, BX, CX, DX, где для одной команды можно было использовать только AX, счетчик мог быть только в CX и так далее. Кстати для одинаковых задач, код у 68000 получался компактнее, чем у 8086.
1. Большинство этих режимов мало что значат. Они скорее о формате выходного файла COM или EXE. Вот если нужны были большие массивы, то надо было выбирать режим Huge — это замедляло. Но к концу 80-х, когда стало для этого у многих хватать памяти, уже были доступны системы для работы в 32-разрядном режиме, в котором этой проблемы уже не было, хотя и заметно тормозился ввод-вывод. Конечно, это уже про 80386. Могу ещё заметить, что указание режима Tiny позволяло получать самые компактные коды, без загрузчика, благодаря именно сегментным регистрам. И вроде бы нет особой проблемы в том, чтобы один раз указать режим. Cкорее могло напрягать использование директив FAR и NEAR, но скорее только начинающих. В современных процессорах много режимов, хотя скорее чисто системных.
2. Иметь как-бы защищенные режимы без защиты памяти вещь абсолютно бесполезная, это только делало архитектуру бессмысленно более громоздкой.
3. Согласен, что теоретически система команд 68000 более продвинутая, но когда дело доходит до практического программирования, то 8086 часто (пусть и не всегда) оказывается лучше. Ну и что, что для счётчика можно использовать только CL — проблема возникнет, только если нужно сразу несколько таких счётчиков, больших 1 — это возможно, но скорее редко, чем часто. Было интересно получить ссылки на какие-нибудь данные, указывающие, что код для 68000 более компактен, чем для 8086. У меня обратная информация, например, программка для вычисления числа π для 8086 почти в полтора раза меньше (примерно 650 байт против более 900). У 8086 многие команды занимают только один байт.
Трудно сказать, почему z8000 не получил широкого распространения, скорее всего по каким-то причинам нетехнического порядка. На мой взгляд он был вполне достойным микропроцессором. Сегментная организация оказалась тупиковым направлением — сейчас никто ей не пользуется.
Трудно сравнивать код 68000 и 8086 напрямую, поскольку это сильно зависит от квалификации программиста, но 68000 имел, например, команду movem, которая позволяла загружать несколько регистров и сокращала код. Такой команды 8086 не имел.
Насчет защиты пямяти — у z8000 она была.
Конечно, у 68000 больше регистров и это на некоторых задачах может давать более компактный код. Но инструкции у х86 могут быть любой длины, например, 1 или 3 байта. А у 68000 все выравнено по границе 4 байта. У архитектуры х86 тут большое преимущество.
Это было причиной популярности z8000 для построения low-end unix серверов.
Не согласен на счёт сегментной организации. Виртуальное адресное пространство тоже в каком-то смысле "сегмент".
Широкого распространения не получил, т.к. был совместим сам с собой и не попал ни в один из популярных компьютеров 80х.
Большинство этих режимов мало что значат. Они скорее о формате выходного файла COM или EXEЭто было очень важно для ABI ЯВУ. Код, скомпиленный в одной модели, только через костыли линковался с кодом другой модели.
Если требовалось предоставить callback-функцию, или просто указатель на данные, нужно смотреть, в одном регистре или в двух он предоставлялся. Очень «увлекательно» было разбираться с API Win3.11, в какую ф-цию какой нужен указатель.
Сегментные регистры — это не достоинство, а недостаток. Благодаря этим сегментным регистрам, существовало пять различных моделей памяти (кто программировал в конце восьмиидесятых — начале девяностых помнят). Всякие разные диковинные tiny, small, medium, large и huge.
Motorola 68000 и Zilog 8000 напрямую адрестовали, соответственно 16 и 8 мегабайт, в отличии от 1 мегабайта у 8086.
Я не знаю систему команд 68000 и 8000, но предполагаю, что без сегментации памяти им приходилось оперировать 32-битными значениями адресов при помощи 16-битных регистров? Вряд ли это удобнее; и уж точно кодировка команд получается более компактной, когда используются 16-битные смещения «в известном сегменте», чем когда используются адреса «от начала памяти».
«Диковинные модели памяти» означали, что 32-битными адресами для кода и/или данных приходилось пользоваться только в тех программах, где это действительно было нужно, а не во всех без исключения.
www.chipnews.ru/html.cgi/arhiv
www.chipnews.ru/html.cgi/arhiv/99_09/stat_2.htm
www.chipnews.ru/html.cgi/arhiv/00_01/stat-3.htm
но сайт то ли взломан, то ли дорвей сделали, то статья открывается, то реклама
А тут только начала статей
www.chipinfo.ru/literature/chipnews
Отдельно что-то где-то валяется, видимо копипастили
housea.ru/index.php/micro/14906
Забавно сейчас про это читать:D
«Специалист» забыли.
Забыли первый любительский комп — РадиоМикро80. Журналы Радио конца 1982 и весь 83. Огромный по сравнению с тем же Р86рк, но тем не менее первый спаянный и оживший…
Мне довелось программировать на ассемблерах разных процессоров. Последний в списке – это Xilinx MicroBlaze.
Вы его точно на ассемблере программировали? Microblaze — это ж ПЛИСовый процессор из EDK. Программируется в SDK на Си. А в XPS процессор вроде только конфигурируется.
А вообще — обзор очень хороший.
В sparc-е множество регистров, объединенных в пересекающиеся блоки, что позволяло передавать до восьми параметров функции не залезая в память. Кстати, на моей аватарке за моей спиной sparcstation десятка.
Еще все эти гарвардские 8048/8051, ломающие шаблоны.
8048 использовался, к примеру, в игровой приставке Magnavox Odyssey 2 (как обычный центральный процессор)
Сохраняется ещё интрига вокруг инструкции UD1 (0F B9), которая неофициально является примером неправильного опкода. Признают ли за ней этот статус или назначат новое качество, пока неизвестно.
Если это про сейчас, то открываем software.intel.com/en-us/articles/intel-sdm, выбираем Intel® 64 and IA-32 architectures software developer's manual volume 2B: Instruction set reference, M-U, находим UD—Undefined Instruction и видим UD0(0F FF /r), UD1(0F B9 /r),UD2(0F 0B).
fasm знает только про UD2, yasm — UD2 и UD1.
Нет, переход на 6502 был как "связывание рук".
Да, про память знал — но всё равно по сравнению с регистрами — это иной стиль. Поэтому было менее удобно. Возможно, это дело привычки и "закрепившегося" стиля… 580-й — это советский 8080. Про 68000 читали в обзорах (приходили на кафедру переплетённые ксерокопии), было интересно — но до практики дело не дошло.
Для полностью самостоятельного приложения, которое берёт на себя всю работу с аппаратной частью и вокруг, это было неважно. А вот если хотел сделать что-то такое, что и было хитрое на ассемблере, и сочеталось даже просто с местным бейсиком (хотя бы не сломать его по выходу из своего кода!) — уже возможность использовать нулевую страницу резко сокращалась. А какая-нибудь Рапира использовала её реально всю — оставляя только несколько ячеек нетронутыми — причём какие именно, документация подвирала.
Да, с этим можно было банально не столкнуться. Но с тех пор утверждение «нулевая страница это те же регистры» вызывает у меня только саркастическую ухмылку — и применяется как объяснение, почему процессору нужны настоящие регистры, а не суррогаты.
При том, что его иначе использовать в этих условиях было невозможно (чрезмерно дорого). И размер нулевой страницы, и громоздкость временной заливки данных в неё и вылива обратно — провоцировали абьюзить её, используя под то, что в нормальных системах не сидит постоянно в регистрах.
> Но архитектура Spark с более чем сотней регистров не стала преобладающей.
Вы с IA-64 не путаете? SPARC имел с точки зрения пользовательского кода 32 регистра (включая пустой). Системному позволялось видеть полный ротор регистров, но к вопросу плотности обычного кода это уже не относится.
Это особенность Агата.
На Apple II была табличка в документации, на которой было расписано использование нулевой страницы. Часть ячеек были неиспользуемыми, а большинство использовалось Бейсиком, и их тоже можно было использовать в своей программе на ассемблере. Только небольшое количество ячеек использовалось Монитором, их не надо было трогать.
На практике нулевая страница была эквивалентна 128 16-разрядным регистрам, из которых где-то 80 можно было использовать.
специальное адресное пространство для портов ввода-вывода размером 64 КБ (y 8080 и z80 этот объем – 256 байт).
Для z80 есть возможность адресовать все 64к портов ввода-вывода:
Команды с непосредственной адресацией IN A,(n) и OUT (n),A аналогичны командам
ввода-вывода МП I8080. Но в добавление к адресу порта n, выставляемому в младшую часть шины адреса, в старшую часть ША подается содержимое аккумулятора.
Это достигается просто манипуляцией адреса регистра. Данные никуда не перемещаются.
Другой недостаток ARM в меньшей плотности кодов по сравнению с архитектурой x86, что делает программы несколько большими, а главное снижает эффективность работы процессорного кеша.
Давным давно, ARM был чуть хуже чем IA-32.
Если же говорить о состоянии дел в настоящий момент, то ARMv8 с фиксированными 32-битными инструкциями выигрывает в плотности кода у x86-64, а также в количестве команд.
У ARM нет таких продвинутых средств для отладки, какие есть у архитектуры x86.
О каких средствах идёт речь?
Непонятно, почему вы так удивляетесь обмену (набора) регистров за 4 такта?
Это достигается просто манипуляцией адреса регистра. Данные никуда не перемещаются.
Важен результат, а он есть — регистры меняются местами. Если для закручивание лампочки крутить стул вместе с тем, кто держит лампочку, та будет закручена. :)
Давным давно, ARM был чуть хуже чем IA-32.
Если же говорить о состоянии дел в настоящий момент, то ARMv8 с фиксированными 32-битными инструкциями выигрывает в плотности кода у x86-64, а также в количестве команд.
В статье все-таки про первые ARM-ы и они не были хуже, а скорее лучше, им не хватало только MMU и арифметического сопроцессора. Насчет плотности кода хотелось бы получить подтверждающую ссылку — сомневаюсь.
им не хватало только MMU и арифметического сопроцессор
Иии...? Как это связано с «плотностью кода»? Я отвечал на вашу цитату.
Насчет плотности кода хотелось бы получить подтверждающую ссылку — сомневаюсь.
Моя оценка на коде с которым я работаю (игры / AVX вычисления): у х86_64 уходит 4.2-4.5 байт на инструкцию. Инструкций зачастую нужно больше чем у ARMv8.
Если вы хотите академического, вот.
digitalassets.lib.berkeley.edu/etd/ucb/text/Waterman_berkeley_0028E_15908.pdf (Figure 5.8)
Есть и другие замеры — тут на SPECInt2006 получили 3,71 байт на команду.
arxiv.org/pdf/1607.02318.pdf
Вообще лучший измеритель это gcc.godbolt.com
Выбираете компилятор, например Clang 5.0 (для ARM нужно указать -target aarch64-linux-gnu), интересующий кусок кода и можно сравнивать.
Да, можно написать функцию в три строки которая будет хуже на ARM, но вычислительный код с векторами и т.п. будет лучше.
Статья хорошая и почти полная. Я бы упомянул, пожалуй, только еще совершенно революционный, широко разрекламированный и абсолютно провальный проект INTEL
IAPX 432.
Да, конечно, времена борьбы за каждый байт в ПЗУ и поиска «хитрых» способов повышения быстродействия прошли, но остались в памяти. Из приятных воспоминаний (в духе Вашей статьи) вспомнилось как не удавалось никак найти 2 или 3 лишних байта в ПЗУ, пока не применил в нескольких местах программы для обнуления аккумулятора однобайтовую команду XRA A (исключающее ИЛИ аккумулятора с самим собой) вместо двухбайтовой MVI A,00H. Или нестандартное использование выхода разрешения прерывания МП I8080 в качестве одноразрядного порта вывода с возможностью программно формировать короткие импульсы командами EI и DI…
А зачем вы изначально такое писали? Её даже писать дольше и работает она тормознее.
Обнулять аккумулятор через загрузку непосредственного значения на i8080 нужно только когда вам нужно сохранить флаги.
На современных процессорах х86 это ещё более актуально.
stackoverflow.com/questions/33666617/what-is-the-best-way-to-set-a-register-to-zero-in-x86-assembly-xor-mov-or-and/33668295
stackoverflow.com/questions/17981447/microarchitectural-zeroing-of-a-register-via-the-register-renamer-performance-v
и т.п.
Преждевременная пессимизация — очень своеобразный подход к программированию =)
Почему сразу не писать «компактно, быстро и удобно» вместо «раздуто, медленно и неудобно»?
интересно, что реально заложенные в нём идеи выстрелили только в Эльбрусе.
интересно, что реально заложенные в нём идеи выстрелили только в Эльбрусе.
хм. это какие идеи? пример?
432 претендовал на это, Эльбрус сделал. И ощутимо проще, чем это пытались сделать инженеры Интела.
Это Вам сейчас, когда уже несколько поколений программистов поделились своим опытом и знаниями с остальными такое использование XRA A кажется естественным и практически единственно возможным. Зачем делать компьютер на реле, если уже были электронные лампы? И т.д. и т.п. Почему надо было работать с какой то DOS, а не сразу «компактно, быстро и удобно» работать под WINDOWS? У меня есть ответ — потому что!
Это Вам сейчас, когда уже несколько поколений программистов поделились своим опытом и знаниями с остальными такое использование XRA A кажется естественным
Что значит «сейчас»? XOR для обнуления регистров использовался задолго до моего рождения.
Есть инструкция 1 байт, 4 такта. Зачем использовать инструкцию 2 байта, 7 тактов?
Логика же должна подсказывать что первый вариант лучше?
Вот, например, CP/M, 70е
OPENFCB XRA A
STA FCB+32
Я начинал в начале 90-х и у меня к тому времени был полноценный мануал по Z80.
www.youtube.com/watch?v=ooi9rpx6ECM
www.youtube.com/watch?v=9cSbjXAFvDg
Один кадр занимал 1 кб и состоял из 2048 блоков (4 бита на блок) в формате 64х32 (каждый блок имел размер 4х4 пикселя), что представляло собой 2/3 экрана спектрума. Дисковод читал 20 кб/с в стандартной конфигурации (16 секторов по 256 байт), что позволяло выводить 10 кадров в секунду (половина времени тратилось на чтение, половина — на вывод на экран).
Альтернативно можно было прочитанный килобайт интерпретировать как 4096 блоков по 2 бита в формате 128х32 что позволяло отображать «видео» с более мелкими пикселями (2х2), но только на 1/3 экрана.
По факту я так и не сделал ничего путного, т.к. видео надо было где-то взять и перекодировать в данный формат, а вот с этим были проблемы. Да и на диск влазило всего 60 секунд. Поэтому, дальше сгенерированных паттернов дело не зашло. А позже, уже в 2000+ году я увидел на одной из выставок как раз такое видео на спектруме в составе какой-то демки.
Ну и к слову, я как только увидел в списке команды XOR A/SUB A, сразу же понял, что их лучше использовать для зануления аккумулятора, никто мне этого не объяснял. Еще была «особенная» команда SBC A, которая позволяла поместить в А значение флага переноса во все биты.
Мне было тогда 13 или 14 лет, точнее не помню. Я ходил в «компьютерный кружок», где стояло два спектрума 48, агат-9, какая-то электроника ВМ (позже я понял, что это был IBM-совместимый компьютер) и правец-8д. Самыми лучшими считались, конечно, спектрумы. Затем шла электроника (т.к. на ней был дисковод и можно было быстро грузить игры), агат (на нем тоже был дисковод, но ничего серьезного из ПО не было) и последним был правец.
Как только я попал в этот кружок, практически сразу понял, что на бейсике ничего серьезного написать невозможно, и мы стали выпрашивать преподавателя прочитать нам курс ассемблера Z80. Он не хотел, мотивируя это тем, что это нам не нужно, все равно ничего путного из нас не выйдет. Но мы настояли, и он прочитал. Это был весьма краткий курс, включающий только основные команды процессора и общий принцип их работы. Скорее всего курс был основан на 8080, т.к., многих «новых» команд процессора там не было. Тем не менее, он дал нам толчок — позволил начать писать хоть что-то на ассемблере, а уже дальше каждый разбирался как мог сам.
По сути, ассемблер — первый ЯП, который я выучил. И считаю, что порядок изучения языков должен быть именно таким, т.к. асм дает понимание, как работает процессор и позволяет писать любые программы на любых языках эффективней.
Затем начал изучать паскаль и параллельно — ассемблер 8086. Писал ассемблерные вставки внутри паскаля — это было очень просто и эффективно, код работал в 10 раз быстрее (паскаль плохо оптимизирует). Затем перешел на 32 разряда и изредка пишу на асме х86 даже сейчас. Но сейчас это не так просто — у процессора много ресурсов, а компиляторы становятся умнее и обогнать их уже не всегда оказывается такой простой задачей.
Спасибо вам за Микро-80!
Кстати о MOS6502, у них небыло микрокода команд, все декодирование и исполнение шло через матрицу. Насколько помню я, это и давало прирост быстродействия процессору, но ограничивало его расширение.
Просто отличный материал, огромное спасибо, жаль плюс статье поставить не дает, извините.
И что значит PDP-11
так и не была введена поддержка 16-х чисел для ассемблера? Их структура команд была привязана к восмеричной системе счисления и позволяла легко программировать сразу в машинных кодах.
О! Абстракции PDP-11 позволяли довести процесс программирования до рефлексов и создавали ощущение понимания, сравнимое с аналогичным от ЯВУ. До сих пор ностальгирую по этому ощущению. Впрочем, это как первая любовь — забыть нельзя, повторить невозможно… ;)
В 80486 были улучшены тайминги большинства инструкций и некоторые из них стали выполняться как и на процессорах ARM за такт. Хотя умножение и деление почему-то стали чуть медленнее
Может по тому, что математический сопроцессор(80387) переехал в процессор?
Очень подробно. Респект. Для меня новостью была информация об относительном быстродействии архитектур. Да, кстати — насколько я понимаю, первой массовой машиной в СССР был Минск-32.
Тут интеловский 8080A был конкурентом их же 8085, и Z80 — наверно, поэтому 8085 оказался никому не нужен.
> Есть основание полагать, что GNU ассемблер для x86 делали под влиянием именно ассемблера PDP-11.
Да, но не напрямую. Сначала был порт System V на i386, сделанный AT&T. Именно в нём было принято такое решение — и множество других, напрямую склонированных с Unix ассемблера PDP-11 и VAX-11 — таких, например, как команды ассемблера, начинающиеся с точки (.byte, .word, .align...) Эти наработки были куплены и перенесены в SCO Unix. И уже под влиянием SCO был сделан GNU as.
Некоторые особенности их решений сохраняются до сих пор. Например, в AT&T отличие fsubr от fsub в том, что суффикс r означает укладку результата не в st(0), а в другой регистр — хотя в оригинальном Intel синтаксисе это означало укладку в регистр вычитаемого, а не уменьшаемого. Или, они заменили идиотски путаные обозначения Intel для команд расширений знака (кто помнит навскидку отличие cwde от cwd?) на свои такие же путаные (cltd против cltq).
> Очень странные и непредсказуемые эффекты можно получить, используя счётчик команд как обычный регистр.
У PDP-11 они как раз очень предсказуемые — порядок отработки побочных эффектов аргументов чётко задан.
80188 использовался в некоторых моделях PC XT. Но самое знаменитое его применение — это в модемах USR Courier. В бСССР для него писали прошивки с заточкой под местную специфику, пользуясь лёгкостью понимания.
> с тех пор деление делать быстрее так и не научились!
Частично научились, но это действие вообще проблемное, и на его оптимизацию не тратят усилий.
Про условные переходы:
> С 80386 стало возможным использовать смещения из двух байт
В 32-битном режиме — все 4.
> С этого процессора начинается использование страничной виртуальной памяти – сегодня это доминирующая технология.
Мнэээ… IBM 370, VAX умели страничную адресацию сильно раньше.
Про 6502… он был удачный с точки зрения внутренней конструкции, да. Но писать что-то серьёзное под него было пыткой — говорю как краевед (Агаты в школе), из-за единственного аккумулятора и постоянных конфликтов за ячейки нулевой страницы. Если бы ему дали хотя бы 3 нормальных почти универсальных 16-битных регистра, он бы точно побил всех конкурентов. Боюсь, помешали этому те же причины, что потом убили его развитие.
IBM 370, VAX умели страничную адресацию сильно раньше.Только это «сильно раньше» было без процессоров-чипов, о которых статья. 6502 очень хороший процессор, проэмулировать на нём z80 — сущий пустяк. Нужно только вместо регистров BC,DE,HL использовать 6 байт на нулевой странице. Писал коды для одинаковых программ для обоих процессоров — ссылка — 6502 более гибок и требует меньших усилий от программиста. Не забывайте, что 256 байт нулевой страницы имеют функциональность регистров, это, повторю, в частности, 128 индексных регистров. Посмотрите на команду LDA ($55,X) — тaкое на z80 не представить.
Насчет непредсказуемых эффектов PDP-11 есть хорошая тема, даю ссылку и посмотрите на материалы рядом — ссылка.
Там обсуждения конкретных совместимых с PDP-11 процессоров. Так можно и процы x86 Intel оценивать по процам x86 от AMD.
Хм, я не нашёл с ходу упоминания специфики именно 8080A, все почему-то универсально говорят про оба. OK, сочтём это за сбой памяти.
> непредсказуемых эффектов PDP-11
Про это уже ответили — неродные процессоры могли как-то лажать, но DEC, насколько я знаю, чётко держал планку.
И эти эффекты не касаются самых важных вопросов — например, порядок выбора дополнительных слов в командах типа mov #1, 20(%2).
> Только это «сильно раньше» было без процессоров-чипов, о которых статья.
Не сходится: вы VAXʼу отдельную главу посвятили.
Не принципиально, но считаю необходимым заметить.
> Посмотрите на команду LDA ($55,X) — тaкое на z80 не представить.
И смысла в ней где-то на уровне ноль целых фиг десятых. Я ещё в те времена как-то заинтересовался осмысленностью этой адресации, пересмотрел (чёрт, грепа не было, листал и глазами смотрел) код стандартных программ типа Бейсика, Школьницы — случаи были просто единичные и тупо сомнительные, в отличие от $ABCD,X или ($AB),Y — последняя вообще использовалась на каждом шагу (ну ещё бы).
Был какой-то паттерн написания, при котором именно такая адресация была полезна? Если да, я его не знаю и не использовал.
В остальном, под что легче писать — вкусовщина, но меня постоянное гоняние байтиков через аккумулятор просто доставало, особенно видя рядом вкусные аналоги типа клонов PDP-11.
Если бы конкуренты не тратили попусту по 4 такта на ерунду, тот 6502 просто не взлетел бы.
Тут хотелось бы примеров, или я чего-то не понимаю — идея стека в нулевой странице как-то особенно смущает. И чем оно так лучше варианта $ABCD, X или $ABCD, Y?
> Ассемблер PDP-11 для байтовых операций очень неуклюж.
Чем? Все основные операции, кроме ADC и SBC, есть в байтовом виде, и даже автоинкремент сделан на 1 вместо 2 (если не %6 или %7).
[PDP-11] Рассмотрим, например, CMPB #2,R1. Для байтовой константы 2 будет выделено слово (а не байт) и так будет верно для всех операций с байтовыми константами. В самом ассемблере неуклюжести это не вызывает, но если смотреть на машинные коды, то лишний 0 — это как пятое колесо. И когда памяти так мало, всего 32КБ — этот ноль чувствуется сильно. Не получится ещё без неуклюжести сравнить старший байт R1 с той же 2.
А где его вообще можно так сравнить? 8086 с его отдельными AH...DH не в счёт, этот подход 1) нигде больше не применяется из известных архитектур, даже современников PDP-11, 2) даже в x86 не распространён ни на старшие 16 из 32, ни на старшие 32 из 64, ни на какие промежуточные случаи.
Везде одно и то же: регистр считается целой сущностью, которая может рассматриваться с меньшей разрядностью, чем его полная, но только в младшей части. И современные компиляторы это поддерживают: они (особенно SSA-based, то есть чуть менее, чем все сейчас) рассматривают любой регистр целиком, а не по частям, даже если используют из него 8 бит из 64. Хотите работать с другими частями регистра — ok, извлекайте и вкладывайте сдвигами.
ARMʼовцы по этому поводу писали по поводу изменения ARM/64: там S0=D0, S1=D1, ..., в отличие от ARM/32, где D0 состоял из S0 и S1, D1 из S2 и S3, и так далее — мол, «в компиляторах ради старой схемы приходилось вводить кучу грязных хаков, теперь мы ушли от этого».
> Можете посмотреть конкретные коды по ссылке (там можно поискать слово fetch).
Прикольно, но там кладут адрес адреса стека в X. Если несколько стеков, обрабатываемых идентичным кодом, в этом есть ещё какой-то смысл. Если нет, можно точно так же через ($NN),Y при Y==0 получить результат не хуже, а возможно и быстрее, насколько я помню 6502.
И где эта способность реально используется? Сейчас кода, который написан вручную на ассемблере, дай бог чтобы 1/100000 от всего исполняемого. Всякие переходники сисколлов и обработчиков прерываний не считаю, там данные возможности тем более не используются. Остальное — автогенерированное. А в выхлопе современных компиляторов, если вы найдёте использование регистров типа ah, bh, то это специальные готовые вставки на редчайшие особые случаи.
Или вы про то, что где-то может быть вставлены операции типа «add al, dl»? Это тоже, насколько вижу, редчайший случай, и принципиально ничем не быстрее того, что если бы в ARM или другом RISC сложили полные слова, даже если важна только их младшая часть.
C и С++ со своими правилами «перед всеми арифметическими операциями всё, что короче int, расширяется до int» помогают в эту же сторону.
Вы знаете какую-то среду, которая всерьёз реально использует короткие типы (8 и 16 бит) без расширения и её компиляция в x86 выполняет операции без расширения, и это реально помогает и является частым случаем в использовании? Если да — поделитесь. Я долго пытался подобрать такую, не нашёл.
Что же касательно лидерства x86 — с моей точки зрения, на 99% это результат обеспечен Microsoftʼом с его более-менее стабильным Windows ABI (на уровне *.lib). Иначе бы эта архитектура, в которой авторы системы команд отказываются думать более чем на полшага вперёд, вымерла бы ещё лет 20 назад. (Собственно Intel сам хотел её убить, но его альтернатива оказалась ещё хуже, и поэтому судьба детоубийцы их не настигла.)
> У ARM-32 встоенный в почти каждую команду barrel shifter, который даёт мгновенный доступ к каждому байту слова. У ARM-64 с этим хуже и, возможно, что так Intel ослабляет конкуренцию c x86.
У ARM-64 то же самое есть в достаточном количестве, мне кажется. И у них очень современная реализация с устранением огромного количества тех идей, которые растут из 80-х годов или ещё раньше, но перестали быть актуальными сейчас. Если сравнивать с x86, которая несёт в себе тонны раритетов ещё 70-х, ARM это бриллиант прогрессивного дизайна (во завернул;))
Это не так. Вот пример кода, где GCC генерирует использование второго байта регистра, например, BH.
char c;
register union {
int a;
char b[4];
} a;
c = a.b[1];
Есть результат: x86 — самые быстрые и с лучшим ПО (Linux на x86 также лучший) — всё остальное лирика. Поклоники VAX очень их и ARM не любят — сломали их малину. Когда-то и восстания луддитов были.:) ARM сейчас лучше только по энергопотреблению. Если бы у Acorn когда-то был посильнее менеджмент, то у них был шанс опрокинуть x86. Когда-то они также в СССР позорно проиграли с ICL 1900 в пользу IBM/360 — у нас решили лучше у американцев воровать, чем с честными англичанами иметь дело — нашли подход к «загадочной» русской душе. :) ARM-64 как и RISC-V какой-то более выхолощенный — не догнать с этим x86. Повторю, современный ARM развивается с оглядкой на Intel.
www.wang2200.org/iskra-226.html
> Все основные операции, кроме ADC и SBC, есть в байтовом виде
Необходимость в байтовых сложениях, видимо, её авторами сочтена меньшей, чем в чём-то другом — поэтому именно ADCB, SBCB уже не получили кода. Ну не хватило кодов на всех.
С современной точки зрения, можно было бы сделать как в x86 — команды вида mem op= reg или reg op= mem, но не mem op= mem; можно было бы сделать только второе (как в S/360); можно было бы сделать команды из 4 байт… но для 1970 это всё было явно избыточно.
Мне лично простановка CC по MOV кажется в разы большей диверсией, чем эти мелочи.
Сам сталкивался с 6502 (точнее 6510), 6809, tms9900, 8048, cp1610, x86.
Больше всего кода написал для x86 (8086-80486), но писать под него, на мой взгляд, неприятно (как и вообще под архитектуру PC, куда эти процессора ставились).
Больше всех понравился, пожалуй, 6809. На втором месте 6502.
Чуть-чуть потрогал sparc — там интересна идея регистровых окон. Трогал также 8080 и z80, но душа к ним не легла.
О программировании под 68000 от людей слышал почти исключительно хорошие отзывы, завидовал (в те времена, когда я сидел на PC, а знакомые на Amiga).
Автор что-то путает.
Acorn Archimedes очень даже использовались в Британских школах.
Компьютер был очень продвинутый. У нас в институте было несколько комплектов. К компьютеру прилагался лазерный видеопроигрыватель для LaserDisk (полноразмерные лазерные диски 30 см, содержали 54000 изображений или около часа видео на сторону, причем это не компреcсированное видео - просто каждый кадр записан, как audio compact disk) - в компьютере была установлена микширующая плата - на мониторе можно было проигрывать, управляя с компьютера, видео или стопкадр с диска, а поверх накладывать компьютерное изображение с маской (в отличие от скажем плат типа screen machine для PC тех лет). Кроме того в компьютере была стерео 16 битная звуковая карта ! Использовалась собственная RISC OS с окнами, таскбаром внизу и тп. Также прилагались диски образовательного содержания для школьников. Тога это все было просто космос, потому что те же CD для PC только появились и были редкими и односкоростными, звуковухи обычно 8 бит моно и тп. А тут качество видео и изображений идеальное, до которого дошли только во времена DVD.
Я программил под эти компы. Помню там были весьма извратные видеорежимы с 256 цветами, причем 4 бита это номер цвета из палитры, а 4 бита - модификация RGB цвета из палитры, чтобы типа можно было делать гуй под любую палитру.
Крутой был у вас Архимедик, когда это было? Мне показали в 1991 голую машину, но и это было потрясающе. А в Англии Архимедов было не совсем мало, но и совсем не много тоже. В школы они шли, но IBM PC шло туда больше. Естестсвенно, они же захватили и большую часть рынка офисных систем. А на секторе домашних компиков, американцы устроили какой-то демпинг с амигами, продав их Британии больше, чем в США. В США они почему-то их продавали очень вяло, наверное были у них свои распилы с Apple и IBM.
Косвенный JMP вообще был крайне редко используемой инструкцией в 6502. Много, если в целой программе была одна такая инструкция. А так чтобы ещё адрес попал на границу страниц – это практически невероятно. К тому же легко избегаемо, так как программы писались в абсолютных адресах, и это всегда можно было проконтролировать. Так что проблема с багом в 6502 очень преувеличена.
Развитию 6502 помешало то, что компьютер Apple IIgs, сделанный на базе 65816, был вытеснен агрессивно продвигаемым Джобсом Макинтошем. Семейство Apple II к тому времени уже накопило ряд наследственных проблем, а Макинтош был сделан с нуля и на базе более быстрого 32-разрядного процессора 68000. Хоть он и был чёрно-белым, а Apple IIgs имела экстраординарную по тому времени видеосистему с 65536 цветами, но в целом Мак воспринимался лучше.
Стоит ещё отметить, что часть тактов в большинстве систем с z80 или 6502 отбирается у процессора схемами поддержки генерации видеосигнала
Для 6502 стандартным решением было предоставление оперативной памяти процессору в одной полярности тактовой частоты, а видеоконтроллеру – в другой. Поэтому процессор и видеоконтроллер не конкурировали между собой, и такты не терялись.
iigs появился просто слишком поздно, когда 6502 был уже глобоко зарыт. Но как контроллер он и до сих пор в деле!
Да.
А что касается косвенного JMP, то программисты 6502 скорее использовали бы вместо него самомодифицирующийся код с прямым JMP, выполняющийся 3 такта вместо 5 и занимающий 3 байта вместо 5. А если нужна была бы таблица адресов, то использовали бы загрузку байтов адреса по индексу в аккумулятор, проталкивание в стек и RTS. Так как косвенный JMP сам по себе не позволял использовать индексную адресацию.
В ПЗУ Apple ][ была пара косвенных JMP для обработки векторов прерываний, но они указывали на конкретные адреса в нулевой странице.
Для 6502 стандартным решением было предоставление оперативной памяти процессору в одной полярности тактовой частоты, а видеоконтроллеру – в другой. Поэтому процессор и видеоконтроллер не конкурировали между собой, и такты не терялись.
Это не совсем так. С развитием видео там стало тактов не хватать. В Коммодоре 64 и особенно 264 (и в Атарях тоже) процессор переодически останавливают. В BBC Micro решили проблему, подняв частоту, но это потребовало дорогой памяти (и наличию пустых тактов) , что привело к тому, что её ставили только 32 К.
насколько я понял, читая документацию по ассемблеру stm8 и отсылкой на ассемблер st7 - это ядро является развитием 6502 или поздней модификации 650х.
используют 2 индексных регистра IX, IY, аккумулятор.
правда сейчас детали не помню.
Эмоциональная история процессоров для первых компьютеров с 70-х до начала 90-х