Не хотел бы я писать под Эльбрус?

Что: 662f54326f780519746fc5ab6c6652c17d85b500

Когда: 2020-12-01 16:51:19+03:00

Темы: hard

Не хотел бы я писать под Эльбрус?

А ведь наверняка на работе именно он будет основным местом для будущих
проектов. Хотя ведь есть же и Байкалы ARM-ы и MIPS32-ы, и КОМДИВ-ы
(MIPS64), но что-то с ними не удовлетворённости у людей (конкретики не
знаю, возможно речь просто про производительность).

А с Эльбрусом пока сложно ответить на вопрос. С одной стороны: идут они
в жопу ибо даже ассемблер закрыт! Ты НЕ можешь командовать своим
процессором, ибо не знаешь его команд. Используй только закрытый
проприетарный C-компилятор lcc. С другой стороны, много статей говорит
что в x86-эмуляции он не шибко просаживается по скорости и его можно
считать просто как альтернативной x86-реализацией. Против чего я в
общем-то ничего против уже не имею. Не, я считаю что x86 уже не один
десяток лет должен быть в гробу, но раз уж даже на отечественном рынке
MIPS/ARM-ы не удовлетворительны (по производительности?), то пока
деваться уж некуда, как и дома я же x86 использую.

А ещё с одной стороны: а что значит писать под Эльбрус? Там в теории
точно такой же Debian, Java, Python. Если уж программа работает на
FreeBSD/Clang/BSDlibc и на GNU/Linux/GCC/glibc, то и на Эльбрусе
(предполагая что забываем про ассемблерные вставки) уж должно взлететь.
Знать что программа будет запускаться вместо *BSD на e2k/GNU/Linux --
мне без раз��ицы что за платформа, код то портируемый (должен быть).

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

оставить комментарий

комментарий 0:

From: kmeaw
Date: 2020-12-02 16:28:28Z

> Ты НЕ можешь командовать своим процессором, ибо не знаешь его команд.

Но ведь, строго говоря, это справедливо и для Intel x86. У процессора
есть (подписанный Intel) микрокод, позволяющий процессору транслировать
x86-инструкции, которые позволено использовать программисту, в свои
"настоящие" микрооперации. Чем это отличается от использования
x86-транслятора e2k (транслирует на лету инструкции x86-машины в e2k)
или lcc (транслирует ahead-of-time инструкции абстрактной машины C в
e2k)?

Это как раз тот случай, когда вместо запрятывания логики в железо, в
которое залезть в домашних условиях проблематично, производитель даёт
нам программно-аппаратный комплекс, программную (пусть и закрытую,
проприетарную) часть которого можно изучать.

комментарий 1:

From: Sergey Matveev
Date: 2020-12-02 16:47:10Z


>Чем это отличается от использования x86-транслятора e2k или lcc

От x86-транслятора -- ничем, поэтому считаю это приемлемым. lcc? Его
где-то надо запустить. Где-то нужно запустить несвободную программу. В
случае с x86/ARM/SPARC/MIPS/whatever я, грубо говоря, могу просто в
шестнадцатеричном редакторе и документацией по процессору сделать
загрузчик/ОС/whatever, записать на накопитель и запустить его на целевом
компьютере. Чёткое детерминированное поведение (CPU же детерминирован,
можно считать). Я могу написать свою ОС для Эльбруса? Могу разве на lcc
написать загрузчик и всё что нужно чтобы полностью портировать
какой-нибудь Plan9, управлять памятью и процессами? Насколько понимаю --
нет, так как это не уровень языка Си, а необходимы какие-то
привилегированные инструкции. Хочется сказать что это не general purpose
компьютер, ведь я не могу делать всё что захочу. Конечно, можно будет
сказать что на Си можно написать любой алгоритм, любое вычисление, ведь
мне же нужно, грубо говоря, АЛУ+память+IO и всё это он даст, пускай и в
виде процесса ОС -- вот только даст ещё и кучу неописанного и не
известного поведения, так как есть закрытая ОС (как минимум, которую
даже не дизассемблировать). Математику можно посчитать -- хорошо. Даже
сравнить с результатами вычислений на других компьютерах. Но это же не
даёт мне возможность *по человечески* портировать какую-нибудь ОС и
работать с ней, как я захочу? Возможность только работать под их ОС?
Спасибо, но нет, тем более проприетарной и закрытой. Но эти рассуждения
демагогией становятся некой уже.

>Это как раз тот случай, когда вместо запрятывания логики в железо, в
>которое залезть в домашних условиях проблематично, производитель даёт
>нам программно-аппаратный комплекс, программную (пусть и закрытую,
>проприетарную) часть которого можно изучать.

Ну мы уже затрагивали тему reverse engineering-а и прочего. Я при своём
мнении: закрытое ПО это не возможность "изучать". Это дорого настолько,
что проще не связываться. И в "железо" можно залезть -- вопрос цены.
Дома -- настолько дорого, что дома никто не будет пытаться. Закрытое ПО
-- дешевле, но всё равно оно не предназначено для "изучения". Что
закрытое ПО, что железо -- одна фигня: производитель не хочет делиться
внутренностями и устройством и помогать нам как-либо в этом.

комментарий 2:

From: kmeaw
Date: 2020-12-02 18:34:12Z

> В случае с x86/ARM/SPARC/MIPS/whatever я, грубо говоря, могу просто в
> шестнадцатеричном редакторе и документацией по процессору сделать
> загрузчик/ОС/whatever, записать на накопитель и запустить его на целевом
> компьютере. Чёткое детерминированное поведение (CPU же детерминирован,
> можно считать).

C-машину тоже можно считать детерминированной. Можно и в
шестнадцатеричном редакторе, и в обычном текстовом, написать
C-программу.

> Я могу написать свою ОС для Эльбруса?

Используя только C - нет. Но вообще - да, у Embox есть некоторые успехи
в этом направлении:

https://github.com/embox/embox/tree/master/src/arch/e2k
https://habr.com/ru/company/embox/blog/421441/
https://habr.com/ru/company/embox/blog/485694/

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

На ассемблере e2k написано совсем чуть-чуть кода, почти вся ОС как была
на кроссплатформенном C, так и осталась.

Завалишин тоже пытался портировать свою ОС на e2k, но результатов я пока
не видел:

https://github.com/dzavalishin/phantomuserland

> необходимы какие-то привилегированные инструкции

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

> Возможность только работать под их ОС?

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

От МЦСТ по запросу можно получить кросс-компилятор для x86 под e2k.
Можно найти доступную машину с родной ОС и компилировать свой код на
ней.

> Я при своём мнении: закрытое ПО это не возможность "изучать".

С такой перспективы e2k становится таким же закрытым, как и x86. Без
реверс-инженеринга у нас есть набор проприетарных кусочков, из которых
мы можем собирать свои собственные программы.

Резюмируя:

На x86 я могу написать код на C, который пройдя через свободный
компилятор превратится в некий промежуточный код, который внутри
процессора (несвободным) механизмом оттранслируется в то, что реально
будет исполняться железом.

На e2k я могу написать код на C, который пройдя через свободный
/bin/cat превратится в некий промежуточный код (в данном случае просто
совпадающий с исходным), который (несвободный) компилятор оттранслирует
в то, что реально будет исполняться железом.

Во втором случае я могу без всякого реверс-инженеринга убедиться в том,
что повторная компиляция моего кода фиксированной версией компилятора
приводит к одинаковой последовательности операций.

В первом случае это проверить проблематично. Возможно, кто-то даже
находил контрпримеры, когда внешние условия (состояние ОС и железа)
приводили к изменению поведения внутреннего транслятора x86->uop.

комментарий 3:

From: Sergey Matveev
Date: 2020-12-02 19:45:42Z


Всё что вы написали я и называю демагогией. Попыткой подмены понятий и
прочего. Имея документацию x86 (ассемблер) я могу используюя свободное
ПО написать для него любую программу? А портировать другую ОС, дописав в
неё чуть-чуть недостающего ассемблера? Могу. Я могу аналогичное
проделать для e2k? Нет, так как нет документации. Мне предлагают
использовать их несвободный инструментарий? А может мне проще напрямую у
МЦСТ просто заказывать программы чтобы они мне писали? Разницы нет
никакой для меня. Даже меньше головной боли будет. А портировать другую
ОС я не смогу, так как нет документации.

Вариант с переносом какого-нибудь Bochs собранного и запущенного на e2k,
а внутри него уже нужной мне ОС -- это пускай суды рассматривают,
которые славятся абсолютно неразумным с человеческой точки зрения
подходом (ведь адвокаты именно этим и занимаются -- подменами понятий,
демагогией), но адекватным с формальной точки зрения. Ведь и на JS
внутри броузера тоже можно запускать наверное какие-то эмуляторы.

МЦСТ предлагает несвободные инструменты для того чтобы на e2k можно было
выполнять ряд задач на Си. Sun когда-то предлагала какие-то
JavaStation-ы в которых типа всё на Java можно было писать. Просто ни
то, ни другое не является general purpose компьютером в обычном
понимании. Хотя формально они Тьюринг-полные и позволяют любую
математику аналогично выполнить как и на x86/MIPS/SPARC/whatever. Но мы
не в суде, поэтому мыслим здраво, а не формальными понятиями. Так то
можно до бесконечности притягивать за уши термины, определения и
границы. Но десятки архитектур "ведут" себя по человечески, предоставляя
документацию, а МЦСТ ведёт как компании типа Apple и Microsoft.

Факт остаётся фактом: без несвободного ПО на e2k ничего не сделать. Для
x86 (и десятков других архитектур) -- можно. Вариант с прослойкой в виде
транслятора между blackbox e2k и x86 командами меня устраивает. А
заставлять запускать что-то закрытое на МОЁМ личном компьютере (не e2k,
а на котором я хочу что-то кросс-компилировать для него) -- без
комментариев.

>приводили к изменению поведения внутреннего транслятора x86->uop.

Это я всё понимаю. Но очевидно что всё это притянуто за уши и вы просто
жонглируете словами и понятиями. Как мне портировать Plan9 на e2k? Пока
никак. Ещё раз повторюсь -- по человечески, а не перекомпилировать
какой-нибудь Bochs и запустить в нём мой Plan9 или запустить
Plan9-for-JS в броузере (допустим, что такой есть). Вы мне скажете что
задача выполнена -- на этом железе я могу запустить Plan9 и видеть на
экране результат.

Embox в статье описывает что по сути он просто тыкает палочкой и смотрит
что получится. Копируют какой-то код (работает -- не трожь!) и пытаются
заставить всё это работать. Любой кто делает несвободный код думает так:
сделаю жизнь разрабам сложнее, чтобы больше иметь власти и контроля в
своих руках, чтобы больше грести денег, пользуясь своим положением.
Никто кто делает несвободное ПО никогда не будет думать о взаимовыгодном
сотрудничестве, о создании действительно полезного и стоящего творения,
о том чтобы улучшать что-то в мире и жизни людей. Любой монополист
всегда точно также превратится в ублюдка, с человеческой точки зрения,
ибо почти никто не в состоянии устоять перед своим положением и
безвыходностью других людей.

Это нормально, такова природа людей, так делают деньги, но если у меня
есть выбор как можно меньше участвовать в этих марафонах "лечь под
одного, потом лечь под другого", то я хотел бы стараться больше иметь
дела с теми, у кого мотивы не только денежные. На работе был коллега
который принципиально отвергал вопросы мотивов человека. Я же
противоположен и для меня мотивы людей в этих вопросах и темах важны.
Всё это уже вопросы этики, мировоззрения, ценностей и прочего. Для
кого-то и проституцией не зазорно заниматься. Для кого-то брать проценты
с друзей которым дал в долг. Кому-то работать с Apple, кому-то с e2k.
Хотя мне вот мотивы у музыкантов наоборот редко важны и я могу слушать и
наслаждаться музыкой конченых
сатанисто-нацисто-фашисто-феминисто-либерало-whatever-ов,
лишь бы музыка нравилась. Видимо, так и у других людей относительно ПО:
лишь бы программа конечная нравилась. Но многие не будут использовать
ReiserFS, потому что Ганс убийца. А вот тут мне уже пофиг, ибо его
личная жизнь и профдеятельность не связаны (надеюсь). А вот если бы Ганс
начал переименовывать blacklist в XXXlist (что там сейчас "кошерно"?),
то мне бы это сильно не понравилось, ибо он свою личную замашку, мне не
нравящуюся, несёт в ПО. А ведь некоторые и политику ещё несут (вот
принципиально не хотелось бы использовать Nano Pussy Riot, хотя у него и
дальше там тьма других замашек). �� идеале лучше не показывать своих
мотивов, взглядов, политики и прочего и действительно делать только ПО,
когда речь про ПО. А музыкантам на сцене "толкать" только музыку, а не
свои личные вегетарианства/политику и прочее. Профессионалы в основном
так и делают, на самом деле. Но когда человек/компания закрывают ПО, то
мотивы в 100% случаев не могут быть благими.

комментарий 4:

From: kmeaw
Date: 2020-12-02 21:21:45Z

> Я могу аналогичное проделать для e2k? Нет, так как нет документации.

> А портировать другую ОС я не смогу, так как нет документации.

Разработчики Embox же смогли.

http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter10.html

https://github.com/nrdmn/elbrus-docs

Документация есть. Пусть и не такого качества, как для многих других
известных архитектур.

Просто я не могу понять смысл ограничения на реверс-инженеринг. Мне
кажется, что практически каждый программист, который писал (а не
копировал куски кода из какого-нибудь osdev tutorial) свою первую
ОС для IBM PC лет 20 назад, хоть что-нибудь реверс-инженерил. Зачем
искусственно себя ограничивать только чтением документации, если часто
бывает быстрее взять и попробовать, воспользоваться методом проб и
ошибок, и посмотреть, что получится. А потом и читать документацию будет
гораздо проще - она сразу станет сильно понятнее.

> Как мне портировать Plan9 на e2k?

Если запретить себе запускать любой несвободный софт, то взять описание
системы команд и скомпилировать (у себя в голове или написав свои
собственные инструменты) платформо-зависимую часть Plan9. Попытаться
запустить полученный бинарник на железе. Увидеть, что сломалось, долго
искать ошибку, исправить её и повторять этот цикл до достижения
приемливого для использования результата.

Написать Форт-систему для незнакомой платформы можно за неделю вечеров.

http://git.annexia.org/?p=jonesforth.git

Не находясь в изоляции, написать неоптимизирующий компилятор
подмножества C, способный скомпилировать более полноценный компилятор C
- за пару месяцев.

http://web.archive.org/web/20160314213928/http://www.rano.org/bcompiler.html

https://bellard.org/tcc/tccboot.html

Вряд ли получится что-то, способное тягаться с lcc по степени
оптимизированности e2k-кода, но работать будет.

> можно запускать наверное какие-то эмуляторы

> не является general purpose компьютером в обычном понимании

У меня где-то дома лежит ноутбук Sony Vaio C1 на процессоре Transmeta
Crusoe. У него в ROM прошит эмулятор x86, который съедает какой-то кусок
памяти для своих нужд, и занимается трансляцией x86-кодов в свои
VLIW-аналоги.

Если неподготовленному человеку дать этот компьютер, то ему никогда не
придёт в голову, что он какой-то особенный. Он выглядит и ведёт себя
точно так же, как самый обчыный general purpose компьютер. У него есть
привычный интерфейс BIOS Setup, он грузит обычные (почти, он эмулирует
i686, но без когда-то недокументированной инструкции CMOVxx)
операционные системы и программы для x86.

Штатных инструментов от производителя для модификации этого эмулятора в
ROM нет. Альтернативной свободной реализации тоже нет. Документации на
настоящий instruction set этого процессора, достаточной для того, чтобы
такую реализацию написать, я тоже не находил. Ни одной ОС, даже с
закрытым кодом, способной исполняться нативно на этом процессоре я не
видел.

Делает ли комбинация этих свойств эту машину не general purpose
компьютером? Ставит ли это компании Transmeta и Sony в один ряд с Apple
и Microsoft?

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

Не помню точно, в какой стране, но Sony обошла пошлину на игровые
приставки, классифицировав свой продукт, как компьютер, предлагая
запускать на нём Yellow Dog Linux (используя подписанный вторичный
загрузчик, который настраивал гипервизор так, что видеоускоритель
становится недоступным).

Внутри стоял процессор Cell с двумя вычислительными ядрами PowerPC,
набор инструкций которых хорошо документирован и поддерживается
популярными (в том числе сводобными) тулчейнами. А вот про устройство
самой приставки Sony никому ничего не рассказывала. И SDK, и отладочный
набор железа мало кому давала (и то за большие деньги).

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

Ещё у меня есть несколько тонких клиентов Dell Wyse S10. Они работают на
процессоре National Semiconductor (теперь AMD) Geode GX, к которому
подключен чип-компаньон Geode CS5536. Вместе с хитрым софтом этот
проргаммно-аппаратный комплекс умеет прикидываться IBM PC-совместимым
компьютером.

Однако, чтобы это было возможным, в прошивке есть SMM-обработчик,
использующий плохо документированные особенности процессора, позволяя
обработчику быть невидимым для ОС и перехватывать контроль над системой,
эмулируя типичную для IBM PC периферию - системный контроллер, таймер,
VGA-совместимую видеокарту, контроллер питания, SuperIO и другие
устройства. Я писал и в AMD, и в Dell, и местному продвацу похожих
машин, просил у них хоть какой-нибудь SDK, документацию и/или исходники.
Ожидаемо, я ничего от них не получил.

Такой компьютер уже меньше похож на general purpose машину с точки
зрения пользователя. Например, большую часть флеш-памяти занимает некая
WTOS, содержащая сетевой стек и реализацию терминального клиента для
серверов Citrix и Microsoft, а BIOS Setup ограничивается лаконичным
меню, где можно лишь поменять пароль, задать время и поменять порядок
загрузки (PXE, IDE, USB).

Те же вопросы: это general purpose компьютер? Какой можно сделать вывод
относительно поведения компаний Dell, National Semiconductor, AMD?

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

Безусловно, Sony и Dell сделали мою жизнь сложнее. Они (или их партнёры
в лице разработчиков железа и прошивок) имеют над этими машинами
некоторый контроль - по крайней мере, у них его больше, чем если бы это
было какое-нибудь из open core на FPGA, например.

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

Все описанные устройства я могу использовать, как general purpose
компьютеры - на них запускается Linux, который я могу собрать из
исходников с помощью свободных инструментов, и для которого я могу
собирать прикладные программы. Для того, чтобы заставить работать
загрузчик, мне нужны либо несвободные инструменты (которых у меня просто
нет, и даже продавать их мне никто не собирается), либо
реверс-инженеринг несвободного кода.

Стоит ли мне в чём-то винить эти комп��нии? Действительно ли у них была
мотивация нанести мне вред?

Станет ли e2k пригодной для использования, если наберётся критическая
масса хакеров, которые напишут патчи для binutils и clang/llvm?

Стоит ли помогать этим хакерам? Железом? Вступлением в их ряды?
Спонсированием таких разработок?

комментарий 5:

From: Sergey Matveev
Date: 2020-12-02 22:54:15Z


>Разработчики Embox же смогли.

Методом проб и ошибок. Это тот случай когда кто-то взялся за то, для
чего нет документации и уважающий себя программист просто не стал бы
связываться, но всё же смог чего-то достичь. Я нисколько не пытаюсь
унизить или проявить неуважение к разработчикам Embox, как к
профессионалам. Но я недавно в блоге упоминал Мигеля де Икаса и как
Столлман на него наехал, назвав предателем. Кто-то его будет считать
наоборот молодцом, что расширил границы .NET и вообще его Mono даже в
смартфонах штатно. Но я на стороне Столлмана. Или кто-то считает
нормальным подписать у Microsoft загрузчик для Linux (я -- нет), мол
пускай Microsoft, но зато будет загрузчик. Кто-то считает Сноудена
героем и молодцом, а для меня он в первую очередь -- предатель своей
родины, пускай мне, как гражданину вражеского гос-ва, это даже и на
руку. С этической стороны я не одобряю Embox (хотя, моего мнения и не
спрашивали) и поэтому не могу ставить их в пример что "они же смогли".

>Документация есть. Пусть и не такого качества, как для многих других
>известных архитектур.

Сейчас я диванный эксперт, но говорили что она далеко не полная,
покрывает лишь часть которую можно для вставки в Си код использовать, но
это не полноценное описание инструкций процессора чтобы можно было
написать ОС. Или же эти люди не правы, соответственно и я, и получается
что описание команд ассемблера то есть и можно брать и писать свободный
компилятор? Если так, то тогда у меня вообще никаких претензий к МЦСТ
нет. То что на *данный момент* есть только один несвободный компилятор
-- ну бывает, это вопрос времени когда кто-то по документации напишет
свободный. Но что-то я нигде не слышал чтобы полностью ассемблер был
описан (в достаточном для написания ОС виде).

>Просто я не могу понять смысл ограничения на реверс-инженеринг. Мне
>кажется, что практически каждый программист, который писал (а не
>копировал куски кода из какого-нибудь osdev tutorial) свою первую
>ОС для IBM PC лет 20 назад, хоть что-нибудь реверс-инженерил.

Я как программист достаточно слаб и тут ничего не смогу сказать или
предположить. Если речь про загрузчики или какие-то простые базовые
ядерные вещи, которые можно понять где находятся в бинаре, которые в
принципе небольшого размера, то уверен что тут reverse engineering
дешёвый и не отнимает много времени и не спорю что проще попробовать и
посмотреть что будет. Но это про простейшие же случаи. А когда речь про
микрокод WiFi/CPU или вон целый компилятор lcc, то нереально же за
вменяемое время разобраться что там, да как, ибо это не ядро/загрузчик.

>Зачем искусственно себя ограничивать только чтением документации, если часто
>бывает быстрее взять и попробовать, воспользоваться методом проб и
>ошибок, и посмотреть, что получится.

А вот например, если не касаться системного программирования, а обычного
с Python/Go библиотечками, то полезно бывает ориентироваться только на
документацию. Чтобы понять насколько она зачастую ужасна и даже
бесполезна -- чтобы понять что именно и конкретно нужно разработчику и
понять как надо писать доку. Хорошая документация -- значит добротное
отношение к проекту. Отсутствие (или неактуальность/бесполезность) --
значит наплевательское отношение, что означает или просто в целом плохое
качество или просто нежелание помогать окружающим. Ведь часто же бывает
что какая-нибудь команда/организация выложит свои наработки, для которых
доки нет (или написана на "отвали") потому что все внутренние
разработчики и так в курсе обо всём, а выложили просто чтобы выложить,
попиариться. Часто бывает (по моему опыту, конечно же) вреден метод проб
и ошибок потому, что ты на самом деле не понимаешь что творишь, но одна
из "проб" выдаёт что тебе нужно и ты успокаиваешься и останавливаешься
на этом, на самом деле не понимая что и как сделал. А потом это больно
аукнется в будущем.

>Если запретить себе запускать любой несвободный софт, то взять описание
>системы команд и скомпилировать (у себя в голове или написав свои
>собственные инструменты) платформо-зависимую часть Plan9. Попытаться
>запустить полученный бинарник на железе. Увидеть, что сломалось, долго
>искать ошибку, исправить её и повторять этот цикл до достижения
>приемливого для использования результата.

Абсолютно приемлемо. Но снова вопрос про: полное ли описание команд
(достаточных для запуска Plan9 и его програм) и их кодирования выложено?
Если да, то тогда я могу забрать назад десятки килобайт всего что
написал и высказал по поводу e2k и в очередной раз сделать вывод что
нефиг слушать других диванных экспертов из Интернета (которые такую чушь
пишут по темам в которых я чуть больше разбираюсь!). И в данном случае я
считаю нормально делать reverse engineering просто считая его читерством
ради скорейшего достижения результата, лишь бы понимание в итоге было
всего, а не просто тупое копирование части загрузчиков/ядер. Просто
отсутствие доки -- это значит задача штатно не выполнима. Наличие доки
-- задача выполнима, просто не так быстро как с reverse engineering-ом
простых вещей, но главное что она выполнима штатно.

>Вряд ли получится что-то, способное тягаться с lcc по степени
>оптимизированности e2k-кода, но работать будет.

Вопрос оптимизированности тут совершенно второстепенный (для меня).

>Делает ли комбинация этих свойств эту машину не general purpose
>компьютером? Ставит ли это компании Transmeta и Sony в один ряд с Apple
>и Microsoft?

Если Crusoe может выполнять API (ассемблерные инструкции) который можно
получить/скачать (x86) и выполнять, то я считаю всё ok. e2k который
запущен с транслятором x86, который там на отдельной флешке (вроде же?),
по мне равносилен и претензий нет. Имея книжечку x86 и редактор где-то,
я могу написать ОС для него. На каком уровне находится "флешка" с
транслятором-микрокодом меня не волнует. Повторюсь: весь мой hate
относительно МЦСТ отталкивался только от того что я в Интернете читал
только про отсутствие описания инструкций процессора достаточных для
запуска ОС. А это значит что нет никакой книжечки по которой я мог бы
сварганить ОС для e2k. Если про не полноту описания ассемблера (хотя мне
казалось что это чуть ли не "официальные" лица типа Шигорина писали)
является неправдой, то претензий к e2k/МЦСТ у меня нет вообще. Но даже
на работе никто никогда не опровергал то что e2k ассемблер закрыт.

>Это general purpose компьютер? Про поведение Sony вопрос задавать не
>буду, они слишком много плохого сделали публично против людей, которые
>хотели инвестировать своё время в разработку под их железо, поэтому
>ответ для меня и так очевиден.

Ну если есть описание CPU, но нет описание как с ним и с его окружением
взаимодействовать, то очевидно что сделать с ним вряд ли что получится.
Насколько понимаю, Apple M1 сейчас же в таком состоянии -- внутри
какой-то ARM, но никакого описания "обвязки" и поэтому уже взялись
reverse engineer-ить это. Пока задача не выполнена (ведь Apple такие же
козлы как и Sony -- всё на свете делают несовместимым и закрытым,
поэтому навстречу разработчикам не пойдут), то использовать этот M1 или
поделие от Sony не представляется возможным, значит и не general purpose
компьютер.

>Те же вопросы: это general purpose компьютер? Какой можно сделать вывод
>относительно поведения компаний Dell, National Semiconductor, AMD?

Я думаю эти тонкие клиенты не презентуются как general purpose
компьютеры. Как и банкоматы -- внутри же OS/2, Windows, whatever, но мы
их не воспринимает и не ожидаем от них general purposeability, поэтому
никаких претензий. К клиентам Dell/AMD (как и Sun Ray прежде) тоже по
моему нареканий нет, ибо их и не представляют как компьютеры общего
назначения. Они "чисты" :-)

>Но они сделали вещи, которые я могу полезно использовать для себя. Моя
>жизнь несомненно стала чуточку лучше от обладания этими устройствами.
>Своё положение я никак не могу назвать безвыходным.

По хорошему все эти компании, как и бизнесмены в целом -- вряд ли
заправляются "хорошими" честными, добропорядочными, заботливыми людьми.
Просто кто-то больше наглеет/охреневает, кто-то меньше. Apple я вообще
считаю лютым врагом человечества, а миллионы людей принципиально не
будут использовать ничего где нет логотипа яблока. Google та ещё срань,
но они взяли и заманили к себе крутых хакеров и развивают Go и всякие
другие хорошие штуки, которые лично мою жизнь сделали лучше, а вредят
мало, ибо их сервисов я просто не использую. Согласен что не всё
чёрно-белое (хотя Apple для меня абсолютный мрак :-)) и, в зависимости
от ценностей людей, все эти нехорошие бизнесмены могут что-то делать и
хорошее (относительно разных людей).

>Для того, чтобы заставить работать
>загрузчик, мне нужны либо несвободные инструменты (которых у меня просто
>нет, и даже продавать их мне никто не собирается), ��ибо
>реверс-инженеринг несвободного кода.

У меня тут вопрос: а зачем? Если нужен general purpose компьютер, то
наверное проще купить "нормальный" ПК, чем возиться с этими
устройствами. Если just-for-fun, ради интереса и всё такое -- без
вопросов. Но в целом то ведь незачем?

>Стоит ли мне в чём-то винить эти компании? Действительно ли у них была
>мотивация нанести мне вред?

То что вы не можете (легко) использовать не предназначенные для general
purpose PC устройства как GP PC -- наверное это точно не их проблема.
Если я не могу использовать Си программы на JavaStation, то это точно
моя проблема. Но e2k позиционируется как GP PC, поэтому я и жду от него
соответствующего удобства в работе.

>Станет ли e2k пригодной для использования, если наберётся критическая
>масса хакеров, которые напишут патчи для binutils и clang/llvm?
>Стоит ли помогать этим хакерам? Железом? Вступлением в их ряды?
>Спонсированием таких разработок?

Если полноценная дока по e2k инструкциям имеется, то претензий к
e2k/МЦСТ нет. Просто пока, получается, нет свободной реализации, как
когда-то не было свободного Unix и Ричарду Столлману конечно какое-то
время приходилось сидеть на проприетарном ПО создавая на нём свободный
GNU. Это вопрос времени, но задача штатно выполнима. С одной стороны
хочется поддерживать тогда хакеров которые бы по этой доке писали e2k
поддержку.

С другой у меня пока в голове нет ответа на вопрос "почему бы не
вкладываться лучше в Байкал/Комдив?", у которых хотя бы MIPS/ARM или в
Эльбрусы на основе SPARC? VLIW обычному пользователю нафиг не сдался.
IA64 показал что ну не могут general purpose компиляторы (а точнее люди
их пишущие) хорошо под него оптимизировать. Зачем спонсировать что-то
что ещё пока никак не поддерживается в свободном ПО, когда есть куча
альтернатив с имеющейся поддержкой? Но тут наверное и куча политики и
экономики и возможно есть нормальные причины. А может быть и нет? И
просто МЦСТ умеет пилить деньги, а Байкал/whatever не могут, возможно
потому что не дают кому надо на лапу, нет связей, и тому прочее? Я опять
в режиме диванного эксперта, но чисто технически мне не понятно зачем
вообще e2k для general purpose задач (я верю, после IA64, что VLIW это
так себе подход, годный только для узкоспециализированных задач)? Почему
не SPARC версию Эльбруса делать?

Если же доки нет полноценной, то я против чтобы люди тратили время на
разбирательства с закрытой штукой, на reverse engineering -- лучше бы
чем-то более полезным занялись. Специалистов в мире и так мало, а тут
ещё с дичайше низким КПД они будут растрачиваться на reverse engineering
закрытого поделия. Пускай даже осилят это и добавят e2k поддержку.
Печально всё равно будет сколько сил было на это потрачено, только
потому что по человечески МЦСТ не хочет "дружить" с разработчиками.

А вообще я деньгами прежде старался поддерживать проекты которые
стараются дружить с СПО/разрабами. Приобретал не дешёвый (тогда) Lemote
YeeLoong, ещё отдавая кучу денег таможне, чтобы поддержать MIPS, а не
жить на x86 дурацком (он кстати до сих пор работает, но имеет одну
аппаратную багу которую я не знал что можно обойти и поэтому перестал им
пользоваться), хотя YeeLoong был и очень нешустрым относительно x86
аналогов. Приобретал тоже не дешёвые (особенно последний) OpenMoko
Freerunner и GTA04, которые и качеством были хуже и софта типа нет, но я
ради спонсирования для будущего готов был брать. Если бы не зависимость
от FreeBSD, то я бы точно сейчас сидел за MIPS32 Байкалом из Чип-и-Дип-а
за 40тыс. рублей, хотя даже YeeLoong имел MIPS64. Если бы Эльбрус
продавал SPARC-и (на которых можно без проблем запускать *BSD/illumos/и т.д.)
за вменяемые цены (допустим 1-2 зарплаты максимум), то я бы обязательно
поддержал (приобрёл), пускай и пришлось бы терпеть неудобства из-за
производительности, но зато я на RISC, без IntelME говн, ещё бы и в
Зеленограде сделанном, без поддержки монополии Intel и стран типа США.

Но Эльбрус не идут навстречу (пока я отталкиваюсь от того, что верю что
дока выложенная там далеко не полноценная). Зачем мне e2k, когда можно
же ведь было бы продолжать развивать SPARC или что-то другое совместимое
(MIPS/ARM/PowerPC), тем более что всё равно же это производится в
Тайване? В Байкале вообще там директоров сажают и наверное компанию
небось прикроют. А КОМДИВы простому смертному не купить. Всё вот как-то не
очень.

комментарий 6:

From: kmeaw
Date: 2020-12-03 00:34:08Z

Спасибо за столь подробный ответ, теперь позиция относительно e2k и её
причина мне понятны.

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

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

Неэффективный прикладной код почти наверняка можно написать с
использованием имеющейся документации. Насчёт системного я теперь
затрудняюсь утверждать - попробую завтра попросить коллег задать этот
вопрос специалистам МЦСТ.

Disclaimer: я никак ни с e2k, ни с МЦСТ не связан, профессиональным
программированием под e2k не занимаюсь, просто у меня есть доступ к
одной машине, и к нам приходили МЦСТшники с лекцией, которая в том числе
содержала рекламу. Иногда я помогаю коллеге, который тоже никак не
связан с e2k, запускать на этой машине всякий разный софт, в основном
игрушки.

> С другой у меня пока в голове нет ответа на вопрос "почему бы не
> вкладываться лучше в Байкал/Комдив?", у которых хотя бы MIPS/ARM или в
> Эльбрусы на основе SPARC? VLIW обычному пользователю нафиг не сдался.

Я пробовал задавать такой вопрос на лекции специалистам МЦСТ, из того,
что понял и запомнил:

Это альтернатива подходу взять готовое ядро, пачку чужих IP-блоков,
добавить пару своих и назвать это своим процессором. Чужие блоки нужно
лицензировать, это накладывает ограничения на их использование,
увеличивает цену, снижает гибкость и скорость внесения изменений силами
только своих разработчиков. А ещё появляется уверенность, что в своём
ядре нет чужих закладок; не смотря на производство на чужих мощностях,
добавить закладку в готовую топологию без исходников почти нереально, а
выборочную сверку какого-нибудь одного узла можно выполнить для тестовой
партии.

VLIW хорош тем, что можно обновлением компилятора и последующей
пересборкой всего прикладного софта увеличить производительность машины,
не меняя физическое железо. Это особенно полезно, когда у нас нет
собственного производства - даже в условиях приостановки выпуска новых
чипов можно наращивать производительность уже выпущенных компьютеров.

VLIW можно сильнее наращивать вширь, увеличивая производительность не
только за счёт роста частоты и числа ядер.

Могу также высказать своё предположение, что текущие машины могут
позволить себе большее время работы компилятора, чем во времена IA64, а
значит найти более эффективное решение тем, где требуется перебор
вариантов. Но официального подтверждения (правда и опровержения тоже)
этому факту мне получить не удалось, и некоторые люди сомневаются в его
реалистичности.

Современному пользователю (прикладному разработчику) и x86 instruction
set не интересен, лишь бы была совместимость со всем нужным софтом,
компилятор компилировал, а весь комплекс в целом достаточно быстро
работал.

> Но Эльбрус не идут навстречу

Ребята из МЦСТ на многие наши вопросы отвечали "мы лежим в этом
направлении". То есть постепенно и с документацией станет лучше, и с
софтом. Но очень постепенно. Насколько я понял, в их текущей структуре
многие процессы построены так, как удобно госзаказчику, которому не
очень понятно, зачем дружить с разработчиками СПО, и то, что доступно
сейчас, случилось или случайно, или благодаря энтузиастам внутри МЦСТ.

Например, публичную документация на систему команд (не включающую в
себя привилегированные инструкции и служебные сегменты) выложили
относительно недавно, 31 мая 2020 года.

комментарий 7:

From: Sergey Matveev
Date: 2020-12-03 07:58:45Z


>Неэффективный прикладной код почти наверняка можно написать с
>использованием имеющейся документации. Насчёт системного я теперь
>затрудняюсь утверждать - попробую завтра попросить коллег задать этот
>вопрос специалистам МЦСТ.

Про прикладной у меня даже нет сомнений что можно написать с имеющейся
документацией. Собственно, нужно же как-то мочь VLIW делать эффективным.

>Это альтернатива подходу взять готовое ядро, пачку чужих IP-блоков,
>добавить пару своих и назвать это своим процессором. Чужие блоки нужно
>лицензировать, это накладывает ограничения на их использование,
>увеличивает цену, снижает гибкость и скорость внесения изменений силами
>только своих разработчиков. А ещё появляется уверенность, что в своём
>ядре нет чужих закладок; не смотря на производство на чужих мощностях,
>добавить закладку в готовую топологию без исходников почти нереально, а
>выборочную сверку какого-нибудь одного узла можно выполнить для тестовой
>партии.

Хм, хорошо. Тут я вообще мало что понимаю, но считал что
"лицензирование" это всего-лишь просто типа некой сертификации когда
можно повесить shield-ик что оно совместимо с MIPS/SPARC/ARM/whatever. Я
слышал какую-то историю что китайские Lemote поэтому официально не
считаются MIPS процессорами, потому что не лицензируют, чтобы не
платить. Это наверное могло бы где-то создавать проблемы, там где
требуется XXX-совместимость, которой официально нет, но в Китае не
создаёт. Я считал что разработчики сами как угодно с нуля делают
процессор.

Если всё на самом деле не так и покупаются готовые "схемы", то да, это
безусловно однозначно хуже чем полностью своё сделанное. Ну и цен на
лицензирование тоже не знаю. Ok, тогда причину принимаю.

>VLIW хорош тем, что можно обновлением компилятора и последующей
>пересборкой всего прикладного софта увеличить производительность машины,
>не меняя физическое железо.

Про теоретическую пользу VLIW я начитан у Таненбаума (про EPIC
Itanium-ов). И в теории только за этот подход. Но на практике за 20 лет
для IA64 так и не смогли написать компиляторы которые бы хорошо
заполняли VLIW/EPIC блоки команд, по полной утилизируя процессор. И
многие умные головы доказывали что это и не возможно, так как компилятор
не знает заранее какие данные будут подаваться обрабатываться и на
практике сколько будет каких-нибудь там циклов и вообще поведения
программы. С текущими процессорами которые на лету "эвристику"
собирают/считают и на основе неё, на основе того что оседает в кэше и
при переименовании регистров, получается хорошая оптимизация. Ну или это
может сделать человек, зная особенности задачи. Ведь даже в Python мы
задумываемся когда надо сделать try/except KeyError, а когда if key in
dict, исключительно отталкиваясь от специфики задач. А процессор не
может заранее про задачи ничего знать, имея на руках голый код.

>Современному пользователю (прикладному разработчику) и x86 instruction
>set не интересен, лишь бы была совместимость со всем нужным софтом,
>компилятор компилировал, а весь комплекс в целом достаточно быстро
>работал.

Безусловно. Я то нисколько за x86 не топлю, наоборот считаю что он
должен был бы помереть 30 лет назад. x86 тут потому что у e2k есть
транслятор с него на e2k. Был бы там прозрачный транслятор с SPARC, то
говорил бы про SPARC.

>Ребята из МЦСТ на многие наши вопросы отвечали "мы лежим в этом
>направлении".

И вот это я интерпретирую как ответ на "отвали". Может быть
действительно "лежат в этом направлении", а может это просто банальная
отговорка ("мы вас услышали", "мы подумаем над этим, ваше мнение очень
важно для нас", и т.д.). Просто уж больно долго лежат. Я слышал что всё
так плохо в плане открытости из-за того что это в первую очередь
финансировалось военкой, которая очевидно совершенно далека от ИТ реалий
и само собой не хочет ничего открывать и МЦСТ тут ничего не может
поделать, ведь кто платит, тот и музыку заказывает. Но может быть это
тоже отговорка? Может плохо стараются объяснить отсутствие минусов
открывая документацию/описание? Одно дело обещать, а другое дело реально
сделать. И тут можно только на доверии и надежде строить какие-то планы,
мол "ладно, пока покомпилируем несвободным lcc, а там и свободная
реализация подъедет, когда наш прикладной софт будет написан". Но лично
для меня МЦСТ это компания про которую я ничего не знаю, ни плохого, ни
хорошего, грубо говоря. Может быть они активно пилят деньги, с низким
КПД, пользуясь своим монополистическим положением что у них единственных
полностью свой разработанный процессор, а не купленные готовые схемы
SPARC/MIPS/ARM/whatever? И денег им вроде как немеренно вкладывает
государство, но пока всё это производство e2k всё равно делается за
рубежом, в отличии от SPARC-совместимых версий в Зеленограде. Я понимаю
что это невероятно дорого у себя это всё поднять и осилить и на данный
момент только Китай, кроме США, это смог сделать (производство
нормальных современных процессоров полностью независимо от США), но мне
казалось (опять же в режиме диванного эксперта) что денег в МЦСТ так
много, что осилить полностью своё производство можно было бы. Ведь
завтра Тайвань, по приказу США, скажет "до свидания" и нет e2k у нас
никакого. В общем пока я не очень уверен в честности (хорошем КПД)
использования всех этих денег которые вливает гос-во, значит и мотивы не
самые благие (попилить денег, а не сделать как можно быстрее, массовее
хорошую достойную замену зарубежным backdoor-ed процессорам (это только
рекламная ширма)), в отличии от китайских YeeLoong, которые могут для
всей страны, для каждого человека делать MIPS64-совместимые (а
соответственно и весь софт будет работать уже написанный)
компьютеры/ноутбуки за абсолютно адекватную стоимость.

комментарий 8:

From: kmeaw
Date: 2020-12-07 10:31:23Z

> Насчёт системного я теперь
> затрудняюсь утверждать - попробую завтра попросить коллег задать этот
> вопрос специалистам МЦСТ.

Спросил. Увы, всё плохо - документацию получить можно, но под NDA и для
тех, кто уже купил Эльбрус.

Сгенерирован: SGBlog 0.34.0