Непонятно, почему вы так удивляетесь обмену (набора) регистров за 4 такта?
Это достигается просто манипуляцией адреса регистра. Данные никуда не перемещаются.
Важен результат, а он есть — регистры меняются местами. Если для закручивание лампочки крутить стул вместе с тем, кто держит лампочку, та будет закручена. :)
Давным давно, ARM был чуть хуже чем IA-32.
Если же говорить о состоянии дел в настоящий момент, то ARMv8 с фиксированными 32-битными инструкциями выигрывает в плотности кода у x86-64, а также в количестве команд.
В статье все-таки про первые ARM-ы и они не были хуже, а скорее лучше, им не хватало только MMU и арифметического сопроцессора. Насчет плотности кода хотелось бы получить подтверждающую ссылку — сомневаюсь.
Благодарю за добрые слова. Однако, sorry, не случилось поработать. :( Слышал только, что там как-то уникально на аппаратном уровне устроена работа с параметрами функций. И в первой половине 90-х в встречал несколько раз в Москве — техника выглядела очень сильно.
Посмотрел в википедии — непонятно там про MMU у z8000. Вроде есть что-то для работы с виртуальной памятью, но ничего нет по защите памяти, её организации. Сомневаюсь, что y Z8000 полноценное MMU как у 80286.
Конечно, у 68000 больше регистров и это на некоторых задачах может давать более компактный код. Но инструкции у х86 могут быть любой длины, например, 1 или 3 байта. А у 68000 все выравнено по границе 4 байта. У архитектуры х86 тут большое преимущество.
Про z8000 почти ничего не знаю. Будет интересно, если сообщите что-нибудь о том, почему этот процессор так и не состоялся фактически.
1. Большинство этих режимов мало что значат. Они скорее о формате выходного файла COM или EXE. Вот если нужны были большие массивы, то надо было выбирать режим Huge — это замедляло. Но к концу 80-х, когда стало для этого у многих хватать памяти, уже были доступны системы для работы в 32-разрядном режиме, в котором этой проблемы уже не было, хотя и заметно тормозился ввод-вывод. Конечно, это уже про 80386. Могу ещё заметить, что указание режима Tiny позволяло получать самые компактные коды, без загрузчика, благодаря именно сегментным регистрам. И вроде бы нет особой проблемы в том, чтобы один раз указать режим. Cкорее могло напрягать использование директив FAR и NEAR, но скорее только начинающих. В современных процессорах много режимов, хотя скорее чисто системных.
2. Иметь как-бы защищенные режимы без защиты памяти вещь абсолютно бесполезная, это только делало архитектуру бессмысленно более громоздкой.
3. Согласен, что теоретически система команд 68000 более продвинутая, но когда дело доходит до практического программирования, то 8086 часто (пусть и не всегда) оказывается лучше. Ну и что, что для счётчика можно использовать только CL — проблема возникнет, только если нужно сразу несколько таких счётчиков, больших 1 — это возможно, но скорее редко, чем часто. Было интересно получить ссылки на какие-нибудь данные, указывающие, что код для 68000 более компактен, чем для 8086. У меня обратная информация, например, программка для вычисления числа π для 8086 почти в полтора раза меньше (примерно 650 байт против более 900). У 8086 многие команды занимают только один байт.
Интересно, только сейчас стал понимать как музыку и звук делают! Помню на Коммодоре +4 был бейсик, расширенный командами для синтеза речи THROAT, PITCH, SAY,… — тогда это порождало очень сильные эмоции.
Звук в точности как на ютуб-видео выше, но пишут, что алгоритм был слегка изменен. А в так не пошедшем в серию Коммодоре 364 был встроенный аппаратный синтезатор речи довольно неплохого качества, его можно услышать в эмуляторе Yape+4 — этот же синтезатор использовался как приставка с С64
A в Amige 500 речь в бейсике уже была «в коробке», но качество улучшилось не намного.
Могу посоветовать автору ещё десяток хотя бы книжек почитать, прежде чем такие статьи писать. Много личной тенденциозности и почти отсебятины. Хотя бы про аду в вики почитал, давно её гражданские используют, в частности, в серьёзном банковском секторе.
Питон лучше рубина? Пельмени лучше жаркого? И современный PHP — это очень мощный инструмент, с быстродействием, благодаря JIT, близким даже к C. Забыт весьма популярный и достойный язык Lua. Где самые модные ныне функциональные языки, начиная с лиспа? Тут можно было бы и про С++ пару добрых слов сказать…
Странные перескоки, например, ругают ручное управление памятью в С (хотя есть и gc для автоматического), а потом пишут, что С++ улучшился объектностью, будто это как-то связано…
Выделил более десятка цитат, достойных скорее всего негативной оценки. Возьму одну. «А в C++ (STL) как реализована строка? Ну, как-то реализована.» Автор, прочитайте хотя бы Страуструпа…
Если это было так, то это скорее ослабило эту фирму. Может и тут конкуренты «помогли».
Важен результат, а он есть — регистры меняются местами. Если для закручивание лампочки крутить стул вместе с тем, кто держит лампочку, та будет закручена. :)
В статье все-таки про первые ARM-ы и они не были хуже, а скорее лучше, им не хватало только MMU и арифметического сопроцессора. Насчет плотности кода хотелось бы получить подтверждающую ссылку — сомневаюсь.
Конечно, у 68000 больше регистров и это на некоторых задачах может давать более компактный код. Но инструкции у х86 могут быть любой длины, например, 1 или 3 байта. А у 68000 все выравнено по границе 4 байта. У архитектуры х86 тут большое преимущество.
1. Большинство этих режимов мало что значат. Они скорее о формате выходного файла COM или EXE. Вот если нужны были большие массивы, то надо было выбирать режим Huge — это замедляло. Но к концу 80-х, когда стало для этого у многих хватать памяти, уже были доступны системы для работы в 32-разрядном режиме, в котором этой проблемы уже не было, хотя и заметно тормозился ввод-вывод. Конечно, это уже про 80386. Могу ещё заметить, что указание режима Tiny позволяло получать самые компактные коды, без загрузчика, благодаря именно сегментным регистрам. И вроде бы нет особой проблемы в том, чтобы один раз указать режим. Cкорее могло напрягать использование директив FAR и NEAR, но скорее только начинающих. В современных процессорах много режимов, хотя скорее чисто системных.
2. Иметь как-бы защищенные режимы без защиты памяти вещь абсолютно бесполезная, это только делало архитектуру бессмысленно более громоздкой.
3. Согласен, что теоретически система команд 68000 более продвинутая, но когда дело доходит до практического программирования, то 8086 часто (пусть и не всегда) оказывается лучше. Ну и что, что для счётчика можно использовать только CL — проблема возникнет, только если нужно сразу несколько таких счётчиков, больших 1 — это возможно, но скорее редко, чем часто. Было интересно получить ссылки на какие-нибудь данные, указывающие, что код для 68000 более компактен, чем для 8086. У меня обратная информация, например, программка для вычисления числа π для 8086 почти в полтора раза меньше (примерно 650 байт против более 900). У 8086 многие команды занимают только один байт.
Звук в точности как на ютуб-видео выше, но пишут, что алгоритм был слегка изменен. А в так не пошедшем в серию Коммодоре 364 был встроенный аппаратный синтезатор речи довольно неплохого качества, его можно услышать в эмуляторе Yape+4 — этот же синтезатор использовался как приставка с С64
A в Amige 500 речь в бейсике уже была «в коробке», но качество улучшилось не намного.
Питон лучше рубина? Пельмени лучше жаркого? И современный PHP — это очень мощный инструмент, с быстродействием, благодаря JIT, близким даже к C. Забыт весьма популярный и достойный язык Lua. Где самые модные ныне функциональные языки, начиная с лиспа? Тут можно было бы и про С++ пару добрых слов сказать…
Странные перескоки, например, ругают ручное управление памятью в С (хотя есть и gc для автоматического), а потом пишут, что С++ улучшился объектностью, будто это как-то связано…
Выделил более десятка цитат, достойных скорее всего негативной оценки. Возьму одну. «А в C++ (STL) как реализована строка? Ну, как-то реализована.» Автор, прочитайте хотя бы Страуструпа…