Исходники ядра Linux для e2k появились в открытом доступе

Тут два варианта. Я предположил, что x3al имел в виду не архитектуру команд Loongson, а конкретного производителя и конкретные модели. То есть, просто покупать у китайцев готовые Loongson. Если так, то это не свой проц.

Если хочется сделать «свой проц» — проще сделать объединённую компанию с кем-то ещё. Российский рынок практически не существует, без внешних рынков нет смысла делать что-то быстрее 8086. Разработка — дорого, в принципе неокупаемая никогда разработка — бессмысленна.

RISC-V и его форки - тупиковая ветвь, change my mind

Как минимум в области микроконтроллеров RISC-V уже успешно теснит ARM. Процессора для десктопного и сервеного применения пока нет, это да.

В 32 года узнал что такое худи)))

А я первый раз это слово увидел. И нет интереса смотреть что оно значит.

и ответ на Исходники ядра Linux для e2k появились в открытом доступе (комментарий) [user]i-rinat[/user]

«Рынок» и Инфраструктура == две стороны одного меха

полистав первые года Byte (c второй трети 70ых 20го по х.к.) - становится яснее что такое долина как и голивуд - и да r&d аутсорсить в энтузиастов готовых по почте отправлять киты для ручной сборки

см текущее -1 сообщение

поправочка

Dr Dobb того периода - Byte вс>ж более кастомер но не diy-ориентированный сразу быв

А в чем это выражается? STM как фигачили arm ядра в своих контроллерах, так и фигачит

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

Так они же вроде делали sparc совместимые процы, как база - вполне.

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

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

Там кстати в OpenE2K уже лежат ребейзенные патчи, для тех кому интересно посмотреть что же МЦСТ в своих приватных ветках наделали.

Ещё на базе прошлого слива binutils 2.29 и linux 3.14 мы с numas13 написали эмулятор.

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

Ещё PDF от Эльбруса 2С3 и 16С. Там по низкоуровневой части тоже много чего интересного написано.

как база - вполне

«Как база» предполагает, что дальше будет развитие как бы само по себе. А у нас нет таких ресурсов, которые есть у Intel, AMD или ARM.

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

А у нас нет таких ресурсов, которые есть у Intel, AMD или ARM.

Продолжу с тобой не соглашаться: как насчет того, что в москве сидел коллектив easic, который в полтора землекопа(по меркам крупных компаний) смогли сделать лучшие БМК(и под современные техпроцессы).

Коллективы, способные разработать вполне пристойное цпу ядро в россии были/есть. Вопрос с периферией и фабриками. До недавних событий это тоже упиралось в деньги: тот же модуль, например, получил деньги от минпромторга на девайсы под 7нм.

Другое дело, что почему-то не растет кокос под государственным надзором, но то и неудивительно.

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

А что б в софте оптимизации делать, у нас есть такие ресурсы ? Даже Intel с HP не осилили... Интерпретируемые языки как там себя на Эльбрусах чувствуют, а Java ?

смогли сделать лучшие БМК

Это типа библиотеки готовых блоков, только уже на кристалле? Мне кажется, опыт в подобном плохо экстраполируется на разработку логики процессоров. Разные задачи.

Коллективы, способные разработать вполне пристойное цпу ядро в россии были/есть.

Те же МЦСТ в своих презентациях постоянно показывают, что e2k+компилятор у них получается заметно лучше, чем SPARCv8/SPARCv9. Если специалисты по развитию «обычных» процессорных архитектур есть, они их найти не смогли.

А что б в софте оптимизации делать, у нас есть такие ресурсы?

Оказалось, есть.

Интерпретируемые языки как там себя на Эльбрусах чувствуют, а Java?

Так себе.

Это типа библиотеки готовых блоков, только уже на кристалле?

Периферия + логические конфигурируемые ячейки + блочная память. «Конфигурируется» эта штука переделкой парой металлов/виа. Очень интересное решение где-то посередине между фпга и асиками с точки зрения цена-ттм-павер.

Мне кажется, опыт в подобном плохо экстраполируется на разработку логики процессоров. Разные задачи.

Задачи, может, и разные, но этот коллектив рисовал кастомную библиотеку под тсмц16 и еще ниже. Это я к тому, что классные специалисты в РФ есть.

Если специалисты по развитию «обычных» процессорных архитектур есть, они их найти не смогли.

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

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

Бинго!

Но это же не повод не закапывать стюардессу?

Китайцы активно заменяют ядра в клонах stm, плюс своё интересное пилят. nxp в ту сторону смотрит, microchip что-то анонсировал.

А разгадка проста - роялти.

Оказалось, есть.

Это иллюзия и обман. Вот же есть железка, сейчас мы допилим компилятор и будет все прекрасно! Но нет. Ни какой компилятор без известных ему входящих данных не справится (разве что JIT) . Но железка то есть, осталось только написать компилятор... И такая мантра будет всегда...

или ARM.

Откуда у ARM ресурсы? они же с маленькой островной страны!(Население Великобритании 67,22 миллиона)

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

Бинго!

А зачем мне идти работать на государственный мцст, где платят гроши, когда я могу работать на вполне себе американский софтовый гигант ?

Те же яйца, только в профиль..

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

У меня нет уверенности, что оно нелегальное. Как нет и в обратном.

Распространение GPL исходников после хотя бы 1 факта распространения бинарников не может быть нелегальным. В принципе.

Это буквально базовое свойство лицензии - право на распространение бинарников и право на получение и распространение исходного кода.

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

Также вы можете уточнить у Михаила Шигорина, он тоже должен быть в курсе истории. Если он, конечно, захочет говорить об этом.

Лицензию даёт кто-то кому-то. Неясно, были ли у дающего полномочия/права поместить исходники под эту лицензию.

Лицензию даёт кто-то кому-то. Неясно, были ли у дающего полномочия/права поместить исходники под эту лицензию.

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

Так что тут как только МЦСТ взяли Linux, glibc и другие пакеты, они получили соответствующий набор прав и обязанностей. Потом происходит то, что описано уже неоднократно:

1. Есть факт передачи со стороны МЦСТ исходников Базальту (см. их ядра, binutils и пр). Он в принципе может быть под NDA и нераспространение со стороны Базальта, хотя если Базальту разрешают продажу, то NDA на передачу теряет силу. Тоже все по условиям GPL. Плюс NDA не ограничивает их право на передачу исходников третьим лицам (эта передача будет законной, но нарушающей NDA, последний абзац соответствующего пункта)
2. Если производитель распространяет бинарные файлы, например обновления, через HTTP, он обязан либо дать исходники, либо дать описание как получить исходники. Базальт сделали второе - на короткое время выложив файлик с инструкциями о том где их найти по тому же адресу где были бинарные файлы (память об этом осталась в интернете).

Собственно почитайте лицензию, ни о каких полномочиях и прочем речи не идет, когда на лицо производные работы (ядро с патчами, glibc с патчами, binutils с патчами и т.п.)

Это же в контексте РФ?

Представь, что тебе нужно сейчас разрабатывать проц.

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

В каком направлении пойдёшь?

Ни в каком, потому что пойдёт заказчик.

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

RISC-V не обязательно дно по производительности. Посмотрите на Alibaba’шный XuanTie C910, например. Там по скорости ядра (на МГц) выходит примерно Cortex A73, то есть чуточку лучше чем Эльбрус и Байкал М1. Частоты порядка 1.6 ГГц на 28нм TSMC заявлены производителем, на дев-борде, которую можно купить хоть сейчас - 1.2 ГГц и обещание обновленной платы Wujian 600 в ближайшем будущем (4 ядра, 2.5 ГГц, какое-то видеоядро).

RISC-V не обязательно дно по производительности.

Чтобы сделать быстрый RISC-V, нужно сделать суперскаляр, который агрессивно оценивает будущее развитие потока вычислений, а это сложно. Гораздо сложнее in-order VLIW, в котором не нужно думать о всяких переименованиях и перестановках.

Чтобы сделать быстрый RISC-V, нужно сделать суперскаляр, который агрессивно оценивает будущее развитие потока вычислений, а это сложно. Гораздо сложнее in-order VLIW, в котором не нужно думать о всяких переименованиях и перестановках.

А тут уже не совсем так.

Я не просто так привел в пример XuanTie C910 - он как раз суперскаляр и с внеочередным выполнением инструкций. Достаточно маленький и компактный, еще и OpenSource. Можно еще вспомнить исследовательские risc-v чипы, которые пилят студенты и аспиранты - например SonicBOOM.

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

Да и про сложность чипа, если говорить, все не так однозначно. Посмотрите на Эльбрус - 8 ядер и большая площадь кристалла, из которой больше половины это кэши. Уменьшить кэш не получится, просядет производительность очень заметно. Значит придется мирится с тем, что цена на чип никогда не будет конкурентоспособной, так как именно в производстве он сложный. А мы еще не вступали в область того как сделать большой и быстрый кэш, а то обычно с ростом размера страдают задержки. Да и, если вы посмотрите, VLIWы имеют тенденцию обрастать костылями, которые пытаются сократить неизбежные простои конвейера, когда процессору надо будет ждать что-нибудь из памяти - например все аппаратные блоки префетча данных, огромные регистровые файлы, огромные кэши… У Итаниума, как вершины (технологической) творения GP VLIW процессоров, вообще в поздних процессорах появилось переименование, retire buffer’ы и другие элементы OoO. В Э16С должно было появиться предсказание переходов, хотя от него тоже хотели уйти. И все это не из-за хорошей жизни.

создаете нерешаемую задачу

Она в будущем нерешаемая. Зато VLIW в краткосрочной перспективе позволяет получить скачок в производительности, что в общем-то и произошло.

Не говоря про то что компилятор под VLIW выходит мягко говоря не простым.

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

XuanTie C910 <…> OpenSource

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

Она в будущем нерешаемая. Зато VLIW в краткосрочной перспективе позволяет получить скачок в производительности, что в общем-то и произошло.

Тоже не совсем. В среднем Эльбрус показывает себя как типичный хороший in-order процессор с соответствующим количеством ядер и соответствующей частотй (читай как Intel Atom) или как очень плохой суперскаляр с внеочередным исполнением (читай Cortex A57). Я бы не назвал это скачком в производительности.

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

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

А какая разница, если задача на уровне компилятора вообще не решается? В принципе.

Можно бесконечно совершенствовать компилятор и все равно не достигнуть средней эффективности суперскаляра с OoO. При этом все это время платить за это повышенной ценой каждого чипа (в разы притом). Кстати еще очень серьезный вопрос про цену, так как не любое изменение должно быть протестировано в железе - есть же FPGA и на них можно сделать прототип и проверить свои идеи, а уже потом заказывать производство.

Зря я сказал про 2022-й.

Что сказано, то сказано. Но его выложили в открытый доступ в 2020-м, насколько я помню.

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

C910 выложен под Apache2, так что хоть куда ставь. В целом у risc-v тоже никаких проблем с лицензированием нет.

А какая разница, если задача на уровне компилятора вообще не решается? В принципе.

В теории можно взять байткод типа LLVM IR и его на лету jit’ить в зависимости от исполнения. Но я не большой специалист и верояно есть свои подводные камни.

есть же FPGA и на них можно сделать прототип и проверить свои идеи

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

Микроархитектуру вполне себе можно моделировать на перфоманс моделях и получать килоопсы. Мы коррелировали перф модель на плюсах с эмулятором и реальным железом - было вполне правдиво.

А можно и не LLVM IR, а сразу бинарный код: так работает эльбрус в режиме х86 или тот же денвер(in order vliw), когда исполняет армовый код. Но у бинарной трансляции есть очень много проблем, не взлетает она, увы. Проверяли.

Я бы не назвал это скачком в производительности.

По сравнению со SPARC’ами от той же конторы чипы с e2k в тестах выглядят заметно повеселее. И они в России пока что лидеры.

А задача не в будущем не решаемая, а в принципе.

Есть дорожка Transmeta.

средней эффективности суперскаляра с OoO

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

есть же FPGA и на них можно сделать прототип и проверить свои идеи

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

C910 выложен под Apache2, так что хоть куда ставь.

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

Бинарный код ты умрёшь PDOшить и развешивать какие-нибудь маркеры.

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

Бинарный код ты умрёшь PDOшить и развешивать какие-нибудь маркеры.

Да вполне себе, если есть внятная система профилирования и уровней оптимизации. Но я говорю об оптимизации именно горячих кусков кода, а не всего бинаря.

Есть дорожка Transmeta.

Трансмета мертва. Ее много раз пытались воскресить, но она все же мертва.

Он там явно заявил, что решения, которые подходят для непосредственно чипов, не всегда хорошо ложатся на FPGA и наоборот

Это правда, что rtl для фпга и для асиков отличается.

Так что нет, FPGA как часть процесса разработки процессоров это не выход.

Их буквально используют для разработки, и в стартапах, и в интеле.

https://studylib.net/doc/5380999/just-in-time-compilation-lessons-learned-from-transmeta

Во, нашел презентаху

Ты имеешь в виду транслируемый бинарь? Я про нативный, который компилятором уже раскидан по ШК и как его там дальше оптимизировать хрен знает.

Есть partial вариант бинарной трансляции: «нулевой» уровень у тебя бежит в нативном коде(ака неоптимизированный бинарь), код прогревается и профилируется, находятся горячие куски и ты их уже оптимизируешь с учетом профилировочной информации.

Это всё понятно, я про другое изначально говорил. Вот есть у тебя исходник программы написанной, к примеру на си(что не лучший пример, ну да ладно). Дальше три дороги: транслируемый x86 бинарь, собранный lcc статичный бинарь, jit-assisted бинарь из некоторого IR представления(LLVM как раз может и не подойти, он тут для примера).

В каком из случаев получится утрамбовать поток инструкций в ШК более плотно?

Плюс ЕМНИП трансмета доступа к «телу», а именно к vliw не давала, только x86 интерфейс, там выбора не было.

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

Трансмета мертва. Ее много раз пытались воскресить, но она все же мертва.

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

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

Их буквально используют для разработки, и в стартапах, и в интеле.

В интеле не только процессоры Core делают, так что ничего удивительного. К тому же ты упоминал, что весь проц в FPGA не засунешь. Так что я вообще не понимаю, к чему это было сказано.

В интеле не только процессоры Core делают, так что ничего удивительного. К тому же ты упоминал, что весь проц в FPGA не засунешь. Так что я вообще не понимаю, к чему это было сказано.

Вот, что вспомнил: https://www-inst.eecs.berkeley.edu//~cs150/sp10/Collections/Papers/nehalemFPGA.pdf

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

Я тут парирую нвидевским Carmel, который есть продолжение идей трансметы. У систем с бинарной трансляцией не так много плюсов, а вот минусы - жирнющие. Чего только стоит валидация самой бинарки. Отвалидировать железо куда проще, но, впрочем, нвидия справилась и с этим, сертифицировав кармель для автомотива.

В теории можно взять байткод типа LLVM IR и его на лету jit’ить в зависимости от исполнения. Но я не большой специалист и верояно есть свои подводные камни.

Можно много чего, вопрос в том чтобы что. Хотите jit’ить что-то на лету или даже AOTить - получите VLIW образца transmeta или nvidia. В принципе даже получится динамическое планирование, но только в условиях ограниченных ресурсов допустимые оптимизации будут не очень богатыми, еще и эффект прогрева будет виден. В принципе по опыту тех кто пошел таким путем - получается лучше чем инвестиция в компилятор, но хуже чем нативно сделать архитектуру.

По сравнению со SPARC’ами от той же конторы чипы с e2k в тестах выглядят заметно повеселее. И они в России пока что лидеры.

М… проблема со спарками в том, что МЦСТ могли взять https://en.wikipedia.org/wiki/OpenSPARC и получить сразу результат веселее и Эльбруса и МЦСТшного же SPARC’а.

Кстати, доступен он с 2005-ого года, так что смысл в Эльбрусе для меня загадка уже давно.

И то что в России они лидеры, не значит что они сделали что-то хорошее. В этом проблемка.

Есть дорожка Transmeta.

Есть, про нее в ответе другому человеку я сказал уже. Вкратце - оно все равно выходит не так эффективно. Пробовала и трансмета и nvidia - не взлетело. Кстати у nvidia лучше получилось, в принципе их ядра Carmel (Tegra Xavier) похож на Cortex-A75 и даже по размеру чип не ужасный, но только по энергоэффективности они этому самому A75 проиграли. Также и Denver был примерно похож на A57, но по эффективности хуже.

Только не нужно путать среднюю производительность

Не совсем понял переход, если честно. Можете пояснить?

Так что нет, FPGA как часть процесса разработки процессоров это не выход.

Посмотрите ссылку про C910 что я давал пару комментариев назад (или оригинальную презентацию на HotChips кажется 2020-ого года). Только внимательно по слайдам. Это на практике применяется и очень активно в разработке подобных ядер.

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

а ты попробуй докажи, что патент был нарушен.

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

транслируемый x86 бинарь, собранный lcc статичный бинарь, jit-assisted бинарь из некоторого IR представления(LLVM как раз может и не подойти, он тут для примера).

Очень зависит от условий. Очевидный плюс x86-бинаря в том что транслятор даст динамическое планирование и сгладит простои конвейера, а также будет работать над уже как-то оптимизированным кодом (предполагая что собран он не с -O0 :) ), хотя в теории у jit-assisted исполнения какого-то байткода должно быть больше информации и должны быть возможны более железо-специфичные оптимизации на лету, но время на выполнение очень сильно ограничено. lcc-бинарь - если компилятор угадал с путем выполнения кода то будет хорошо, если не угадал - хуже чем транслятор. Собственно на практике на Эльбрусе это заметно, когда некоторый софт под транслятором работает лучше чем нативно собранный.

Плюс ЕМНИП трансмета доступа к «телу», а именно к vliw не давала, только x86 интерфейс, там выбора не было.

Не было, но это пример именно такого JIT-исполнения в абсолюте.

Не совсем понял переход, если честно. Можете пояснить?

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

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

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