В первой части были описаны многие разные процессоры до середины 90-х. Для мейнфреймов IBM там места не нашлось, так как эти системы долгое время не использовали процессоры-чипы. Однако, мейнфреймы IBM тесно связаны с другими компьютерными системами, долгое время являясь одними из лучших образцов компьютерной техники, на которые так или иначе ориентировались практически все. Кстати, формат хабр-блога, как и Википедии, позволяет редактирование, что позволило значительно переработать содержимое первой части с учетом поступивших замечаний и прочей дополнительной информации.

В этой части главное внимание уделяется сравнению машинного языка мейнфреймов с другими системами, которые были популярны в период с 70-х по 90-е. Это прежде всего x86, 68k, VAX и ARM. Системы 390 и, в особенности, Z рассматриваются очень фрагментарно – основное внимание уделяется именно системе 370.

И ещё о сортировках

Рискну опять поднять эту тему. Начну со ссылки на статью Михаила Опанасенко (oms7), очень впечатляющую по объёмам проделанной работы, а также по количеству приведёных ссылок. Свой материал начал готовить, не зная об этой публикации, что впоследствии, после ознакомления привело к необходимости его существенной переработки. Для тех, кто уже прочитал эту статью, сообщаю, что в моём материале, исследуются более разнообразные по типам данные, в частности, строки и вещественные числа, используются библиотеки boost и bsd, а также затрагиваются некоторые другие отсутствующие в названной статье темы.

A characteristic feature of modern programming is the use of the global network as a source of reference information, in particular, a source of patterns for solving unknown or little-known problems for a specific programmer. Such an approach saves a lot of time and often gives quite qualitative results. However, the solutions laid out in the network although usually correct, do not always take into account all the subtleties of solving a problem, which leads to the appearance in the source code of sections that usually work correctly, but under not quite standard circumstances become sources of unpleasant surprises.

Consider the topic of using sequence files in the Linux kernel, such files are considered to be the most convenient mechanism for printing from kernel mode. But in practice, using them correctly is much more difficult than you would think.

A lot of materials on this topic are available online. The best is the source code of the kernel itself which has quite detailed comments. The problem with this source of information is its volume. If you do not know exactly what to look for, it is better if you only have limited time, not to try at all. For me, when I became interested in the topic, Google provided several seemingly excellent sources of information relating to my search: the famous book The Linux Kernel Module Programming Guide and a series of articles by Rob Day. These sources are not new, but very solid.

Характерная черта современного программирования в использовании глобальной сети как источника справочной информации, в частности, источника шаблонов для решения неизвестных или малоизвестных конкретному программисту проблем. Такой подход экономит массу времени и часто даёт вполне качественный результат. Однако, решения, выложенные в сети, хотя обычно правильны, но не всегда учитывают всех тонкостей решения той или иной проблемы, что приводит к появлению в кодах участков, которые обычно работают правильно, но при не совсем стандартных обстоятельствах становятся источниками неприятных неожиданностей.

Рассмотрим тему использования файлов-последовательностей в ядре Linux. Такие файлы считаются самым удобным механизмом для печати из режима ядра. Но на практике использовать их правильно гораздо сложнее, чем можно об этом подумать.

В сети доступно множество материалов по этой теме. Самый лучший – это исходники самого ядра с достаточно подробными комментариями. Проблема этого источника информации в его объёме. Если не знать в точности, что искать, то лучше, имея лишь ограниченное время, и не пробовать. У меня, когда возник интерес к теме, Google нашёл несколько на первый взгляд отличных источников информации: известную книгу The Linux Kernel Module Programming Guide и серию статей Роба Дея (Rob Day) по нужной теме. Источники не новые, но весьма солидные.

Мне довелось программировать на ассемблерах разных процессоров. Последний в списке – это Xilinx MicroBlaze. Решил выложить некоторые свои наблюдения за особенностями этих почти волшебных железок, которые как волшебный ключик Буратино открыли нам двери в волшебную страну виртуальной реальности и массовой креативности. Об особенностях современных систем x86, x86-64, ARM, ARM-64 и т.п. писать не буду, может быть в другой раз – тема очень большая и сложная. Поэтому планирую закончить на Intel 80486 и Motorola 68040. Хотелось ещё включить в обзор IBM/370, с которыми имел дело. Эти системы были довольно далеки от широких масс пользователей, но оказали при этом огромное влияние на компьютерные технологии. На них просто не хватило выделенного на тему времени, они не использовали процессоры-чипы и самих их вроде бы почему-то не осталось совсем. Очень надеюсь, что мои материалы привлекут внимание и знатоков, которые смогут добавить что-нибудь из того, о чем не подумал или не знал.

В качестве иллюстративного материала прикрепляю свой небольшой камень из Розетты – программки для расчета числа π на разных процессорах и системах по алгоритму-затвору, претендующие на звание самых быстрых его реализаций. Похожий "камень" есть и для алгоритма для быстрого расчета множеств Мандельброта.

Недавно очередной раз отработал со студентам 2-го курса 2-семестровую дисциплину «Алгоритмические языки». Обзорно рассмотрели несколько дюжин языков программирования. Один из студентов, Вадим Шукалюк, захотел получше с ними познакомиться, получить более четкое представление о каждом из них. Посоветовал ему провести небольшое исследование. Чем и увлёк. Предлагаю свой отчёт по проделанной за несколько месяцев вместе с ним работе.

У каждого языка программирования есть свои достоинства и недостатки. Одна из важнейших характеристик транслятора с любого языка — это скорость исполнения программ. Очень трудно или даже невозможно получить точную оценку такой скорости исполнения. Ресурс http://benchmarksgame.alioth.debian.org/ предлагает игровую форму для проверки такой скорости на разных задачах. Но число языков, представленных на этом ресурсе, довольно невелико. Предельную ёмкость стека, критическую величину для рекурсивных вычислений проверить проще, но она может меняться в разных версиях транслятора и быть зависимой от системных настроек.

Тестировались следующие трансляторы: си (gcc, clang, icc), ассемблер (x86, x86-64), ява (OpenJDK), паскаль (fpc), яваскрипт (Google Chrome, Mozilla Firefox), лисп (sbcl, clisp), эрланг, хаскель (ghc, hugs), дино[1], аук (gawk, mawk, busybox), луа, рубин, бейсик (gambas, libre office), питон-2, пи-эйч-пи, постскрипт (gs), пролог (swipl, gprolog), перл, метапост, Т_EХ, тикль, бэш. Исследовались как собственно скорость исполнения нескольких небольших, но трудоёмких алгоритмов, так и:

• качество оптимизации некоторых трансляторов;
• особенности при работе с процессорами Intel и AMD;
• предельное число рекурсивных вызовов (ёмкость стека).