Создание экосистемы свободного ПО для процессоров «Эльбрус»

В двухсвязном списке у тебя есть гарантия, что ссылки не образуют петлю. Иначе это не двухсвязный список, чувак.

last->next = first;
first->prev = last;

Даже односвязный список может быть вида

#1=(1 2 3 . #1#)

Молодец, навалил говна и рад. Зачем ты так сделал?

Затем, что Rust эту утечку памяти будет считать безопасной. Если же «просто так не делай», то можно и на Си++ писать. Программы быстрее работать будут.

Затем, что Rust эту утечку памяти будет считать безопасной.

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

Кстати, что небезопасного в утечках памяти-то?

1200 случаев в полностью прикладном движке браузера:

https://github.com/search?q=repo%3Aservo%2Fservo+unsafe+%7B&type=code

То есть частная компания не может наладить разработку и производства …

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

Я так и не смог для себя определиться тупик это или нет.

Встречаются и верующие в плоскую землю. Что я могу поделать

1200 случаев в полностью прикладном движке браузера

Там подавляющее большинство – вызов системных функций и внешних библиотек. Например, JS-движка (его нет в Servo), функций отрисовки гуйни и так далее.

Это всё требует unsafe{}, потому что внешние сишноплюсовые библиотеки, да.

Встречаются и верующие в плоскую землю. Что я могу поделать

Проводить их до края Земли и показать им, что на самом деле Земля цилиндрической формы... ;) А видимая ими плоскость — это всего лишь торец цилиндра. :)

Тем не менее эмуляция х86, где тоже нет порядка, исполняется на эльбрусах быстрее

Тем не менее эмуляция х86, где тоже нет порядка, исполняется на эльбрусах быстрее

Там как раз JIT компиляция. Как в OS Singularity.

Можно также транслировать RISC V. Но эффективней какой-то свой байткод.

E-16S в режиме эмуляции x86 оказался быстрее самого себя с нативным кодом! 2873 против 2553 попугаев.

Это как раз про сравнение двух компиляторов. Один из Си, второй из x86.

а на какой ширпотребный продукт ставить эльбрус?

Ну покупает же народ всякие одноплатные компы,пишет под них и их использует. Причем и «на работе» и дома тоже. Хотя по производительности они примерно как смартфон и от топовых интелов очень далеко. На Raspberry Pi в каком-то из вариантов по слухам в качестве проца был совсем не быстрый чип от dvd-плейера - однако популярности это никак не помешало. Вот и Эльбрус мог бы также продаваться. Если бы было где его производить.

Неттопы продаются. За 200-300 тысяч.

Там подавляющее большинство – вызов системных функций и внешних библиотек.

Ну не знаю. Прямо на первой странице:

https://github.com/servo/servo/blob/42f42b39cc91766cee2192fc9ba91d4ca6ac2101/components/webgpu/lib.rs#L159

https://github.com/servo/servo/blob/42f42b39cc91766cee2192fc9ba91d4ca6ac2101/components/layout/flow_ref.rs#L55

https://github.com/servo/servo/blob/42f42b39cc91766cee2192fc9ba91d4ca6ac2101/components/script/dom/crypto.rs#L54

https://github.com/servo/servo/blob/42f42b39cc91766cee2192fc9ba91d4ca6ac2101/components/script/dom/bindings/principals.rs#L61

https://github.com/servo/servo/blob/42f42b39cc91766cee2192fc9ba91d4ca6ac2101/components/script/dom/bindings/weakref.rs#L99

https://github.com/servo/servo/blob/42f42b39cc91766cee2192fc9ba91d4ca6ac2101/components/script/dom/bindings/proxyhandler.rs#L281

лол ты как раз натаскал то, о чём я написал: обвязку вокруг типов для работы с внешними библиотеками. Половина вот этих ссылок как раз об этом. Ну чувааааааак ну…

В этом коде вызова внешних библиотек нет.

impl CrossOriginProperties {
    /// Enumerate the property keys defined by `self`.
    fn keys(&self) -> impl Iterator<Item = *const c_char> + '_ {
        // Safety: All cross-origin property keys are strings, not symbols
        self.attributes
            .iter()
            .map(|spec| unsafe { spec.name.string_ })
            .chain(self.methods.iter().map(|spec| unsafe { spec.name.string_ }))
            .filter(|ptr| !ptr.is_null())
    }
}

impl Transmute<id::markers::Device> for id::Id<id::markers::Queue> {
    fn transmute(self) -> id::Id<id::markers::Device> {
        // SAFETY: This is safe because queue_id = device_id in wgpu
        unsafe { id::Id::from_raw(self.into_raw()) }
    }
}

    pub fn deref_mut(this: &mut FlowRef) -> &mut dyn Flow {
        let ptr: *const dyn Flow = Arc::as_ptr(&this.0);
        unsafe { &mut *(ptr as *mut dyn Flow) }
    }

Да и баг с ним, с этим ВАЗом! :) «Эльбрусы» мне интересны гораздо больше… :))

В целом я не думаю, что ситуация с эльбрусом будет лучше чем с vaz2109.

В первом банально нет небезопасных операций, это просто копирование указателя. Скорее всего просто пометили работу с сишными строками.

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

А нет, вру, в первом видимо был сишный юнион.

Всяко может быть, но «ванговать» сейчас — дело неблагодарное.

Ну и «Эльбрусы» для страны всё-таки куда важнее...

суперскалярность ещё не приделали, а значит производительности там не будет. А вы предлагаете врываться в это ядро с обоих ног. Чтобы что?

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

И уже после этого думать какое нужно ядро чтобы заместить долю рынка,достаточную для окупаемости его разработки и производства.

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

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

для дешевых микроконтроллеров.

Было бы неплохо если будет возможность применять в своих поделках свои дешевые и открытые микроконтроллеры вместо иностранных. Уверен что найдется немало энтузиастов, готовых с ними повозиться при их доступности. И даже помочь в вылавливании багов и совершенствовании архитектуры. Не говоря уж о том,что в процессе освоения напишут и отладят удобный для людей инструментарий разработчика. А не удобный для рекламы и продаж,как это нередко у закрытых проприетарных изделий бывает. Примеры уже были - вон сколько крутого софта народ под 580 проц когда-то написал. Да и рынок микроконтроллеров куда шире рынка десктопов. Обычные люди редко осознают сколько же микроконтроллеров работает у них в обычной квартире. И под все надо было софт написать - а это огромный рынок труда для программистов. Я бы сказал - поле непаханое. В отличие от десктопа,для которого за прошедшие три десятка лет всё необходимое уже более-менее написали и найти там свою нишу заметно сложнее.

но «ванговать» сейчас — дело неблагодарное.

А не надо ванговать, развитие технологии в рамках капитализма возможно только в случае, если на неё подсаживают силой весь мир. У эльбруса такого точно не будет.

для страны всё-таки куда важнее…

Ага, как 1,5 комплектов ратника.

А не надо ванговать, развитие технологии в рамках капитализма возможно только в случае, если на неё подсаживают силой весь мир

Настолько категоричное утверждение, что даже и обосновать его просить как-то неудобно... :)

Ага, как 1,5 комплектов ратника.

??..

Ну покупает же народ всякие одноплатные компы,пишет под них и их использует. Причем и «на работе» и дома тоже.

Допустим, одноплатник на Эльбрусе будет по техническим характеристикам не отставать от rpi. Но возникает самый главный вопрос: зачем, если под rpi больше софта, больше комьюнити, проще разрабатывать?

Было бы неплохо если будет возможность применять в своих поделках свои дешевые и открытые микроконтроллеры вместо иностранных

А пока что нет не только открытых, но даже и просто дешёвых...

Я бы сказал - поле непаханое

Непаханное, но чужое, и вид разрешённой деятельности для него сильно «не тот».

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

Любой unsafe «чтобы везде использовать только безопасные обёртки». Что здесь помешало реализовать трейт безопасно? FFI тут нет.

RISC-V, в отличие от E2K - это то, что уже поддерживается коммерческими компаниями и опенсорсом

Аргумент неоднозначный. Вон x86 еще больше поддерживается коммерческими компаниями и опенсорсом но это же не повод копировать архитектуру и систему команд,унаследованную от проца полувековой давности и за это время обвешаную огромным количеством костылей и подпорок. Понятно что сам интел отказаться не может - ему надо тянуть обратную совместимость. Наши процессоростроители находятся в начале пути и поэтому у них положение лучше - могут выбрать что-то более перспективное и продвинутое. Да,согласен, что перспективность и продвинутость VLIW - весьма спорная. Много лет с ним возились и в Интеле и у нас и в менее известных местах - но результаты довольно скромные. Хотя вот пишут что надежность кода и диагностика ошибок получается выше чем на x86 за именно за счет архитектурных фич. Это тоже преимущество,причем «перпендикулярное» числодробильной производительности. Потому что в одних применениях нужно считать как можно быстрее,а в других можно и помедленнее но чтобы без ошибок и падений.

ARM тоже когда-то был затычкой для телефонов. А теперь поди ж ты.

Причем архитектуру и систему команд первых армов сделали буквально несколько человек. Именно те идеи,которые так по сей день основой и являются. Это я к тому,что придумывание своей архитектуры и системы команд вместо копирования чего-то готового - это тоже может быть вполне приемлимым вариантом. Тут главное придумать удачно - вот как у того же ARM получилось.

А с другой стороны https://www.opennet.ru/opennews/art.shtml?num=52208 … https://www.reddit.com/r/rustjerk/comments/k9tow8/rust_developers_after_bullying_a_maintainer_into/

Но возникает самый главный вопрос: зачем, если под rpi больше софта, больше комьюнити, проще разрабатывать?

То есть, по прошествии этих нескольких лет, вы так и не поняли?

Что здесь помешало реализовать трейт безопасно? FFI тут нет.

Ты это на ЛОРе спрашиваешь? Сходи спроси у авторов. По отдельно выдернутым кускам кода нельзя судить о том, что же там помешало-то.

Было бы неплохо если будет возможность применять в своих поделках свои дешевые и открытые микроконтроллеры вместо иностранных.

Так есть же Байкал и Ядро.

Я констатирую, что даже в прикладном коде часто проще поставить unsafe, чем бороться с компилятором. Если проект не слишком популярный.

Это очень «толстые» и не очень «микро» контроллеры.

Вот «микро» от Ядро:

https://riscv-alliance.ru/risc-v-mikrokontroller-hackee-by-miet-and-yadro/

А на фоне Эльбруса и Байкал будет «микро».

А пока что нет не только открытых, но даже и просто дешёвых…

Так ведь и импортозамещением всерьез занялись совсем недавно. У нас же как всегда - пока жареный петух не клюнет… Сколько писали и говорили о том что нужно и можно переходить на линукс потому что зависимость от чужого софта это плохо. Но всем было лень поэтому толком ничего не делалось. А как клюнул петух - вон за пару лет сколько всего перевели. И сразу «неразрешимые» проблемы решаться начали типа главной - нежелания пользователей переучиваться.

Непаханное, но чужое, и вид разрешённой деятельности для него сильно «не тот».

Где же оно чужое если буквально в каждой квартире прямо сейчас уже работает несколько микроконтроллеров? Причем в бытовой технике,которая собирается у нас в стране,хотя и имеет «фирменные» шильдики. Можно подумать что для изготовления платы с микроконтроллером к какой-нибудь стиралке или микроволновке нужны запредельные космические технологии. А ведь учитывая количество только одних этих девайсов - это огромный рынок сбыта. Но у нас всё еще сильны традиции «догнать и перегнать» - вот и пытаемся тягаться с топовыми процами,которые нам пока не по зубам. А ведь из экономической теории и практики известно что мелкий и массовый товар даёт больше объемы прибыли чем дорогой и штучный.

Я констатирую, что даже в прикладном коде часто проще поставить unsafe, чем бороться с компилятором.

Часто? Нет.

Ещё раз: большая часть кода, который ты притащил, это разные обёртки над вызовами FFI или типами для FFI типа сишных строк. Меньшая часть – обход проверок, навроде валидации UTF-8, потому что эти проверки уже сделаны где-то в другом месте. Например, в тех же сишных библиотеках.

И я всё ещё не понимаю, зачем ты это сюда тащишь-то. Хочешь доказать, что в Rust иногда требуются вызовы unsafe{}? Никто с этим не спорит. Но ты сам и подтвердил, что требуются они достаточно редко, потому что 1200 вызовов на такой жирный проект как Servo (258429 строк кода на Rust) – это ничто. Это меньше 1% всего кода является unsafe{}.

Мне нравится, как ты сам опровергаешь то, что пытаешься тут доказать.

Я констатирую, что даже в прикладном коде часто проще поставить unsafe, чем бороться с компилятором.

Проще - не значит лучше. Особенно если изначально известно что от кода требуется надежность. А чтобы не бороться с компилятором надо изучить правильные приемы программирования и избавиться от «сишных» привычек слишком вольного написания кода и особенно - обращения с типами. Если мы «поборем» компилятор и всё-таки заставим два числа сложить - то потом может оказаться что сложили мы метры с килограммами. А что - и то и другое целые числа. Но в результате получится ерунда.

Так есть же Байкал и Ядро.

А что, отладочную плату для экспериментов с ними можно купить в магазине? А документацию для программирования скачать на сайте? Лично у меня такое ощущение что для энтузиастов электроники они доступны не особо лучше чем Эльбрусы.

Вот «микро» от Ядро:

https://riscv-alliance.ru/risc-v-mikrokontroller-hackee-by-miet-and-yadro/

И «на манеже всё те же»:
— «НИУ МИЭТ и YADRO представили»
— "Учебный прототип микроконтроллера на базе ядра SCR1 разработан"

А у меня на столе лежат китайские CH32V003*** (RISC-V2A) с отладочными платами. Да, они заметно более слабенькие, но они уже производятся в промышленных масштабах и стоят не слишком дорого.
Есть и другие, посерьёзнее. Только вот они китайские, а не наши. Но зато доступны.
«По три рубля, но мелкие. Но — сегодня!..» ©

А на фоне Эльбруса и Байкал будет «микро».

Да-да, «Здесь будет город-сад!»... :)

Хых... :(

Так ведь и импортозамещением всерьез занялись совсем недавно.

Да понимаю я всё!.. Но иногда зло берёт!.. :)

Где же оно чужое если буквально в каждой квартире прямо сейчас уже работает несколько микроконтроллеров?

Я другое имел в виду, ну да ладно. Просто в последний год всё думаю, «как дальше жить»: микроконтроллеров от Microchip стало сильно меньше по доступному ассортименту, и сильно дороже по цене. А я с ними ещё с 1990-х...

Вот и думаю, «куда пойти, куда податься». :) Пока что набрал образцов китайского микроконтроллеростроения «на попробовать», но ведь и это тоже не наше, и «отключить газ» могут в любой момент...

RISC-V микроконтроллер MIK32 АМУР (К1948ВК018)

Для физлиц

https://www.chipdip.ru/product0/9001456984

Для юрлиц

https://tellur-el.ru/catalog/integralnye_mikroskhemy_1/mikrokontrollery_i_protsessory_1/mikrokontrollery_1/323268/

Отладочная плата с программатором

https://tellur-el.ru/catalog/razrabotka_i_konstruirovanie_1/otladochnye_platy_1/323392/

Для самостоятельного изготовления

https://mikron.ru/products/mikrokontrollery/mk32-amur/#!/tab/672102497-4

Обзор комплекта разработчика

https://www.youtube.com/watch?v=11_MNi7C9Wc

Arduino-совместимая плата ELBEAR ACE-UNO

https://elron.tech/russian-arduino-compatible-board/

ELJTAG-программатор для RISC-V микроконтроллеров

https://elron.tech/eljtag-programmator-risc-v-mcu/

Готовые комплекты

https://arduino54.ru/category/rus-product/

Документация

https://elron.tech/materialy-dlja-elbear-ace-uno/

Модули ELSOMIK (System on module) с MIK32 АМУР

https://elron.tech/elsomik/

Удобны в монтаже, содержат оттестированные составы компонентов и схемотехнику, и позволяют оперативно запустить устройство на базе MIK32 АМУР.

зачем, если под rpi больше софта, больше комьюнити, проще разрабатывать?

Если на одноплатник с Эльбрусом получится поставить линукс то софта сразу станет много. А если сравнимать именно с rpi,с которой обычно как раз всякие энтузиасты и возятся,то этим энтузиастам будет интересно пощупать новое и необычное устройство. Именно потому что сами rpi уже вдоль и поперек ими изучены. Если же говорить о коммерческой разработке - то воникает вопрос почему например тех же роутеров существует и продается много моделей на разных процах,а не один какой-нибудь под который бы все и писали? Да и возвращаясь к одноплатникам - кроме rpi существует еще немало разных других, их покупают и под них тоже пишут. Или вот смартфоны - зачем их столько с разными внутренностями,хотя для покупателя они давно уже внешне выглядят все плюс-минус одинаково,а количество мегапикселей в камере давно превышает разумное для бытового применения?

Спасибо за информацию! Почитаю...

Жаль только, что цена микроконтроллера, да и «цена вхождения», явно не для «рядового пользователя»... :(

Ну да особого выбора у нас сейчас нет. :)

Стоимость модуля ELSOMIK BASE 3 200 - 3 800 руб. с НДС, в зависимости от объёма. Самое бюджетное решение на MIK32 АМУР.

Неттопы продаются. За 200-300 тысяч.

Дороговато конечно,но на работе вполне реально купить. Я вот застал времена когда обычный десктоп на 80286 стоил 43-47 тысяч советских рублей (89-90 годы). Для сравнения - это примерно как три отечественных легковых автомобиля в то же время. И ничего, компы покупались организациями и программисты получали к ним доступ,изучали,учились писать софт. Сам работать с «персоналками» как раз в это время и начинал. Это уже сильно позже народ «зажрался», компы стали домой покупать и стало не нужно прилагать усилия чтобы найти доступ к компу где-то на работе или по знакомству.

Товарищ, видимо, не учитывает, что «Эльбрус» и RPI разрабатываются и предназначены, скажем так, для решения немного разных задач... :)

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

Думаю, в том числе и потому, что процессоры и микроконтроллеры разного класса «у них», как когда-то транзисторы КТ315 «сотоварищи» у нас: их много, они разные, и покупаются «на вес» и «за копейку пучок».

свободно-распространяемого ПО для платформы «Эльбрус».

Так свободного или свободно-распространяемого?

Однозначно ненужно

Основная проблема в том, что unsafe используется действительно массово.

Это следствие «сишных» привычек вольного обращения с типами данных. Я когда изучал язык Ada в начале 90х - тоже поначалу спотыкался о его ограничения именно из-за сишных привычек. А потом научился использовать эти ограничения для благих целей,а не «бороться» с компилятором. И стало хорошо.

Хочешь доказать, что в Rust иногда требуются вызовы unsafe{}? Никто с этим не спорит.

Выше было утверждение, что на Safe Rust можно написать всё.

Это меньше 1% всего кода является unsafe{}.

С этим согласен. Но этот 1% тогда лучше запускать в том самом РБВ.