ЕС ЭВМ — это измена, трусость и обман? (ссылка на статью)


Комментарии:
2024-08-07 Автор сайта

Пришёл на почту такой вопрос:
Помнится, встречал на вашем сайте такое мнение, что «начинать нужно с создания своих собственных отечественных процессоров». Возможно, это писали не Вы, но мне интересно ваше мнение на этот счёт.
Решил дать ответ через сайт на странице, которая ближе всего к этой теме. Ибо сейчас стоит такой же вопрос, как и 55 лет назад: сделать что-то своё или выбрать что-то лучшее из зарубежного? 55 лет назад выбирали между условным «Уралом»/БЭСМ-6 и IBM/360. Сейчас же, если упростить ситуацию, выбирают между «Эльбрусом» и RISC-V.

Выбор IBM/360 в качестве ЕС ЭВМ был, на мой взгляд вынужденной мерой: на дворе была холодная война, а времени и денег было в обрез. Обвинение в предательстве, высказываемые сейчас, неуместны: люди, которые принимали такое решение, были уважаемы и не раз доказывали, что их труд и талант работает на благо страны.

Что касается сегодняшнего дня, то пусть правильное решение примут специалисты. Себя же считаю недостаточно компетентным в этом. С одной стороны, хочется пожелать успехов отечественному «Эльбрусу». С другой стороны, есть вопросы: а потянем ли? Действительно ли так хорош «Эльбрус»? Ведь есть споры на сей счёт («Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU» и «Процессор Эльбрус — почему статья о тупике несостоятельна»), и я не знаю, кто прав в этом споре.

Есть вариант сделать ставку на RISC-V, ибо эта архитектура открыта. И тут возможна хитрость: «если мафию победить невозможно, то нужно её возглавить». Известный специалист Юрий Панчул пишет:
Путь России, Китая и другой зарождающейся мировой альтернативы — это линуксные компьютеры на RISC-V. Там можно легально, конструктивно и эффективно использовать открытые решения со всего мира, на основе которых строить свои.
Впрочем, и архитектуру «Эльбруса» тоже можно сделать открытой, как у RISC-V, и вроде бы делаются шаги в этом направлении.

Так что моё мнение такое: пусть принимают решение специалисты, а я с ним соглашусь. Главное, чтобы потом не было двоемыслия, что иностранные языки программирования на отечественных процессорах — это хорошо, а вот наоборот — это плохо.
2024-08-09 alextretyak

Автор сайта
Мой вопрос был немного не про это.
Вот смотрите. Всюду нас окружают компьютеры с процессорами архитектуры x86: дома, на работе, практически на всех серверах для хостинга (в т.ч. хостинга этого сайта). Вы верите в то, что это положение можно как-то изменить? (Речь не о каких-то нишевых/узких применениях, а про массовую вычислительную технику.)

Да, возможно ARM или RISC-V когда-то в будущем смогут потеснить x86 в нише ПК/ноутбуков, но сейчас, на данный момент, x86-процессоров уже произведено и работает много миллиардов штук. И в ближайшие годы (а скорее десятилетия) архитектура x86 продолжит быть доминирующей в этой нише.

Но если взять любой процессор Intel x86 и стереть с его корпуса маркировку, то что от него останется американского?

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

И чем вообще «русский» процессор принципиально может отличаться от существующих иностранных? Не получится ли в итоге плюс-минус то же самое (регистры, кэш-память, типичный набор инструкций — mov/load/store, сложение, вычитание, умножение, сдвиги и т.д.)?
К тому же, в разработке процессоров x86 принимало участие множество людей самых разных национальностей. И если что и является американским в x86-процессорах, так это их документация.

И вот в этой области, как раз таки у нас есть реальная возможность «перехватить инициативу». В каком смысле?
По словам одного из бывших сотрудников Intel:
из существующей X86 ISA сейчас используется около 20%. Остальное – пережитки прошлого.
Официальная документация от Intel по архитектуре x86/x86-64 — это огромный талмуд на 5000 страниц, который изучать полностью нет никакого смысла, т.к. большая часть информации в нём уже не актуальна. И сейчас очень не хватает именно актуальной документации по современным процессорам архитектуры x86. Причём документации в удобной форме, а не в виде архаичного pdf-документа, в котором затруднительно осуществлять поиск нужной информации и который распечатывать всё равно никто не будет.

Собственно, я считаю, что начинать нужно именно с такой документации. В процессе работы над которой следует обозначить устаревшие возможности архитектуры x86, а также новые возможности, которые не используются в современном ПО и, следовательно, также являются неактуальными. (Для оценки актуальности тех или иных команд архитектуры x86 можно просто проанализировать машинный код всего популярного ПО [даже исходники иметь не обязательно — есть дизассемблер] и если какие-то команды вообще нигде не используются, значит они неактуальны.)
Более того, такая документация сможет помочь не только для разработки ПО под x86, но и для проектирования новых процессоров (как отечественных, так и не очень). Т.к. в зависимости от «нужности»/частоты использования инструкции зависит её реализация в процессоре.

И если такую документацию вести сразу на русском языке [ну или параллельно на английском и на русском], тогда неизбежно встаёт вопрос и о... русском языке ассемблера.
Хотя этот вопрос уже неоднократно поднимался, всерьёз за реализацию такого проекта никто ещё не брался (речь про реально работающий генератор машинного кода х86-64 из русского ассемблера с поддержкой современных расширений набора команд [хотя бы SSE/AVX2]). И у меня есть некоторые соображения на этот счёт. В течение месяца я планирую опубликовать соответствующую статью на Хабре {…}.
2024-08-09 Автор сайта

Вы верите в то, что это положение можно как-то изменить?
Оно уже давно меняется, при этом без нашего участия. Операционных систем Android установлено больше, чем Windows. А работает Android на ARM. Фирма Apple скакала сперва с Motorola на PowerPC, потом на Intel, потом на ARM. И делала это достаточно безболезненно! Потому что мощность нового процессора позволяла эмулировать старый процессор без потери скорости.

Linux работает на многих платформах, ему, по сути, всё равно на чём работать. Остаётся Windows. Но индийский руководитель Microsoft заявил, что у его компании больше нет религии. То есть они теперь всеядны. Так что свято место лидирующей архитектуры пустым не будет. Тем более, что x86 не оптимальна и объективно проигрывает в некоторых вещах , типа плотности команд (машинный код для реализации одного и того же длиннее, чем у конкурентов), и положение неисправимо.

Но x86 не исчезнет, просто доля сожмётся. Ведь PowerPC до сих пор применяются, например в истребителях F-22 или F35. X86 останется в ещё больших количествах, ибо исторический багаж очень велик.

Ну чисто субъективное ощущение, что скорость смены эпох возрастает.

в зависимости от «нужности»/частоты использования инструкции зависит её реализация в процессоре.
При разработке отечественной архитектуры «Самсон» самые частые команды специально сделали однобайтовыми. Вот это я понимаю, вот это борьба за оптимальность.

всерьёз за реализацию такого проекта никто ещё не брался
Разработка Д.Ю.Караваева — это не только суверенный компилятор PL/1, но и суверенный ассемблер x86. Просто он не русифицирован. Но лично я не наблюдал интереса к русификации ассемблера. О чём неоднократно писал.
2024-08-11 alextretyak

Оно уже давно меняется
Не соглашусь.
Ничего принципиально не меняется. Только добавляется. А это большая разница.

В существующей нише ПК/ноутбуков/серверов за последние несколько десятилетий принципиальных изменений не было (x86 продолжает доминировать), а рынок смартфонов/планшетов — это новая ниша. Которые [смартфоны/планшеты] лично я к компьютерам не отношу вообще. Почему? А вы попробуйте попрограммировать на Android-устройстве. Попробуйте подключить к смартфону/планшету мышь, клавиатуру, монитор (а лучше два) и настроить IDE для комфортной работы. И попробуйте установить например Python. С официального сайта, правда, не получится, т.к. Android вообще не упоминается в списке неофициально поддерживаемых платформ даже на странице ‘Python for Other Platforms’.
Проблема в том, что Android — это не Linux. И её владелец — компания Google — вообще не заинтересована в поддержке разработчиков нативных приложений под свою систему и в превращении смартфонов в мобильное Arm64-рабочее место. И хотя производительности ARM-процессора современного смартфона вполне достаточно для работы тяжёлых программ (в т.ч. и IDE), получить пользовательский опыт аналогичный ПК с x86 никак не получится. Т.е. ARM тут оказалась в заложниках политики Google.

Что касается продукции Apple. Она ориентирована на свою особую аудиторию фанатов и, как вы верно упомянули, Apple удавалось успешно перепрыгивать с одной архитектуры на другую много раз. И я бы не стал причислять какие-либо процессоры в устройствах Apple к ARM-процессорам. Уже сейчас их "ARM-based" чипы поддерживают некоторые недокументированные инструкции (например Apple AMX), которые никто кроме Apple, очевидно, добавлять в свои процессоры не будет. И дальше, я полагаю, расхождение с ARM будет только увеличиваться. Не исключено, что Apple вообще соорудит какую-то новую архитектуру специально под себя.

Таким образом, ARM занимает свою отдельную нишу и единственная область, в которой архитектура ARM может потеснить x86 — это рынок серверов. Но и здесь изменения происходят очень медленно.
В новости от 2014 года было сказано:
По мне­нию AMD, через пять лет 25% всех сер­веров в мире будут работать на плат­форме ARM.
Вот прошло уже 10 лет, и по факту доля ARM на серверном рынке составляет 10%, причём больше половины из них обслуживают Amazon Web Services. Т.е. несмотря на значительно большую энергоэффективность — в 2-4 раза по сравнению с Intel Xeon — ARM-сервера до сих пор используются лишь в каких-то специализированных решениях, где серверный софт специально пишут под ARM.

Но x86 не исчезнет, просто доля сожмётся.
Так то оно так. Вот только с такими темпами этот процесс растянется на много десятилетий. И что нам делать всё это время, просто ждать?
Я предлагаю ориентироваться на текущее положение вещей (т.к. не похоже, что оно может принципиально измениться в ближайшем будущем) и разрабатывать своё ПО для сокращённой версии x86-64 (содержащей только актуальные возможности архитектуры).
Хотя и про поддержку ARM64 забывать не следует. Но для полноценного использования ARM-процессоров (в работе) необходимо будет разработать или доработать специальную операционную систему, т.к. Android для профессиональной работы не годится.
2024-08-11 Автор сайта

Ничего принципиально не меняется. Только добавляется... x86 продолжает доминировать... рынок смартфонов/планшетов — это новая ниша.
Ой, не скажите. Знаю многих людей, которые не айтишники и которые перестали обновлять свои домашние компьютеры раз в несколько лет. Старые компьютеры у них пылятся без дела, а новые не нужны, потому что есть телефон, а в нём есть всё, что нужно. А полазить в Интернете можно и с телевизора лёжа на диване.

Теперь про тех, кого знаю и кто использует компьютеры на работе. Один разработчик на PHP поставил себе Linux на ноутбук и тащится от того, что с Windows он бы тормозил и пришлось бы покупать новый. А вот с Linux он весьма шустрый. Раз у него стоит Linux и ему нужен PHP, то в следующий раз он опять возьмёт ноутбук под Linux, а вот какой у него будет процессор — большой вопрос. Очень даже может быть, что ARM или RISC-V. Ведь главное — соотношение цена/качество.

Знаю другого разработчика на Go. Ему на работе выдали ноутбук Apple. Не потому, что он фанат, а просто выдали и всё. Он ему понравился. А ведь в нём нет x86.

Ещё из того, что знаю. На одном предприятии работникам в цехах на телефоны поставили приложение, в котором они получают производственные задания и ставят отметки об их выполнении. За компьютеры садятся только бригадиры, которым нужна только 1С и почта в браузере. Если 1С переведут на ARM или RISC-V (а это обязательно когда-нибудь случится), то надо только дождаться предложения на поставку компьютеров с такими процессорами. Так что не только домашние компьютеры x86 уходят из жизни.

не стал причислять какие-либо процессоры в устройствах Apple к ARM-процессорам. Уже сейчас их "ARM-based" чипы поддерживают некоторые недокументированные инструкции... полагаю, расхождение с ARM будет только увеличиваться.
Это не важно для ответа на вопрос: «перейдёт ли мир на что-то не x86 или не перейдёт». Что ARM, что модифицированный ARM не являются x86 и это главное.

прошло уже 10 лет, и по факту доля ARM на серверном рынке составляет 10%.
Так потому что нет предложения. Зайдите на сайт какого-нибудь компьютерного магазина и Вы не увидите в каталоге компьютеров или серверов с ARM. А когда появится, то покупатели учтут соотношение цена/качество.

Я предлагаю ориентироваться на текущее положение вещей... и разрабатывать своё ПО для сокращённой версии x86-64.
Я бы отдал приоритет генерации кода во что-то, не сильно зависимое от платформы. В Си или LLVM. К сожалению, в последнюю не дадут внести поддержку «Эльбрусов» (или уже не дали). Поэтому неплохо бы задуматься об отечественном аналоге LLVM. И это, на мой взгляд, куда актуальнее, нежели русский ассемблер. Думаю, Вежливому Лису стоит учесть это в своих планах. Он ведь любит планировать.

для полноценного использования ARM-процессоров (в работе) необходимо будет разработать или доработать специальную операционную систему
Зачем? Есть масса версий Linux, которые работают с ARM. И зарубежные, и отечественные. ОС от Касперского работает на x86_64, но написана она не на ассемблере, поэтому вполне переписывается и на другие платформы. Да и стоит ли ориентироваться на ARM? Всё равно не дадут законно производить. Лучше сразу строить планы на RISC-V. И про «Эльбрус» не забываем.
2024-08-12 alextretyak

Ой, не скажите. Знаю многих людей, которые не айтишники
Вот, но я-то говорил об айтишниках.
Но ладно, не буду спорить. Критерии наблюдаемых «изменений» бывают разные. Окружение у нас тоже очень разное. Я говорил про свой опыт, вы — про свой. И хотя компьютер я тоже давно не обновлял, но без дела у меня пылятся планшет и эл.книга [с процессорами ARM, как можно догадаться]. За большим монитором работать с информацией [особенно, писать статьи] гораздо удобнее.

отечественном аналоге LLVM. И это, на мой взгляд, куда актуальнее, нежели русский ассемблер
Допустим, что и правда актуальнее. Вот только это не отменяет вопрос: а выхлоп этого «отечественного аналога LLVM» под архитектуру x86 будет на каком языке? Сразу в машинном коде? А если где-то в одном битике ошибка и вместо машинного кода D1'E8 (инструкция shr eax, 1) сгенерировался D1'F8 (инструкция sar eax, 1), и полученная программа вроде бы в целом работает (т.к. обе эти инструкции осуществляют сдвиг вправо на 1 бит), но иногда ведёт себя странно. Как находить в сгенерированном коде такие ошибки? Даже ассемблер разглядывать — то ещё удовольствие. Но машинный код x86 — это вообще ужас-ужас. Той же мнемонике shr соответствуют 6 различных кодов операции в зависимости от того, какие операнды она принимает (https://www.felixcloutier.com/x86/sal:sar:shl:shr). Разработчики компилятора должны это наизусть заучивать?
Нет, всё-таки без языка ассемблера никак.
Тем более, что вы сами предлагали идею в верном направлении (обозначать машинные операции не сокращениями из букв, а символами). Осталось только эту идею более тщательно проработать. Чем я, кстати, сейчас и занимаюсь. [Этому, собственно, и будет посвящена новая статья, о которой я здесь уже упоминал.]
2024-08-12 Автор сайта

а выхлоп этого «отечественного аналога LLVM» под архитектуру x86 будет на каком языке? Сразу в машинном коде?
С одной стороны, если сразу в машинный код, то это и быстрее, и компилятор проще. Но в целях отладки всё-таки лучше с промежуточным этапом — текстом на ассемблере.

Как находить в сгенерированном коде такие ошибки?
Разработчики компилятора должны это наизусть заучивать?
Чтобы разработчик компилятора из своего языка не мучился с такими проблемами, ему лучше компилировать в аналог LLVM. А вот разработчик этого аналога должен вовсю постараться, чтобы не было путаницы между «shr» и «sar». Он должен сделать работу качественно.

вы сами предлагали... обозначать машинные операции не сокращениями из букв, а символами
Если бы я это делал заново, то и сейчас поступил так же, хотелось языку ассемблера привить какие-то черты от ЯВУ. Вспомнил некоторые черты языка ассемблера, который разрабатывал Е.А Зуев. Что-то оттуда взял. Но у «паскалиста» Зуева ассемблер получился не такой, как у меня, «сишника».

Но я говорил о невостребованности русского ассемблера не просто так. Никто за 10 лет не поинтересовался моим ассемблером. А русификатор Си скачивали более 1600 раз.

В отечественном LLVM я первый был бы заинтересован, если бы он был качественный. Это ж сколько головной боли он бы снимал. Между прочим, у нас хорошая отечественная школа в этой области. Были в прошлом проекты языков Эпсилон и Сигма, своего рода «ассемблеры высокого уровня».
2024-09-02 alextretyak

разработчик этого аналога должен вовсю постараться, чтобы не было путаницы между «shr» и «sar». Он должен сделать работу качественно.
Даже если «отечественный аналог LLVM» будет работать идеально без ошибок, то всё равно иногда требуется посмотреть ассемблерный листинг с целью анализа итогового сгенерированного машинного кода: