- комментарий 0:
From: kmeaw
Date: 2026-05-14 09:57:42Z
> А Эльбрус закрытый и там нет FreeBSD.
А если будет спортирована современная версия FreeBSD, а именно дописана в
исходниках платформозависимая часть ядра, доработан linux(4) для обеспечения
бинарной совместимости с уже существующими e2k-программами, доработана в
исходниках и пересборана базовая система с помощью lcc и clang из ОС Эльбрус,
то что нужно будет открыть, чтобы платформа стала пригодной для использования?
- комментарий 1:
From: Sergey Matveev
Date: 2026-05-14 10:29:26Z
*** kmeaw [2026-05-14 09:58]:
>доработан linux(4)
Лично мне это вообще не играет роли.
>пересборана базовая система с помощью lcc и clang из ОС Эльбрус
То есть, всё равно без закрытых несвободных компиляторов нельзя будет
собрать? Или речь про то, что начальную bootstrap сборку делаем на ОС
Эльбрус, получаем на выходе какую-то FreeBSD которую можно будет
загрузить и уже в ней снова полностью саму себя собрать её штатным
LLVM/Clang? Меня бы это устроило.
>то что нужно будет открыть, чтобы платформа стала пригодной для использования?
Я не писал ОС, так что не знаю какие именно наборы инструкций нужны.
Вроде бы написать ОС, с тем что они открыли, не выйдет. Насколько
понимаю, вот например LoongArch открыл достаточно, чтобы можно было и в
компиляторы его добавить (LLVM, Go) и ОС портировать. Вот так должно
быть, как мне кажется.
Вот беру я ISO FreeBSD. В ней, само собой, куча бинарей которые я
запускаю с диска. Потом всю ОС пересобираю. Вот беру я её компилятор: он
будет из исходников пересобран с нуля? Да. Будет ли ядро пересобрано?
vi, ed? Загрузчик UEFI? Всё будет. Это меня удовлетворяет. Вроде бы и
байт в байт идентичный .iso образ можно будет собрать в принципе.
Строго говоря, никто не гарантирует что тот бинарник компилятора с .iso
не встроит что-то плохое во время компиляции cc из исходника, но пока я
с этим готов мириться, ибо ещё не был прецедентов мне известных. Если
lcc будет использовать для начальной сборки, как bootstrap -- ok, тоже
могу смириться.
Хотя вспомнил про другой большой stopper: в Go нет поддержки e2k. Если
бы это был какой-нибудь гипотетический Java, Rust -- плевать на них, всё
равно не использую. А куда ж я без Go?
- комментарий 2:
From: kmeaw
Date: 2026-05-15 11:02:39Z
> > доработан linux(4)
> Лично мне это вообще не играет роли.
Без этого не получится запустить lcc и clang, который (пока что) использует
lcc.
> То есть, всё равно без закрытых несвободных компиляторов нельзя будет
> собрать?
Да, компилятор (по крайней мере его backend) останется несвободным.
При этом доступна документация, которой достаточно для написания альтернативной
реализации. Возможно силами сообщества доделают полноценный порт LLVM.
> в Go нет поддержки e2k
Есть форк, в котором такая поддержка есть. Но придётся подменить
golang.org/x/sys, чтобы поддержать новый ABI и возможно что-то ещё.
Поддержка Go находится на достаточном уровне, чтобы для Linux собирался и
работал dockerd, портирован gccgo. Если интересно проверить совместимость, то
могу попросить собрать и запустить какой-нибудь код.
- комментарий 3:
From: Sergey Matveev
Date: 2026-05-15 13:12:30Z
*** kmeaw [2026-05-15 11:03]:
>Без этого не получится запустить lcc и clang, который (пока что) использует
>lcc.
>Да, компилятор (по крайней мере его backend) останется несвободным.
Печально. То есть, всё равно продолжение использования несвободной
закрытой программы.
>При этом доступна документация, которой достаточно для написания альтернативной
>реализации. Возможно силами сообщества доделают полноценный порт LLVM.
"силами сообщества" -- вот это печалит. Не, это здорово если community
сможет это сделать. Где-то я видел статью что чуть-ли не за считанные
дни можно было написать ассемблер/компилятор Go для RISC-V, так что
может и не такая громоздкая задача. Но ведь этим же в идеале должна бы
заниматься сама МЦСТ! Ну или она считает что Go вообще не приоритетная
штука.
>> в Go нет поддержки e2k
>
>Есть форк, в котором такая поддержка есть. Но придётся подменить
>golang.org/x/sys, чтобы поддержать новый ABI и возможно что-то ещё.
Ого, приятно слышать что кто-то этим занимается.
>Поддержка Go находится на достаточном уровне, чтобы для Linux собирался и
>работал dockerd, портирован gccgo. Если интересно проверить совместимость, то
>могу попросить собрать и запустить какой-нибудь код.
Пока там нет свободного ПО/ОС, FreeBSD, то даже не любопытно: всё равно
не вариант использовать. А для работы: можно будет использовать только
то, что есть из коробки либо в родной ОС, либо в Астре.