Комментарии 162
НЛО прилетело и опубликовало эту надпись здесь
Очень жалко, что не упомянули IBM360/370. До сих пор с ужасом вспоминаю правила использования регистров 13, 14, 15 при вызове и возврате из процедур.
Это не микропроцессоры.
Писал на ЕС-1045 лабораторные на ассемлере и Рефале…
Я всякие трансформации МГД-волн на фронтах ударных волн считал для диссертации по астрофизике. Ночами с пульта EC-1055M. Ну а в качестве компенсации и хобби, чего уж скрывать, помогал с СВМ (это минский перевод на русский VM/SP) местному сисадмину. Когда то и ядро умел пересобрать, и следующую версию СВМ запустить на виртуалке предыдущей версии. И инструкцию к машине (на немецком) понять. Да и девочек-операторов «поблагодарить» :)
Спасибо за интересную статью, прочитал с большим удовольствием.
Безусловно, что одним из самых лучших процессоров, из сделанных в 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.
Про z8000 почти ничего не знаю. Будет интересно, если сообщите что-нибудь о том, почему этот процессор так и не состоялся фактически.
1. Большинство этих режимов мало что значат. Они скорее о формате выходного файла COM или EXE. Вот если нужны были большие массивы, то надо было выбирать режим Huge — это замедляло. Но к концу 80-х, когда стало для этого у многих хватать памяти, уже были доступны системы для работы в 32-разрядном режиме, в котором этой проблемы уже не было, хотя и заметно тормозился ввод-вывод. Конечно, это уже про 80386. Могу ещё заметить, что указание режима Tiny позволяло получать самые компактные коды, без загрузчика, благодаря именно сегментным регистрам. И вроде бы нет особой проблемы в том, чтобы один раз указать режим. Cкорее могло напрягать использование директив FAR и NEAR, но скорее только начинающих. В современных процессорах много режимов, хотя скорее чисто системных.
2. Иметь как-бы защищенные режимы без защиты памяти вещь абсолютно бесполезная, это только делало архитектуру бессмысленно более громоздкой.
3. Согласен, что теоретически система команд 68000 более продвинутая, но когда дело доходит до практического программирования, то 8086 часто (пусть и не всегда) оказывается лучше. Ну и что, что для счётчика можно использовать только CL — проблема возникнет, только если нужно сразу несколько таких счётчиков, больших 1 — это возможно, но скорее редко, чем часто. Было интересно получить ссылки на какие-нибудь данные, указывающие, что код для 68000 более компактен, чем для 8086. У меня обратная информация, например, программка для вычисления числа π для 8086 почти в полтора раза меньше (примерно 650 байт против более 900). У 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 она была.
Посмотрел в википедии — непонятно там про MMU у z8000. Вроде есть что-то для работы с виртуальной памятью, но ничего нет по защите памяти, её организации. Сомневаюсь, что y Z8000 полноценное MMU как у 80286.
Конечно, у 68000 больше регистров и это на некоторых задачах может давать более компактный код. Но инструкции у х86 могут быть любой длины, например, 1 или 3 байта. А у 68000 все выравнено по границе 4 байта. У архитектуры х86 тут большое преимущество.
Конечно, у 68000 больше регистров и это на некоторых задачах может давать более компактный код. Но инструкции у х86 могут быть любой длины, например, 1 или 3 байта. А у 68000 все выравнено по границе 4 байта. У архитектуры х86 тут большое преимущество.
Был MMU: sci-hub.tw/10.1016/0745-7138(83)90028-3
Это было причиной популярности z8000 для построения low-end unix серверов.
Это было причиной популярности z8000 для построения low-end unix серверов.
Не согласен на счёт сегментной организации. Виртуальное адресное пространство тоже в каком-то смысле "сегмент".
z8000 вполне состоялся, на нем хватало коммерческих продуктов, был относительно популярен у военных, дожил до 90х.
Широкого распространения не получил, т.к. был совместим сам с собой и не попал ни в один из популярных компьютеров 80х.
Широкого распространения не получил, т.к. был совместим сам с собой и не попал ни в один из популярных компьютеров 80х.
z8000 «состоялся» убив возможное развитие семейство z80. Если мне не изменяет память то нанятый разработчик процессора с полной свободой действий помножил на ноль любую совместимость, не только бинарную, но и формальную — на уровне мнемоник ассемблера, создав процессор с системой команд, а'ля VAX. Возможно это городская легенда, но когда я читал книжку по микропроцессорам в начале 90-х z8000 выглядел бледно на фоне 286 и 68000.
Большинство этих режимов мало что значат. Они скорее о формате выходного файла 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-битными адресами для кода и/или данных приходилось пользоваться только в тех программах, где это действительно было нужно, а не во всех без исключения.
НЛО прилетело и опубликовало эту надпись здесь
Прикольно. Помню тоже писал такие статьи в журнале ЧипНьюс в далеком двухтысячном году. Только про 8 и 16-разрядные микроконтроллеры.
А 4-разрядные что ж забыли? Наши К145ИК18/19 с разными прошивками. Ихний TMS1000.
А ссылку не дадите?
а чего-то, оказывается сохранилось.
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
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
«Это, конечно, Радио-86РК, Микроша, многоцветные Орион-128, Вектор и Корвет.»
«Специалист» забыли.
«Специалист» забыли.
«Орион» сделан из «Специалиста» добавлением RAM-диска.
Извините, даже и не знал про такой.
Спектор-001. в инструкции было написано, что программно совместим с Радио-РК86.
Забыли первый любительский комп — РадиоМикро80. Журналы Радио конца 1982 и весь 83. Огромный по сравнению с тем же Р86рк, но тем не менее первый спаянный и оживший…
Читая всё это, так и вспоминается сериал HCF (Halt and Catch Fire). Там мелкая контора чуть ли не в гараже хочет вытеснить IBM с рынка ПК, ставя на оптимизированную схемотехнику и оптимизированный BIOS, который в маш. кодах пишет хипповато-асоциальная студентка.
Мне довелось программировать на ассемблерах разных процессоров. Последний в списке – это Xilinx MicroBlaze.
Вы его точно на ассемблере программировали? Microblaze — это ж ПЛИСовый процессор из EDK. Программируется в SDK на Си. А в XPS процессор вроде только конфигурируется.
Очень сильный обзор, спасибо.
Извините, как-то забыл про наш Агат. Добавил абзац.
А как же SPARC? Ведь он тоже тех же времен.
А вообще — обзор очень хороший.
А вообще — обзор очень хороший.
Благодарю за добрые слова. Однако, sorry, не случилось поработать. :( Слышал только, что там как-то уникально на аппаратном уровне устроена работа с параметрами функций. И в первой половине 90-х в встречал несколько раз в Москве — техника выглядела очень сильно.
В sparc-е множество регистров, объединенных в пересекающиеся блоки, что позволяло передавать до восьми параметров функции не залезая в память. Кстати, на моей аватарке за моей спиной sparcstation десятка.
Ах, да, были же еще PowerPC, с которого долго не могла сползти Apple, был i860 с короткой и странной судьбой.
Еще MIPS, IA64, DEC Alpha (первый процессор на 1ГГц).
Еще все эти гарвардские 8048/8051, ломающие шаблоны.
Еще все эти гарвардские 8048/8051, ломающие шаблоны.
IA64, DEC Alpha — это уже позднее. Я имел в виду процы, которые были не позднее 486, на котором примерно автор остановился.
8048/8051 — это все-таки не процессоры общего назначения, а контроллеры для «встраиваемых систем» (вроде как вместе с этим семейством MCS-51 и появилось понятие «встраиваемых систем». хотя могу ошибаться).
C i860 все просто — согласно официальным источникам, В Интел не могли предугадать, что окажется востребованным — дальнейшее развитие x86 или risc. Вот и «выкатили» оба…
Сохраняется ещё интрига вокруг инструкции 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 (Агат-9), на факультативе — на асме Z80 (Yamaha MSX-2). Почему-то Z80 нравился больше.
Может потому, что на ПК Yamaha графика была лучше, а звук намного лучше?
Нет, переход на 6502 был как "связывание рук".
Очень интересно. Вы писали, что перешли с 6502 на z80. Был бы очень признателен за пример, иллюстрирующий скорее «развязывание рук».
Не на z80, а писал попеременно для 580, 6502 и pdp-11 (z80-очень редко, баловство с синклером, 48/51 — почаще, в т.ч. писал кросс-средства для них). pdp-11, на мой взгляд, лучший из ассемблеров. ну а разница между 580 и 6502 — например, в количестве регистров.
Писал уже об этом, но повторю для вас. У 6502 память нулевой страницы имеет функциональность регистров. Согласен, что если не думать о производительности, то ассемблер PDP-11 хорош. Думаю, вам бы понравился ассемблер Motorola 680x0. Возможно и ARM тоже понравился — там было изначально менее 30 инструкций. И не совсем понял про 580 — что это процессор?
Да, про память знал — но всё равно по сравнению с регистрами — это иной стиль. Поэтому было менее удобно. Возможно, это дело привычки и "закрепившегося" стиля… 580-й — это советский 8080. Про 68000 читали в обзорах (приходили на кафедру переплетённые ксерокопии), было интересно — но до практики дело не дошло.
Использовать нулевую страницу 6502 в качестве «почти регистров» не годилось. Проблема в том, что, говоря современным термином, регистры бывают общего назначения и служебные (в x86 последние это то, что MSR), так вот нулевая страница несла оба набора, и все участвующие использовали какие-то её ячейки непредсказуемым образом (надо было вычислять по исходникам).
Для полностью самостоятельного приложения, которое берёт на себя всю работу с аппаратной частью и вокруг, это было неважно. А вот если хотел сделать что-то такое, что и было хитрое на ассемблере, и сочеталось даже просто с местным бейсиком (хотя бы не сломать его по выходу из своего кода!) — уже возможность использовать нулевую страницу резко сокращалась. А какая-нибудь Рапира использовала её реально всю — оставляя только несколько ячеек нетронутыми — причём какие именно, документация подвирала.
Да, с этим можно было банально не столкнуться. Но с тех пор утверждение «нулевая страница это те же регистры» вызывает у меня только саркастическую ухмылку — и применяется как объяснение, почему процессору нужны настоящие регистры, а не суррогаты.
Для полностью самостоятельного приложения, которое берёт на себя всю работу с аппаратной частью и вокруг, это было неважно. А вот если хотел сделать что-то такое, что и было хитрое на ассемблере, и сочеталось даже просто с местным бейсиком (хотя бы не сломать его по выходу из своего кода!) — уже возможность использовать нулевую страницу резко сокращалась. А какая-нибудь Рапира использовала её реально всю — оставляя только несколько ячеек нетронутыми — причём какие именно, документация подвирала.
Да, с этим можно было банально не столкнуться. Но с тех пор утверждение «нулевая страница это те же регистры» вызывает у меня только саркастическую ухмылку — и применяется как объяснение, почему процессору нужны настоящие регистры, а не суррогаты.
Вы о том, что некоторые системы использовали почти всю нулевую страницу. Это плохо. На некоторые системы не хватало документации — тоже нехорошо. Но причем тут сам процесор?! Некоторые системы использовали и многие регистры, например, ZX Spectrum использовал регистр IX, а Amstrad CPC — весь альтернативный набор регистров. В TMS9900 получается, что все адресные регистры и регистры данных — это суррогаты. В современных системах, когда обращение к памяти проходит очень быстро, можно вообще без регистров и такие архитектуры используются. Другое дело, что в системе должно быть достаточно быстрой, успевающей за процессором памяти. Регистры, конечно, повышают плотность кодов. Но архитектура Spark с более чем сотней регистров не стала преобладающей.
> Но причем тут сам процесор?!
При том, что его иначе использовать в этих условиях было невозможно (чрезмерно дорого). И размер нулевой страницы, и громоздкость временной заливки данных в неё и вылива обратно — провоцировали абьюзить её, используя под то, что в нормальных системах не сидит постоянно в регистрах.
> Но архитектура Spark с более чем сотней регистров не стала преобладающей.
Вы с IA-64 не путаете? SPARC имел с точки зрения пользовательского кода 32 регистра (включая пустой). Системному позволялось видеть полный ротор регистров, но к вопросу плотности обычного кода это уже не относится.
При том, что его иначе использовать в этих условиях было невозможно (чрезмерно дорого). И размер нулевой страницы, и громоздкость временной заливки данных в неё и вылива обратно — провоцировали абьюзить её, используя под то, что в нормальных системах не сидит постоянно в регистрах.
> Но архитектура Spark с более чем сотней регистров не стала преобладающей.
Вы с IA-64 не путаете? SPARC имел с точки зрения пользовательского кода 32 регистра (включая пустой). Системному позволялось видеть полный ротор регистров, но к вопросу плотности обычного кода это уже не относится.
В каких условиях? Что дорого? В любых нормальных системах, с которыми работал всегда можно было найти более 16 свободных ячеек на нулевой странице. Положить туда байт — 5 тактов, адрес — 10 тактов. 256 байт для 8-биток — это не так уж и мало. К сожалению, не довелось поработать с Рапирой или Школьницей — интересные системы — может когда-нибудь и получится. Возможно, что там в чем-то «перестарались».
Это особенность Агата.
На Apple II была табличка в документации, на которой было расписано использование нулевой страницы. Часть ячеек были неиспользуемыми, а большинство использовалось Бейсиком, и их тоже можно было использовать в своей программе на ассемблере. Только небольшое количество ячеек использовалось Монитором, их не надо было трогать.
На практике нулевая страница была эквивалентна 128 16-разрядным регистрам, из которых где-то 80 можно было использовать.
специальное адресное пространство для портов ввода-вывода размером 64 КБ (y 8080 и z80 этот объем – 256 байт).
Для z80 есть возможность адресовать все 64к портов ввода-вывода:
Команды с непосредственной адресацией IN A,(n) и OUT (n),A аналогичны командам
ввода-вывода МП I8080. Но в добавление к адресу порта n, выставляемому в младшую часть шины адреса, в старшую часть ША подается содержимое аккумулятора.
Действительно, и знал вроде об этом…
По этой причине OUT (n), A редко подходила для адресации таких портов, а вот комбинация LD A, nh; IN A, (nl) — использовалась постоянно, особенно при опросе клавиатуры ). Альтернативой было LD BC, NN; IN A, ( C ), но, если помню верно, предыдущий вариант выполнялся за 14 тактов, этот — за 18, поэтому, если старшие 8 бит адреса порта не надо было сохранить «на будущее», вариант с IN A, (n) был предпочтительней.
Непонятно, почему вы так удивляетесь обмену (набора) регистров за 4 такта?
Это достигается просто манипуляцией адреса регистра. Данные никуда не перемещаются.
Давным давно, ARM был чуть хуже чем IA-32.
Если же говорить о состоянии дел в настоящий момент, то ARMv8 с фиксированными 32-битными инструкциями выигрывает в плотности кода у x86-64, а также в количестве команд.
О каких средствах идёт речь?
Это достигается просто манипуляцией адреса регистра. Данные никуда не перемещаются.
Другой недостаток 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, но вычислительный код с векторами и т.п. будет лучше.
«Стагнация» 6502 во многом связана с реализацией контроллера дисковода Apple II. Возняк сделал его красиво и очень просто, но привязка к таймингам исходного процессора делала невозможной увеличение тактовой или оптимизацию команд.
Был еще 4004интел, но мы его не стали встраивать ( тема была приборчик делали ) а поставили тогда 580 серию в которой уже и интерфейсы были.
Автор как-то прошел совсем мимо военного применения микропроцессоров… думаю многие «недоговорки» были свзаны именно с этим. В частности, емнип, товары с моторолловскими 68000 были запрещены к поставкам в СССР вообще. А наш 580ВМ80 до сих пор на службе ПВО (в комплексах С300)
Очень интересная статья, спасибо! Вот только тема процессоров АРМ раскрыта не полностью. Недавние исследования кристаллов процессоров АРМ выявили в них микротрансляцию инструкций на уровне PLA (декодирование инструкций). Очень хорошо эта тема раскрыта в блоге Кена Шерифа. В частности, здесь. А вообще, хотелось бы вторую часть статьи про АРМ процессоры. Также, никак не затронута архитектура MIPS.
Благодарю за ссылку.
Внёс много добавлений по теме ARM…
Статья просто чудо! Обожаю такие обзоры, Спасибо. Вот только, почему-то, нет никаких упоминаний про архитектуру MIPS. А тем не менее, она берёт своё начало в далёком 1985м году и на сегодняшний день очень активно используется в маршрутизаторах, ADSL модемах и подобных устройствах. Также, использовалась в игровых консолях Nintendo64, Playstation и Playstation 2. Точных данных о реальной рыночной доле не имею, однако, доподлинно осведомлён о наличии подобных процессоров в Zyxel Keenetic Giga, ASUS ADSL и ещё нескольких маршрутизаторах, которые раздербанил на запчасти самолично.
Одной из особенностей применения микропроцессоров является то, что он в большинстве случаев не является самодостаточным изделием (в отличии от микроконтроллеров). Он требует ряда внешних схем для своей полноценной работы. Начиная с 70-х годов, да и по-сути по настоящее время фирмы выпускают не просто микропроцессоры, а микропроцессорные наборы. Одной из важных причин доминирования микропроцессоров INTEL является то обстоятельство, что совместно с МП фирма сразу предложила большой набор совместимых с микропроцессором чипов позволяющих создать законченную систему, не мучаясь с собственной разработкой. На мой взгляд это один из важных факторов выбора фирмой IBM МП I8088 для своего ПК. На материнской плате IBM PC кроме МП имелось несколько чипов производства INTEL. Помню, как пришлось напрягаться при разработке Микро-80 не имея ничего кроме собственно микропроцессора.
Статья хорошая и почти полная. Я бы упомянул, пожалуй, только еще совершенно революционный, широко разрекламированный и абсолютно провальный проект INTEL
IAPX 432.
Да, конечно, времена борьбы за каждый байт в ПЗУ и поиска «хитрых» способов повышения быстродействия прошли, но остались в памяти. Из приятных воспоминаний (в духе Вашей статьи) вспомнилось как не удавалось никак найти 2 или 3 лишних байта в ПЗУ, пока не применил в нескольких местах программы для обнуления аккумулятора однобайтовую команду XRA A (исключающее ИЛИ аккумулятора с самим собой) вместо двухбайтовой MVI A,00H. Или нестандартное использование выхода разрешения прерывания МП I8080 в качестве одноразрядного порта вывода с возможностью программно формировать короткие импульсы командами EI и DI…
Статья хорошая и почти полная. Я бы упомянул, пожалуй, только еще совершенно революционный, широко разрекламированный и абсолютно провальный проект INTEL
IAPX 432.
Да, конечно, времена борьбы за каждый байт в ПЗУ и поиска «хитрых» способов повышения быстродействия прошли, но остались в памяти. Из приятных воспоминаний (в духе Вашей статьи) вспомнилось как не удавалось никак найти 2 или 3 лишних байта в ПЗУ, пока не применил в нескольких местах программы для обнуления аккумулятора однобайтовую команду XRA A (исключающее ИЛИ аккумулятора с самим собой) вместо двухбайтовой MVI A,00H. Или нестандартное использование выхода разрешения прерывания МП I8080 в качестве одноразрядного порта вывода с возможностью программно формировать короткие импульсы командами EI и DI…
«однобайтовую команду XRA A вместо двухбайтовой MVI A,00H.»
А зачем вы изначально такое писали? Её даже писать дольше и работает она тормознее.
Обнулять аккумулятор через загрузку непосредственного значения на 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
и т.п.
Преждевременная пессимизация — очень своеобразный подход к программированию =)
Почему сразу не писать «компактно, быстро и удобно» вместо «раздуто, медленно и неудобно»?
А зачем вы изначально такое писали? Её даже писать дольше и работает она тормознее.
Обнулять аккумулятор через загрузку непосредственного значения на 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
и т.п.
Преждевременная пессимизация — очень своеобразный подход к программированию =)
Почему сразу не писать «компактно, быстро и удобно» вместо «раздуто, медленно и неудобно»?
iapx432 — уникальное явление. знать про него очень полезно.
интересно, что реально заложенные в нём идеи выстрелили только в Эльбрусе.
интересно, что реально заложенные в нём идеи выстрелили только в Эльбрусе.
интересно, что реально заложенные в нём идеи выстрелили только в Эльбрусе.
хм. это какие идеи? пример?
«А зачем вы изначально такое писали?»
Это Вам сейчас, когда уже несколько поколений программистов поделились своим опытом и знаниями с остальными такое использование XRA A кажется естественным и практически единственно возможным. Зачем делать компьютер на реле, если уже были электронные лампы? И т.д. и т.п. Почему надо было работать с какой то DOS, а не сразу «компактно, быстро и удобно» работать под WINDOWS? У меня есть ответ — потому что!
Это Вам сейчас, когда уже несколько поколений программистов поделились своим опытом и знаниями с остальными такое использование XRA A кажется естественным и практически единственно возможным. Зачем делать компьютер на реле, если уже были электронные лампы? И т.д. и т.п. Почему надо было работать с какой то DOS, а не сразу «компактно, быстро и удобно» работать под WINDOWS? У меня есть ответ — потому что!
Это Вам сейчас, когда уже несколько поколений программистов поделились своим опытом и знаниями с остальными такое использование XRA A кажется естественным
Что значит «сейчас»? XOR для обнуления регистров использовался задолго до моего рождения.
Есть инструкция 1 байт, 4 такта. Зачем использовать инструкцию 2 байта, 7 тактов?
Логика же должна подсказывать что первый вариант лучше?
Вот, например, CP/M, 70е
OPENFCB XRA A
STA FCB+32
Как бы Вами объяснить различие в доступности информации в конце 70-х и сейчас? Если у Вас на руках имеется только несколько страниц с системой команд судорожно и неаккуратно вырванных из единственного мануала INTEL на выставке в 1978, пока фирмач отвлекся (было, что греха таить), то все остальное придется додумывать самому. Это сейчас Вы можете посмотреть — а как там обнулял аккумулятор Гарри Килдалл в CP/M или что за загадочная структура — FCB.
Посмотрел ваши публикации, вопрос снят =)
Я начинал в начале 90-х и у меня к тому времени был полноценный мануал по Z80.
Я начинал в начале 90-х и у меня к тому времени был полноценный мануал по Z80.
Ну и времена были. Помню в ГПНТБ в конце 80-х вместо зарубежных исходных материалов часто был только их ужасный машинный перевод на русский. А что было в 70-е — время легенд!
В то время изучение даже двоичных файлов было обычным делом. Однажды я увидел у друга на РС проигрыватель MOD файлов. Мне очень понравился звук по сравнению с моим спектрумовским AY. Спустя какое-то время я приделал к своему ZX две ВВ55А, четыре 8-битных ЦАПА и захотел сделать плеер MOD файлов. Но как, ведь описания формата не было вообще? Пришлось разбираться в файле просто глядя на двоичные данные. И в итоге за месяц плеер я все-таки сделал. У меня был самодельный апгрейд до 256 Кб, но и этого явно не хватало для большинства MOD файлов, поэтому я придумал такой «хак» — если памяти для загрузки очередного семпла не хватает, плеер берет самый большой семпл и сжимает его в два раза, помечая, что воспроизводить его надо медленней. В итоге мой плеер играл даже MOD объемом до 720 Кб (больше на дискету не влазило). Частота дискретизации выходного сигнала получилась невысокой — около 8 КГц, но даже это было в то время невероятным счастьем.
Круто! Вы бы ещё видеостример добавили. Это, кстати, реально www.youtube.com/watch?v=KXe7x8xoSnE
www.youtube.com/watch?v=ooi9rpx6ECM
www.youtube.com/watch?v=9cSbjXAFvDg
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+ году я увидел на одной из выставок как раз такое видео на спектруме в составе какой-то демки.
Один кадр занимал 1 кб и состоял из 2048 блоков (4 бита на блок) в формате 64х32 (каждый блок имел размер 4х4 пикселя), что представляло собой 2/3 экрана спектрума. Дисковод читал 20 кб/с в стандартной конфигурации (16 секторов по 256 байт), что позволяло выводить 10 кадров в секунду (половина времени тратилось на чтение, половина — на вывод на экран).
Альтернативно можно было прочитанный килобайт интерпретировать как 4096 блоков по 2 бита в формате 128х32 что позволяло отображать «видео» с более мелкими пикселями (2х2), но только на 1/3 экрана.
По факту я так и не сделал ничего путного, т.к. видео надо было где-то взять и перекодировать в данный формат, а вот с этим были проблемы. Да и на диск влазило всего 60 секунд. Поэтому, дальше сгенерированных паттернов дело не зашло. А позже, уже в 2000+ году я увидел на одной из выставок как раз такое видео на спектруме в составе какой-то демки.
Ну пусть даже инфы в такой доступности в то время не было. Но должна же быть логика! Уж сколько байт занимает команда-то должно быть известно! Ну и дальше почти очевидно, что двухбайтовая команда будет выполняться медленнее однобайтовой, хотя, тут могут быть исключения связанные с АЛУ. Когда я начинал программировать на спектруме, информации по тактам всех команд у нас тоже не было. Так я писал программу, где испытывал неизвестную команду многократно и смотрел на время её выполнения. Таким образом, я получил полную растактовку всех команд процессора (повезло, что мы работали уже на «новых» клонах спектрума, где не использовался сигнал WAIT при обращении к памяти и все команды всегда выполнялись строго определенное время). А еще, чтобы узнать все возможные команды процессора (т.к. доки полной тоже ведь не было), я просто вводил байты 0х00 — 0хFF и дизассемблировал результат. Таким образом удалось узнать парочку «новых» команд. Потом еще ведь и выяснял таким же образом, что они делают =)
Ну и к слову, я как только увидел в списке команды XOR A/SUB A, сразу же понял, что их лучше использовать для зануления аккумулятора, никто мне этого не объяснял. Еще была «особенная» команда SBC A, которая позволяла поместить в А значение флага переноса во все биты.
Ну и к слову, я как только увидел в списке команды XOR A/SUB A, сразу же понял, что их лучше использовать для зануления аккумулятора, никто мне этого не объяснял. Еще была «особенная» команда SBC A, которая позволяла поместить в А значение флага переноса во все биты.
В Одессе говорят — «Чтоб я был такой умный как моя жена потом». Ноль — эта константа, которая ничем не отличается от любой другой. Когда Вам регистре, например B, нужно загрузить константу, Вы наверное пишите — MVI B,0 и тому, кто читает Вашу программу все ясно без комментариев. Так Вы поступаете всегда, пока Вам не надо загрузить 0 в аккумулятор. XRA A, SUB A — это отступление от правил и требует небольшого, но дополнительного осознания — Ааа, да тут просто обнуляется аккумулятор. В любом случае, я рад за Вас — за Ваше нестандартное мышление! Просто дополнительный вопрос — а сколько Вам было лет, когда Вы начали программировать в кодах и на ассемблере?
Ну так эффективное программирование на ассемблере само по себе требует не столько дополнительного осознания, сколько четкого представления всех имеющихся ресурсов процессора и понимания, как их грамотно распределить для решения поставленной задачи.
Мне было тогда 13 или 14 лет, точнее не помню. Я ходил в «компьютерный кружок», где стояло два спектрума 48, агат-9, какая-то электроника ВМ (позже я понял, что это был IBM-совместимый компьютер) и правец-8д. Самыми лучшими считались, конечно, спектрумы. Затем шла электроника (т.к. на ней был дисковод и можно было быстро грузить игры), агат (на нем тоже был дисковод, но ничего серьезного из ПО не было) и последним был правец.
Как только я попал в этот кружок, практически сразу понял, что на бейсике ничего серьезного написать невозможно, и мы стали выпрашивать преподавателя прочитать нам курс ассемблера Z80. Он не хотел, мотивируя это тем, что это нам не нужно, все равно ничего путного из нас не выйдет. Но мы настояли, и он прочитал. Это был весьма краткий курс, включающий только основные команды процессора и общий принцип их работы. Скорее всего курс был основан на 8080, т.к., многих «новых» команд процессора там не было. Тем не менее, он дал нам толчок — позволил начать писать хоть что-то на ассемблере, а уже дальше каждый разбирался как мог сам.
По сути, ассемблер — первый ЯП, который я выучил. И считаю, что порядок изучения языков должен быть именно таким, т.к. асм дает понимание, как работает процессор и позволяет писать любые программы на любых языках эффективней.
Затем начал изучать паскаль и параллельно — ассемблер 8086. Писал ассемблерные вставки внутри паскаля — это было очень просто и эффективно, код работал в 10 раз быстрее (паскаль плохо оптимизирует). Затем перешел на 32 разряда и изредка пишу на асме х86 даже сейчас. Но сейчас это не так просто — у процессора много ресурсов, а компиляторы становятся умнее и обогнать их уже не всегда оказывается такой простой задачей.
Мне было тогда 13 или 14 лет, точнее не помню. Я ходил в «компьютерный кружок», где стояло два спектрума 48, агат-9, какая-то электроника ВМ (позже я понял, что это был IBM-совместимый компьютер) и правец-8д. Самыми лучшими считались, конечно, спектрумы. Затем шла электроника (т.к. на ней был дисковод и можно было быстро грузить игры), агат (на нем тоже был дисковод, но ничего серьезного из ПО не было) и последним был правец.
Как только я попал в этот кружок, практически сразу понял, что на бейсике ничего серьезного написать невозможно, и мы стали выпрашивать преподавателя прочитать нам курс ассемблера Z80. Он не хотел, мотивируя это тем, что это нам не нужно, все равно ничего путного из нас не выйдет. Но мы настояли, и он прочитал. Это был весьма краткий курс, включающий только основные команды процессора и общий принцип их работы. Скорее всего курс был основан на 8080, т.к., многих «новых» команд процессора там не было. Тем не менее, он дал нам толчок — позволил начать писать хоть что-то на ассемблере, а уже дальше каждый разбирался как мог сам.
По сути, ассемблер — первый ЯП, который я выучил. И считаю, что порядок изучения языков должен быть именно таким, т.к. асм дает понимание, как работает процессор и позволяет писать любые программы на любых языках эффективней.
Затем начал изучать паскаль и параллельно — ассемблер 8086. Писал ассемблерные вставки внутри паскаля — это было очень просто и эффективно, код работал в 10 раз быстрее (паскаль плохо оптимизирует). Затем перешел на 32 разряда и изредка пишу на асме х86 даже сейчас. Но сейчас это не так просто — у процессора много ресурсов, а компиляторы становятся умнее и обогнать их уже не всегда оказывается такой простой задачей.
Спасибо вам за Микро-80!
Интересная статья, но жалко что 1801 серию углублено не рассказали. На сколько помню я система команд PDP была наложена сверху на код НЦ, победила бы позиция сторонников Intel и 1801 стали бы х86 совместимыми.
Кстати о MOS6502, у них небыло микрокода команд, все декодирование и исполнение шло через матрицу. Насколько помню я, это и давало прирост быстродействия процессору, но ограничивало его расширение.
Кстати о MOS6502, у них небыло микрокода команд, все декодирование и исполнение шло через матрицу. Насколько помню я, это и давало прирост быстродействия процессору, но ограничивало его расширение.
читал, как роман
Кстати, идея с двумя стеками иногда возвращается в контексте борьбы с переполнениями буферов.
Для 6502 добавил бы, что его ядро до сих пор живее всех живых и выпускается многотысячными тиражами во всяких детских (и не детских) игрушках типа Тамагочи, простейших «обучающих» контроллерах (не Денди/NES, хотя и их хватает)
В принципе многие вещи знал, о некоторых читал или смотрел видео, но как-то все было разрозненно. Здесь же, все и сразу, даже зачитался.
Просто отличный материал, огромное спасибо, жаль плюс статье поставить не дает, извините.
Просто отличный материал, огромное спасибо, жаль плюс статье поставить не дает, извините.
Спец команды по пересылке строк в x86 — это по сути костыли из-за отсутсвия команд с автоинкрементной и преддекрементной адресаций.
И что значит PDP-11
И что значит PDP-11
так и не была введена поддержка 16-х чисел для ассемблера? Их структура команд была привязана к восмеричной системе счисления и позволяла легко программировать сразу в машинных кодах.
Попробуйте посмотреть на ситуацию практически. ISA PDP-11 предлагала для работы со строками использовать две команды, а x86 одну с префиксом — второе быстрее. Команды с автоинкрементом и декрементом нужны в большинстве случаев для работы со строками, поэтому если есть строковые команды, то можно и не усложнять ISA адресными автоинкрементом и декрементом. Intel решила вопрос более практично, DEC для практики имеет только преимущество по операциям типа MOV (R1)+,-(R2) или MOV -(R1),(R2)+. DEC захламила всё пространство опкодов ради абстракций, которые при наличие хороших компиляторов ничего не значат. Конечно, если с энтузиазмом программировать сразу и в машинных кодах, то компиляторы не нужны. Но это какой-то каменный век компьютерных технологий. Hа РDP-11 писали обычно на неплохом ассемблере MACRO-11 и там иногда было полезно использовать 16-е числа, но этого было нельзя даже в 90-е.
Практичность интела заставляет более активно использовать стек или обмен регистрами, чтобы высвобожать для регистры для узкоспециализированных команд. Например: сформировать третий массив из сумм элементов двух других.
О! Абстракции PDP-11 позволяли довести процесс программирования до рефлексов и создавали ощущение понимания, сравнимое с аналогичным от ЯВУ. До сих пор ностальгирую по этому ощущению. Впрочем, это как первая любовь — забыть нельзя, повторить невозможно… ;)
В 80486 были улучшены тайминги большинства инструкций и некоторые из них стали выполняться как и на процессорах ARM за такт. Хотя умножение и деление почему-то стали чуть медленнее
Может по тому, что математический сопроцессор(80387) переехал в процессор?
В некоторых 8088 есть возможность выполнять команды 8080 на аппаратном уровне, переход в этот режим, насколько помню, по прерыванию int E0h.
писать про 8-битки и не упомянуть RCA1802! А ведь он и щас живее всех живых, до сих пор выпускается (CDP1802A, Intersil).
Очень подробно. Респект. Для меня новостью была информация об относительном быстродействии архитектур. Да, кстати — насколько я понимаю, первой массовой машиной в СССР был Минск-32.
8080 требовал три напряжения, а 8080A — только одно — +5V. Наши клоны были соответственно K580ИК80 (позднее ВМ80) и КР580ВМ80А; причём, 80 был в тонком корпусе с мягкими выводами (только пайка), а 80А — в обычной многоножке (соответственно, легко ставился на розетку). Реально у нас использовался только 8080А/ВМ80А — во всех компьютерах местной разработки. В вики есть фото Квазаровского ИК80 — у меня когда-то лежало несколько таких без дела.
Тут интеловский 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-битных регистра, он бы точно побил всех конкурентов. Боюсь, помешали этому те же причины, что потом убили его развитие.
Тут интеловский 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-битных регистра, он бы точно побил всех конкурентов. Боюсь, помешали этому те же причины, что потом убили его развитие.
8085 был очень даже нужен и очень широко использовался, но в качестве CPU в компьютеры не пошёл, хотя вполне мог бы. 8080A и КР580ВМ80А также использовали три напряжения — см. документацию. Про SCO не знал, благодарю. Насчет непредсказуемых эффектов PDP-11 есть хорошая тема, даю ссылку и посмотрите на материалы рядом — ссылка.
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 и КР580ВМ80А также использовали три напряжения — см. документацию.
Хм, я не нашёл с ходу упоминания специфики именно 8080A, все почему-то универсально говорят про оба. OK, сочтём это за сбой памяти.
> непредсказуемых эффектов PDP-11
Про это уже ответили — неродные процессоры могли как-то лажать, но DEC, насколько я знаю, чётко держал планку.
И эти эффекты не касаются самых важных вопросов — например, порядок выбора дополнительных слов в командах типа mov #1, 20(%2).
> Только это «сильно раньше» было без процессоров-чипов, о которых статья.
Не сходится: вы VAXʼу отдельную главу посвятили.
Не принципиально, но считаю необходимым заметить.
> Посмотрите на команду LDA ($55,X) — тaкое на z80 не представить.
И смысла в ней где-то на уровне ноль целых фиг десятых. Я ещё в те времена как-то заинтересовался осмысленностью этой адресации, пересмотрел (чёрт, грепа не было, листал и глазами смотрел) код стандартных программ типа Бейсика, Школьницы — случаи были просто единичные и тупо сомнительные, в отличие от $ABCD,X или ($AB),Y — последняя вообще использовалась на каждом шагу (ну ещё бы).
Был какой-то паттерн написания, при котором именно такая адресация была полезна? Если да, я его не знаю и не использовал.
В остальном, под что легче писать — вкусовщина, но меня постоянное гоняние байтиков через аккумулятор просто доставало, особенно видя рядом вкусные аналоги типа клонов PDP-11.
Если бы конкуренты не тратили попусту по 4 такта на ерунду, тот 6502 просто не взлетел бы.
Хм, я не нашёл с ходу упоминания специфики именно 8080A, все почему-то универсально говорят про оба. OK, сочтём это за сбой памяти.
> непредсказуемых эффектов PDP-11
Про это уже ответили — неродные процессоры могли как-то лажать, но DEC, насколько я знаю, чётко держал планку.
И эти эффекты не касаются самых важных вопросов — например, порядок выбора дополнительных слов в командах типа mov #1, 20(%2).
> Только это «сильно раньше» было без процессоров-чипов, о которых статья.
Не сходится: вы VAXʼу отдельную главу посвятили.
Не принципиально, но считаю необходимым заметить.
> Посмотрите на команду LDA ($55,X) — тaкое на z80 не представить.
И смысла в ней где-то на уровне ноль целых фиг десятых. Я ещё в те времена как-то заинтересовался осмысленностью этой адресации, пересмотрел (чёрт, грепа не было, листал и глазами смотрел) код стандартных программ типа Бейсика, Школьницы — случаи были просто единичные и тупо сомнительные, в отличие от $ABCD,X или ($AB),Y — последняя вообще использовалась на каждом шагу (ну ещё бы).
Был какой-то паттерн написания, при котором именно такая адресация была полезна? Если да, я его не знаю и не использовал.
В остальном, под что легче писать — вкусовщина, но меня постоянное гоняние байтиков через аккумулятор просто доставало, особенно видя рядом вкусные аналоги типа клонов PDP-11.
Если бы конкуренты не тратили попусту по 4 такта на ерунду, тот 6502 просто не взлетел бы.
Есть очень большая тема по 6502 — Форт. Как правило, адресация типа ($EE,X) используется для реализации внутреннего стека Форта. Она может быть удобна проста для доступа к ячейке памяти, если регистр Y занят, а Х установлен в нуль или имеет известное значение. Ассемблер PDP-11 для байтовых операций очень неуклюж. Для ваксов сделали процессор, но это уже после 32016. Написано, что 32016 был именно первым процессором со страничной организацией вм. Адресации типа ($AA),Y действительно очень удобна — остальные 8-битные системы могут только завидовать такой. В том то и дело — такты, команда 6502 поняла это одними из первых.
> Как правило, адресация типа ($EE,X) используется для реализации внутреннего стека Форта.
Тут хотелось бы примеров, или я чего-то не понимаю — идея стека в нулевой странице как-то особенно смущает. И чем оно так лучше варианта $ABCD, X или $ABCD, Y?
> Ассемблер PDP-11 для байтовых операций очень неуклюж.
Чем? Все основные операции, кроме ADC и SBC, есть в байтовом виде, и даже автоинкремент сделан на 1 вместо 2 (если не %6 или %7).
Тут хотелось бы примеров, или я чего-то не понимаю — идея стека в нулевой странице как-то особенно смущает. И чем оно так лучше варианта $ABCD, X или $ABCD, Y?
> Ассемблер PDP-11 для байтовых операций очень неуклюж.
Чем? Все основные операции, кроме ADC и SBC, есть в байтовом виде, и даже автоинкремент сделан на 1 вместо 2 (если не %6 или %7).
[6502] С фортом это не я придумал, так лучшие в мире 6502-программисты решили. Можете посмотреть конкретные коды по ссылке (там можно поискать слово fetch).
[PDP-11] Рассмотрим, например, CMPB #2,R1. Для байтовой константы 2 будет выделено слово (а не байт) и так будет верно для всех операций с байтовыми константами. В самом ассемблере неуклюжести это не вызывает, но если смотреть на машинные коды, то лишний 0 — это как пятое колесо. И когда памяти так мало, всего 32КБ — этот ноль чувствуется сильно. Не получится ещё без неуклюжести сравнить старший байт R1 с той же 2.
[PDP-11] Рассмотрим, например, CMPB #2,R1. Для байтовой константы 2 будет выделено слово (а не байт) и так будет верно для всех операций с байтовыми константами. В самом ассемблере неуклюжести это не вызывает, но если смотреть на машинные коды, то лишний 0 — это как пятое колесо. И когда памяти так мало, всего 32КБ — этот ноль чувствуется сильно. Не получится ещё без неуклюжести сравнить старший байт R1 с той же 2.
> Не получится ещё без неуклюжести сравнить старший байт 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.
А где его вообще можно так сравнить? 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.
x86 до сих пор в лидерах и частично потому, что более гибко, чем многие другие архитектуры умеет работать с байтами. 3ачем им быть на что-то ещё похожими? Сравните, например, 8086 и 68000. У ARM-32 встоенный в почти каждую команду barrel shifter, который даёт мгновенный доступ к каждому байту слова. У ARM-64 с этим хуже и, возможно, что так Intel ослабляет конкуренцию c x86. ARM смог перегнать х86 в 80-х и в 1996. После второго успеха Intel просто купила эту технологию и стала во-многом её определять.
> x86 до сих пор в лидерах и частично потому, что более гибко, чем многие другие архитектуры умеет работать с байтами. 3ачем им быть на что-то ещё похожими?
И где эта способность реально используется? Сейчас кода, который написан вручную на ассемблере, дай бог чтобы 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 это бриллиант прогрессивного дизайна (во завернул;))
И где эта способность реально используется? Сейчас кода, который написан вручную на ассемблере, дай бог чтобы 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 это бриллиант прогрессивного дизайна (во завернул;))
> А в выхлопе современных компиляторов, если вы найдёте использование регистров типа ah, bh, то это специальные готовые вставки на редчайшие особые случаи.
Это не так. Вот пример кода, где 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.
Это не так. Вот пример кода, где 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.
А откуда берётся это вездесущее «воровать»? Насколько я помню, СССР лицензировал 360.
Спасибо за внимание к статье, но ну вы и даёте! www.computer-museum.ru/books/vt_face/6_rameev_5.htm — такое вот было позорище. А после IBM стали воровать всё, что получалось или скорее на что указывали, — Wang, DEC, Intel,… Xотя об отечественных Уралах даже американцы из Восточного блока хорошо отзываются — en.wikipedia.org/wiki/Charles_Simonyi Ради воровства закрыли и Уралы и БЭСМ-10 и почти уже состоявшееся соглашение с англичанами
Это эмоции. А по факту представительство IBM в СССР было открыто, ЕМНИП, в 1972 году и находилось в историческом центре Москвы в очень приличном здании. И я полагаю, что формальные ограничения на экспорт этой технологии, которые, судя по всему, на них налагало правительство США, были как-то обойдены. Я очень сомневаюсь, что IBM стал бы открывать офис в стране, которая его бысстыдно обворовывает.
Вам дали конкретную ссылку. DEC тоже имела в СССР офисы и что? Ни эта фирма, ни IBM официально никакого отношения к клонированию их компьютеров и использованию ПО без лицензии не имели. Про Ванг деталей не знаю, но нигде в источниках нет про то, что Искры делали по соглашению. Про Коком — ерунда, ограничения пошли только в 80-е, а склонировали архитектуру в 70-е. Разработка архитектуры, софта для неё — это очень затратное дело, проще взять готовое, что и было сделано, в Ванге от этого ничего не получили. Кто-то здесь запостил воспоминания про то как в 70-е добывали документацию Intel… Юникс и на БК портанули, только это было какое-то развлечение только — для работы не годилось. В Киеве Поиск сделали — реально круто, но микросхемы не сами придумали, а другим путем получили.
И про Wang. С Искрами-226 я сам работал в то время. Это не украденый Ванг, это машина, которая была спроектирована полностью в СССР, и которая была программно совместима с Wang-ом. Заказчиком был Госплан, они купили пару тысяч вангов, а потом наши посмотрели на систему команд и сделали машину на советской элементной базе и под нашу периферию. Вот насчёт софта — не знаю, может его и тиснули. Машину спроектировали сами. Кстати, отличная была машина, даром, что на бейсике. Говорят, впрочем, что на неё Юникс в Киеве портанули.
О. Всё ещё хитрее. Госплан их и дальше хотел закупать, но COCOM запретил их продавать в СССР. Тогда СССР их сделал сам.
www.wang2200.org/iskra-226.html
www.wang2200.org/iskra-226.html
Eщё пример вспомнил про неуклюжесть PDP-11 с байтами. Нужно считать байт из памяти и добавить к нему, например, 5. Число в памяти целое беззнаковое, может быть более 127. Самое лучшее, что придумал, — это CLR R1; ORB mem,R1; ADD data,R1
Ну так я ж говорил
> Все основные операции, кроме ADC и SBC, есть в байтовом виде
Необходимость в байтовых сложениях, видимо, её авторами сочтена меньшей, чем в чём-то другом — поэтому именно ADCB, SBCB уже не получили кода. Ну не хватило кодов на всех.
С современной точки зрения, можно было бы сделать как в x86 — команды вида mem op= reg или reg op= mem, но не mem op= mem; можно было бы сделать только второе (как в S/360); можно было бы сделать команды из 4 байт… но для 1970 это всё было явно избыточно.
Мне лично простановка CC по MOV кажется в разы большей диверсией, чем эти мелочи.
> Все основные операции, кроме ADC и SBC, есть в байтовом виде
Необходимость в байтовых сложениях, видимо, её авторами сочтена меньшей, чем в чём-то другом — поэтому именно ADCB, SBCB уже не получили кода. Ну не хватило кодов на всех.
С современной точки зрения, можно было бы сделать как в x86 — команды вида mem op= reg или reg op= mem, но не mem op= mem; можно было бы сделать только второе (как в S/360); можно было бы сделать команды из 4 байт… но для 1970 это всё было явно избыточно.
Мне лично простановка CC по MOV кажется в разы большей диверсией, чем эти мелочи.
Это я неудачный пример взял, наспех. Там нужна константа более 255, а не 5. Со сложением как раз проблем (почти?) никогда нет — продумали они тут неплохо. Проблема в знаковом расширении, которое иногда сильно всё запутывает, например, при работе с таблицами. И, конечно, BISB, а не ORB. :) В PDP-11 ассемблере много хорошего и сделали его ещё в 60-х!
Очень хороший обзор, спасибо.
Сам сталкивался с 6502 (точнее 6510), 6809, tms9900, 8048, cp1610, x86.
Больше всего кода написал для x86 (8086-80486), но писать под него, на мой взгляд, неприятно (как и вообще под архитектуру PC, куда эти процессора ставились).
Больше всех понравился, пожалуй, 6809. На втором месте 6502.
Чуть-чуть потрогал sparc — там интересна идея регистровых окон. Трогал также 8080 и z80, но душа к ним не легла.
О программировании под 68000 от людей слышал почти исключительно хорошие отзывы, завидовал (в те времена, когда я сидел на PC, а знакомые на Amiga).
Сам сталкивался с 6502 (точнее 6510), 6809, tms9900, 8048, cp1610, x86.
Больше всего кода написал для x86 (8086-80486), но писать под него, на мой взгляд, неприятно (как и вообще под архитектуру PC, куда эти процессора ставились).
Больше всех понравился, пожалуй, 6809. На втором месте 6502.
Чуть-чуть потрогал sparc — там интересна идея регистровых окон. Трогал также 8080 и z80, но душа к ним не легла.
О программировании под 68000 от людей слышал почти исключительно хорошие отзывы, завидовал (в те времена, когда я сидел на PC, а знакомые на Amiga).
Прочитал, интересно, спасибо.
litwr2 вы слышали про КолибриОС, ядро и многие программы которой написаны на ассемблере? Может быть смотрели исходники ядра? Что думаете?
litwr2 вы слышали про КолибриОС, ядро и многие программы которой написаны на ассемблере? Может быть смотрели исходники ядра? Что думаете?
Благодарю за добрые слова. Про Колибри и её родственника Menuet знаю давно, запускал и удивлялся ещё лет более 10 назад. Там все базовые программы на ассемблере. Хотел кое-что прикладное написать, но не хватило возможностей найти время. С ядром не работал.
Машина по имени kremvax реально существовала много лет и стояла на узле Интернет (Релком) в кооперативе Демос на Овчинниковской набережной. Позже компания Sun узнав об этом подарила Релкому машину под обещание тоже использовать её для обеспечения работы Интернета в России под именем kremlsun.
Автор что-то путает.
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-х