Pull to refresh

Comments 95

Спасибо за статью :-)

ИМХО и Эльбрус и Мультиклет сражены одной болезнью:

1) Раз нет 22нм — давайте увеличивать парралелизм.
2) Проектируем в HDL кодах, симулируем — на 2000МГц производительность рвет всех конкурентов. Ура, Интелу конец, какие же они тупые!
3) В железе получаем производительность 10% от планируемой, т.к. широкие архитектуры тормозят тем сильнее, чем тоньше нормы без очень большой работы по конвееризации.
4) Софт делаем по остаточному принципу, на волне сдутия энтузиазма… В реальности-то качество софта важнее скорости железа, +-20% производительности процессора на непередовых техпроцессах уже не имеют никакого значения, а вот наличие/отсутствие поддержки архитектуры в основной сборке GCC/LLVM — это постоянный гемор для всех и на всегда…

Со всем согласен. Из перечисленных пунктов лично сталкивался с последним.
Когда делали вычислитель для военных, решили делать обязательно свое. Так на первом этапе процессор собрали, а показывать что он работает предлагали на симуляторе. Я сидел с разработчиком проца и пилили процессор, для того чтобы хоть что то показать, как раз впервые Embox пригодился:). На втором этапе уже убедили, что нужно взять открытый стандарт на архитектуру и сделать его реализацию. Там хоть все средства разработки есть.
А ещё нашей электронике очень сильно не хватает своих CPLD и FPGA. Если поглядеть на контроллеры конкурентов, то можно заметить что они сильно отличаются периферией что в неё интегрирована. Но отечественная промышленность такую номенклатуру просто не вытянет и логично было бы поставить простое MCU с внешней шиной которая подключена к ПЛИС и уже на ПЛИС можно сделать любую периферию, даже аналоговую, например дельта-сигма цап и ацп.
Есть знакомый на гос предприятии, делают силовые привода и управление к ним, но очень сильно маются отсутствием ПЛИС и тем что на отечественных микроконтроллерах чертовски убогая периферия которая сводит на нет ARM Cortex M3 ядро. Пробовали заказывать плис — ответа нет ни от одной конторы, а они якобы делают клоны альтеры начала 90ых годов.

Ну и нужны не просто копии ПЛИС, а чтоб работал родной Квартус для них. Без среды разработки будет нереально что либо сделать вообще.
Так проблема та же ) Софт для синтеза Verilog->RTL->Netlist->прошивка очень нетривиален, и по сложности в 100 раз превосходит разработку самой плисины.

Есть конечно возможности для срезания углов, но в любом случае, это задача.намного больше и сложнее еще одного процессора. И банкет оплачивать никто не спешит :-)
но проблема даже не в софте, были бы аналоги альтеры — можно было бы пользоваться готовым квартусом. Но наших плис что то вообще не видно. Есть сомнительные конторы которые молчат и не отвечают. Есть производители БМК которые после получения нетлиста и объёмов тоже не отвечают и на этом всё и заканчивается.
В итоге гос предприятия разрабатывают всё на рассыпной логике дедовскими методами 70ых годов. И на фоне «импортозамещения» «санкций» и прочих пугалок им запретили вообще вносить в комплектацию нормальные чипы. Даже такие на которые нет отечественных аналогов, например техасовские 320 контроллеры заточеные под двигатели (гибкие шим и быстрые АЦП). Да блин просто 12 битные АЦП в десятки мегасемплов нереально найти.
Из отечественных ПЛИС, на сколько я знаю, есть живьем только клон Cyclone II без PLL… И всё…
просьба дать контакты и наименования. Буду очень благодарен.
У вас явно какое-то очень неудачное общение было с производителями отечественных ПЛИС и БМК. Я вот лично знаю десятки людей, которые с ними успешно работают. Да и кое-кого из самих разработчиков ПЛИС и БМК тоже знаю. Это ни в коем случае не снимает упрека в никакущем качестве общения с потребителями с производителей, но вы все же сгущаете краски.
P.S. 12-битный АЦП на 40 мегасемплов от «Микрона» запущен в серию и называется 1299ПВ2У. 14-разрядники с эффективными 12 битами обещают в начале 2016 года.
общался не я, а официальные представители с завода, на котором я не работаю,
но от координат / наименований не откажусь — мне лично самому интересно поддержать отечественную промышленность, если она по ценам подходит к задаче, и ПЛИС с АЦП мы используем.
У «Микрона» на обновленном недавно сайте есть закрытый раздел, в который дается доступ представителям потенциальных заказчиков. Контакты на сайте есть, отвечают они вроде нормально, и в целом начали хоть как-то выстраивать работу с потребителями.
Производимые на «Микроне» ПЛИС воронежской разработки там вроде есть. И вам еще наверное отдельно могут быть интересны аналого-цифровые БМК дизайн-центра «Союз», они как раз удобно сопрягают функционал ПЛИС и аналоговой обвязки.
www.dcsoyuz.com/products/cristals
гибридные бмк в россии не только союз делает,
а так, всё желание связываться с бмк умирает ровно тот момент, когда озвучивается алгоритм разработки «прошивки». а затем контрольным выстрелом озвученная цена за мин партию. раз и навсегда.

по поводу взппшных 5576хс (они же «наши флексы 10к») — емнип, то младшая хс1 стоила порядка 75кр за штучку пару лет назад, старшая хс4 уходила далеко за 100кр. спасибо радхарду и, соответственно, только ромбику.
потом вышли «наши флексы10ке» в той же серии, еще более отрадхарденные…
с новыми взппшных 5578тс (они же «наши циклон2») не сталкивался. пока.
микроновские 5510ХС, вроде как, помёрли не появившись.
ниисовские даже номера не получили, не выбравшись из окра.
кто ещё у нас именно плисами занимался?
А никто и не говорил, что цены будут адекватными( Оно все радхард, с соответствующей серийностью и ценами. Это, причём, касается решительно любых российских микросхем, затраченных под ВПК (то есть почти всех). Так что тут экономика обычно очень больно наступает на горло патриотизму потребителей, работающих на рынке, а не с госзаказом.
«Микроновские новые ПЛИС» (они же новые воронежские, сделанные на «Микроне») в итоге появились. Цены лучше, видимо не стали.
Вот вот, про софт почему то все забывают!
Забыли сделать целое министерство по организации отрасли. Незачем пинять на сапожника, что он пальто не предлагает к своим сапогам.
Ну нет, это скорее «а к пуговицам претензии есть?»
Покупателю нужен не просто процессор, а процессор, которым можно воспользоваться для решения каких-то задач.
Вот вот, «к пуговицам претензии есть?»:)
А кто додумался заказывать разработку проца без программ? А кто должен был заказывать разработку и проца и программ к нему?
А никто не заказывал «Мультиклету» разработку ничего. Они сами решили, что хотят делать, а потом уже искать потенциальных покупателей. Вот по полной и огребают теперь плоды своего подхода.
Если они посылку пол года отправляют, то делают они проц не для этого.
Посылку отправили сразу же как у нас появилась отладочная плата. Первая отладочная плата потребовала коррекций для удобства пользователей. Я лично просил LDM-Systems внести правки, чтобы пользователям было удобно работать с платой. Те, кто занимаются у нас продажей выставляют счета заранее и указывают срок с расчетом, что плата придет и сразу заработает.
А как вы собираетесь на ПЛИС делать аналоговую периферию?
По сабжу:
1) +1 к BarsMonster, разработать кристалл ПЛИС — не проблема, проблема разработать софт для синтеза и прошивки.
2) Клоны альтеры действительно в России есть. Видимо, плохо заказывали.
А как вы собираетесь на ПЛИС делать аналоговую периферию?

ПЛИС рулит аналоговым обвесом. Пример ЦАП — плис цифровая, выдаёт шим, на выход RC цепочка, очень сильно утрирую но примерно так.

2) Клоны альтеры действительно в России есть. Видимо, плохо заказывали.
не спорю, они есть, находили, писали — не отвечают, просто игнорируют крупное градообразующее предприятие.
«Пример ЦАП — плис цифровая, выдаёт шим, на выход RC цепочка, очень сильно утрирую но примерно так»
Ох, надо же предупреждать, когда вы такое пишете, у меня чуть сердечный приступ не случился. Это даже не забивание гвоздей микроскопом, а я даже не знаю, как назвать.
Во-первых, представьте себе скорость и разрядность такого «ЦАП». Два эффективных бита? Три?
Во-вторых, не проще ли рулить нормальными микросхемами аналогового обвеса вместо того, чтобы изобретать очень плохие велосипеды? Современные ЦАП и АЦП вполне себе снабжены удобными внешними интерфейсами.
указанный способ только лишь грубый костыль в условиях когда вообще всё импортное запрещено, а что-то делать надо и лучше делать одну ПЛИС чем стопятьсот специализированных. «давайте будем быдлокодить хотябы без goto»
Я думаю, что проблема комплексная, а если решать проблему только разработав кристалл или только железо, то вряд ли что-то дельное получиться. Пользователю нужно решение которое он сможет использовать. Это можно решать если делать совместимое железо/софт с уже существующими аналогами. Например, Мультиклет выпускает совместимые с gcc средства разработки, причем на первом этапе можно и без оптимизации обойтись.
мне кажется более оптимальным сделать полную железную копию популярной АВР/СТМ32 и плис типа циклона, а софт использовать их. А исходники того-же GCC можно проверить на наличие закладок и желательно делать это не 5 лет.
Согласен. Написал в комменте. Тоже пытались сделать оригинальную архитектуру, но через год, приняли решение реализовывать стандартную ибо, не понятнуть все сразу, а без софта проц не нужен. Но если уж Мультиклет существует, то нужно брать совместимые решения. Допиливать gcc/llvm, а поддержка своего компилятора, хм, дело уж точно неблагодарное.
----Сейчас специалистов учат работать на каком-то конкретном процессоре?

Для этого бесплатно полсотни комплектов разработчиков с подготовленными методичками должны раздатся в каждый универ каждого областного вуза и на 80-90% профинансироваться государством, как этого сделали в Англии и разрешить компенсировать их оплату в вузы налоговыми льготами.
Тут дело даже не в раздаче методичек и комплектов для отладки, а в том что когда изучают микроконтроллеры изучают общую архитектуру, ну и практика, не так важно на чем. Точнее важно, если поставить IAR то выпускники будут просить его когда придут на предприятия. И тут мы опять возвращаемся к тому что средства разработки важнее самого процессора.
Нет знание процессора и данной архитектуры нужно, но скорее для системных программистов (компиляторщиков и так далее), а для прикладников требуют только иметь общее представление об архитектуре.
>>Intel вкладывает огромные деньги в ПО, причём эти вложения превышают их вложения в разработку и непосредственное производство процессоров
Пруф? А то мне всегда казалось, что все вложения Интел в ПО окупаются несколькими покупателями их компилятора, слишком дофига он стоит.
Какого рода доказательства Вам нужны?
Что вложения превышают ...?
Если честно это я на лекции какого то директора Intel слышал, что разработкой софта занимается гораздо больше людей чем разработкой и производством процессоров, ссылку дать не могу. Но то что Intel покупает mcafee за несколько миллиардов, а это именно разработчик ПО, что он вкладывается в всякие ОС, Meego и так далее, что его компилятор один из самых (если не самый) лучших для x86, мне кажется это достаточное доказательство.
Ну хотелось услышать откуда у этого слуха ноги растут. Проверку логикой то он не выдерживает. Вы хоть представляете себе сколько стоит фаба со всем оборудованием? А за нее ведь наликом надо платить а не акциями :)
А про компилятор я уже сказал. Посмотрите на его цену. Разработчики этого компилятора уже своих внуков по жизни обеспечили.
А какая у него цена? Я нашёл по 200 долл., это дорого?
похоже вы нашли стоимость апгрейда
цена руководствуясь сайтом intel от 700 до 3000. MPI есть только в версии за 3к
К сожалению цену фабрики не знаю! Возможно Вы нас просветите?

На самом деле это хорошо, что Вы так внимательно читали статью! Но если это единственный момент который Вас «зацепил», то мне не удалось донести свои мысли, по крайней мере до одного читателя:(
С остальным я был уже знаком по форуму ixbt, где кстати бывает разработчик мультиклета. С вашими мыслями я был согласен, не согласен был только с мыслью, которая оказалась не вашей :)

цену заводов можно подсмотреть в новостях, аналитике и отчетах Интел. К примеру «старые новости»: corp.cnews.ru/news/top/index.shtml?2010/10/28/414023
Фабы и процессоры — это разные виды бизнеса. Первые сами себя окупают, выполняя как заказы процессорного подразделения и других подразделений Интел, так и ОЕМ-заказы от других клиентов.
> что разработкой софта занимается гораздо больше людей чем разработкой и производством процессоров

Насколько я понимаю, в производстве процессора нужны не люди в большом количестве, а очень дорогие заводы.
Это ведь не «Старкрафт», что заплатил сотни минералов — и завод перенёсся в Калифорнию из соседнего измерения.

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

Людей или программистов?

Вы же помните, что тезис был про «разработкой и производством процессоров», а не про количество турков на производстве рабочей одежды молдован строящих заводы?
Ну значит, полупроводниковые технологии разрабатывают молдаване-строители.
Кто ж ещё, точно ведь не программисты.
А станки для литографии делают турки, в свободное от пошива прозодежды время.
Ясно ведь, что все, кто не программисты — низкооплачиваемая чернь.
> А станки для литографии делают турки

А станки для литографии не делает Intel
Вот вот, еще и низкоквалифицированная чернь то:)
Производители микросхем, как правило, не делают оборудование для литографии. Интел тут не исключение, свои производственные линии они покупают у ASML, впрочем, владея значительной долей акций этой компании. А «освоение нового техпроцесса» на заводах Интел — это наладочные и калибровочные работы совместно со специалистами ASML, а не разработка нового оборудования.
Не знаю про Intel, но могу сказать про ARM, что в разработку компиляторов, симуляторов и отладчиков, в т.ч. в бесплатные GCC и LLVM, вкладываются огромные деньги.
Эти затрыты не отбиваются покупателями коммерческих версий ПО; они покрываются из прибыли от собственно процессоров, справедливо полагая, что процессоры ARM (в т.ч. STM) никто бы не покупал, не будь ПО для них общедоступным.
Собственно именно эту идею я и пытался выразить!:) Спасибо!
Насчет Intel не знаю, а разработка софта для микроконтроллера или ПЛИС с оригинальной архитектурой совершенно точно на порядки более дорога и трудоемка, чем разработка собственно кристаллов.
UFO just landed and posted this here
#define max(a, b) (a > b) ? a : b
#define min(a, b) (a < b) ? a : b
Лучше что-нибудь в таком роде:
#define max(a, b) ((a) > (b) ? (a) : (b))
#define min(a, b) ((a) < (b) ? (a) : (b))

То в случае какого нибудь
if (min(a, b + c) * x > y) { ... }
может неловко получиться.
Спасибо за замечание!
В исходниках используется именно безопасный вариант, но в статье тоже не помешает исправить.
Ссылка на коммит
Да, тут перепутаны знаки «больше» и «меньше», но позже это было исправлено :)
Спасибо! Конечно вы правы! В статье поправили.
Мы эти пару мест решили вообще не вносить в мастер, как и многие другие, слишком странные изменения:) В указанном бранче они есть. В мастер были внесены, compiler.h и еще несколько нормальных изменений для всех платформ.
Скажите, а в вашем исходном варианте зачем дополнительные переменные вообще?
Чтобы избегать ситуаций, подобных следующей:
min(foo++, bar)
С дополнительными переменными foo будет инкрементирована один раз, а без них — дважды.

Ещё есть более экзотический пример (возможно, надуманный, но всё же возможный), когда может нарушиться согласованность. Если передавать в качестве аргумента разыменованный указатель, после сравнения аргументов может произойти переключение контекста, изменяющее содержимое соответствующего участка памяти. В таком случае макрос может вернуть значение, которого ему не передавали.
Проблема с этими Эльбрусами и Мультиклетами в том, что для них нет рынка, кроме чего-то полураспильного. Делаете процессор, так хотя бы на какой-то общепринятой системе команд (да хоть пиратьте, кому вы нужны). Это автоматически решает 99% проблем с софтом.
Если хотите оставить реальный след, то явно не процессором. Скажем, сейчас в тренде распознавание образов. Сделайте чип, который умеет ускорять какие-то операции из нейронных сетей. Покажите, что умеете в распознавание голоса точнее и энергоэффективнее существующих решений. Лицензируйте производителям SoC. Это в любом случае будет проще, чем решать проблемы согласованности кешей или написание компилятора для VLIW. Я не говорю, что что-то такое гарантированно принесет золотые горы, но, блин, всё лучше, чем сливать деньги на что-то совершенно бессмыленное.
А пиратить-то зачем? Лицензии на ядра продаются стоят приемлемых денег.
Более того, если вы собираетесь не пилить, ампотом кому-то что-то продать, то «кому вы нужны» скорее всего не прокатит.
У «Эльбруса» есть, кстати, свои задачи, которые он хорошо решает и под которые он, собственно, и заточён. Они, правда, совсем не рыночные, а военные.
А «Мультиклете» выглядит в основном как «делаем не то, что востребованно, а то, что нам самим интересно. Как это потом продавать — без понятия, но нам все равно».
Да, в мультиклете, это скорее фундаментальная наука и новая концепция, по крайней мере мне тоже так показалось.
Но может у них все таки что то получиться!:)
Эльбрус прекрасно решал бы свои задачи, будь он обычным АРМом с числодробильными расширениями. Бонусом они бы получили Линукс и тулчейн, который пилят всем миром. И не надо пытаться пилить компилятор на котором Интел однажды чуть не надорвался.
Когда начинали проектировать Эльбрус, ARM ещё не «выстрелил». Х86 был единственным вариантом популярной архитектуры.

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

Я как то на конференции OSDay спросил у сотрудника МЦСТ. Почему они не возьмут свой SPARC как ядро общего назначения, добавят свои ядра на E2K архитектуре, и получиться довольно интересный чип, эдакий аналог тексасовских OMAP ов. Получил ответ, что руководство считает по другому.
Я думаю его так пихают потому, что на числодробилку пока никто денег не даст, а вот на платформу общего назначения (хоть бы и для военных и прочих гос структур) дают. Может позже сделают, но маловероятно.
эльбрус перегружен огромным количеством других функций, например поддержкой x86 и их защищенным режимом. вытаскивать из этого голый VLIW это фактически разработка нового ядра.
Тут тоже вопрос спорный. На рынке числодробилок с хорошим параллелизмом тоже довольно тесно. Тут и специализированные процессоры, и мощнейшие GPU. Способен ли Эльбрус с ними на этом поле конкурировать?
сейчас в тренде ипортозамещение)
Первое, что хочется сказать — большое спасибо представителям Embox за статью!
Вы проделали действительно большой объем работы и получили результат.
Очень хотелось бы список всего, что необходимо в первую очередь от нас.

Когда я первый раз пришел в компанию Мультиклет существовала только версия в FPGA прообраза P1.
В это же время начинали писать компилятор. Мы и тогда понимали как вести разработку:
1) Сначала делаем и корректируем программную модель
2) Далее пишем компилятор, сталкиваемся с трудностями, понимаем как их преодолеть
3) Вносим коррективы в архитектуру и систему команд и возвращаемся к пунктам 1 и 2 пока не получим выйгрыша на большинстве тестов
Некорректно нас сравнивать с Эльбрусом, т.к. у нас нет финансовой поддержки со стороны государства.
Действительность такова, что нам приходится жить по средствам!

В архитектуре мы видим потенциал, понимаем где и как мы можем быть быстрее. Сейчас выпущено 2 реализации
мультиклеточной архитектуры (P1 и R1). Мы уже знаем как в несколько раз ускориться по архитектуре на нераспараллеливаемом коде, но перед выпуском R2 в идеале надо пройти этапы по пунктам 1,2,3 и получить компилятор, который нас устраивает.

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

Использовать готовый компилятор не так просто. Мы взяли компилятор lcc (могли взять и gnu) за основу за несколько месяцев собрали под нас Си89 в итоге получили избыточный код, который и выполняется дольше и занимает больше места, чем нужно. Сейчас ведутся работы по оптимизации этого компилятора
и рассматривается возможность его развития до уровня Си99.

По llvm процитирую ответы mikhanoid в комментариях к нашей публикации на Хабре:

1) LLVM заточен на регистровые машины, то есть на те, в которых обмен данными между инструкциями осуществляется через регистры.
Регистр, как абстракция, это такая именованная ячейка памяти. LLVM ожидает, что если в регистр с именем X записано некоторое значение, то потом оно и будет всегда читаться по этому имени X до следующей записи.
Объяснить LLVM, что такое «ссылка на результат одной из предыдущих инструкций», и то, что одно и то же имя, например, "@1" может означать разные значения, не понятно как. Мы не разобрались сами.
Но если кто-то нам подскажет, мы будем весьма рады и благодарны этому хорошему человеку.

2) Наша первая попытка была: взять стандартный интерфейс для описания целевой машины LLVM и реализовать его. На этом уровне не получилось.

Проблема не в количестве, а в том, что эти vreg-и являются именно регистрами, то есть, они хранят связанные с ними значения постоянно. LLVM считает, что vreg переживает ветвления. А у нас совсем не так.

То есть, ссылка на коммутатор, в общем случае, не переживает линейный блок. И нужно делать анализ, каково время жизни текущего vreg-а. Много проблем в этот анализ добавляет наличие phi-узлов с их хитрыми множественными входами.

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

По идее, нам бы хорошо иметь в самом начале оптимизации замкнутые по чтениям/записям линейные участки, а потом их уже объединять, анализируя ссылки на память или регистры, куда осуществляются доступы. А LLVM выдаёт совсем не такой код.
На мой взгляд вам стоит прежде всего подумать не об оптимизации, а о gcc совместимом фронтэнде. Конечно лучше взять готовый (llvm, gcc). как минимум на этом этапе. А потом можно и свой компилятор создать.
Кто вам такое сказал про LLVM?
В LLVM существует несколько уровней представления программы. На входе бэкенда мы имеем код на языке LLVM, который вообще не заточен под какую-либо архитектуру. Из него можно сделать что угодно.

Дальнейшие рассуждения тоже не соответствуют, как мне кажется.

> одно и то же имя, например, "@1" может означать разные значения, не понятно как.
Мне тоже непонятно, если честно.

> для получения хорошего кода нужен некий адский анализ
О да, это так.

И небольшой оффтопик: Отправлял заявку на участие в семинаре, ответа не получил. Приходить или нет?
Отвечу сам себе.
> одно и то же имя, например, "@1" может означать разные значения, не понятно как.
Понятно. Просто нужно пронумеровать команды уникальными номерами, а в конце, после всех оптимизаций DAG-а, расставить тэги. Не вижу проблем.
На семинар конечно приходите, 8 сентября в 11-00 (г.Екатеринбург, Челюскинцев д.2, офис 135) всё в силе.

У нас есть возможность уже сейчас сделать разметку вида:
habr:
arg1:=    getl 1
arg2:=    getl2
addl @arg1, @arg2
complete
Старые как мир грабли. Российская элементная база это практически всегда вещь в себе.
Мораль же пмсм такова: не нужно изобретать «отечественное» на «отечественном», нужно изобретать «мировое» и использовать доступное.
С другой стороны, в военное время опыт собирать оружие из чего угодно ценнее позолоченных «кирпичей» с неформованными ногами. А пока ВПК бьется за ромбики, какой-нибудь моджахед прикручивает к боеголовке стоковый китайский смартфон. Так что можно смело заказывать на алибабе батут и запускать г-на Рогозина в космос посредством оного.
На счет батута не знаю. Но в военное время рассчитывать на поставку с алибабы, это…
В общем то я скептически отношусь с идее повсеместного импортозамещения, но все таки военным важно не зависеть от поставок компонентов.
Кстати, вполне себе используют доступное, сейчас просто доступного становиться меньше. А строгие правила касались очень узкого класса задач, типа РВСН.
Вопрос приобретения проблемных комплектующих уже сейчас предлагается решаеть через посредников в Азии) Ссылку не подскажу, но точно читал такое в каком-то интервью одного из. Это только в новостях все герои — полное имортозамещение к 2018 году, а в реальности — вся надежда на «алибабу»…
Основным пунктом любого ТЗ вояки желают максимальное использование номенклатуры отечественых ЭРИ. При том, что эти ЭРИ производятся небольшими партиями в лучшем случае раз в квартал, поставки соответственно — вроде логично, кому такое эри и по таким ценам нужно, кроме обреченных…
Отсюда качество выпускаемых ЭРИ хромает ввиду не отлаженного тех.процесса, а координированием закупок отечественного и согласованием импортного ЭРИ на предприятиях-исполнителях вынуждены заниматся либо целые отделы, либо специальные группы сотрудников, численность которых иногда сопоставима с численностью группы разработчиков проекта. При этом в пресловутый ромбик вваливают бешеное количество денег.
Т.е. отечественная обороноспособность зависит не от потенциального врага, а от отечественного ВПК, что на практике еще хуже.
Пообщавшись с разными производителями отечественных процессоров я в целом разделяю точку зрения автора. Только ситуация намного хуже. Кто-то получает ящиками деньги минпромторга ведет себя как монополист. Кто-то делает проекты таким образом, что создается впечатление, что целью работы является закрытие гештальта «отечественный процессор». Вообще это серьезная родовая травма/комплекс неполноценности, связанный с отсутствием отечественных технологий в рынке ИКТ — интеллу ничего так и не показали, майкрософту тоже. Все что можем — раз в пару лет брать государевы деньги на очередной клон линукса под названием национальная ОС. Тоже самое с процессорами. У меня стойкое ощущение, что никто в действительности не заинтересован в распространении отечественных процессоров, а они используются в всяких пропагандистских целях (смотрите какие мы классные) или там, где все стоит нерыночных денег (а-ля война). Объяснить отсутствие в открытом доступе тулчейнов, средств разработки, эмуляторов, доступных отладок под отечественные архитектуры я не могу! За последние десять лет через мои руки прошли несколько десятков отладочных плат под самые разнообразные архитектуры, и всегда можно было по щелчку пальца получить спорт, какой-то софт, IDE и прочее. Просто вендоры заинтересованы в распространении своих устройств.

Вторая существенная проблема которую я вижу, это отсутствие понимания того, каким образом происходит распространение технологий в обществе. Разработчики железа (да и софта) не видят социального контекста технологий (и инноваций). Им кажется, что стоит сделать что-то классное (с их точки зрения), так все сразу побегут и купят это. Это ведь величайшее заблуждение. С обществом нужно работать, нужно открывать (это метафора) технологию профессиональному сообществу, нужно работать с ним, нужно создавать собственные сообщества. Посмотрите как это делает _успешны_ Open Source, и как это делает неправильно любой другой неуспешный открытый проект. Даже редкостное говно при правильной работе с сообществом может быть востребовано, приведено в порядок и распространено. У нас же все ведется в закрытую, никто ни чем не делится, все все скрывают ото всех. Я не предлагаю открывать исходники процессора, но почему людей лишают возможности интеграции новых технологий в существующие проекты? Если разработчики не в силах создать свой компилятор, не способны купить специалистов на рынке, то почему они не хотят пользоваться силой Open Source? Код, софт, давно уже не является основной ценностью проекта. Это издержки, которые необходимы, но они не гарантируют успеха. Они его даже не приближают. А вот что точно приближает успех — так это грамотная работа с сообществом. Посмотрите, все успешные компании раздают сорцы на лево и направо. А если не разрают сорцы, так раздают тулчейны, SDK, бесплатные курсы, кто-то даже железки.
Если разработчики не в силах создать свой компилятор, не способны купить специалистов на рынке, то почему они не хотят пользоваться силой Open Source?


Вы же сами пишите, что это очень дорого создать сообщество. Порой даже дороже чем разработать в закрытую. Посмотрите на открытые проекты крупных компаний. Уже работающую базовую технологию открывают хотя сами продолжают пилить ее, то есть затраты на разработку продолжают капать, но добавляется еще работу с сообществом!
другого пути нет, если вам не платит минпромторг.
иными словами, конкуренция она не только в технологиях. сейчас не 80ый год, когда можно выложить ядро в опенсорс и сразу появится сообщество. сообщество нужно создавать, с ним нужно работать, это один из инструментов распространения технологии. он способствует, но не гарантирует. зато его отсутствие — это шаг назад, в прошлое, и методы прошлого уже не работают.
У нас почти все кроме мультиклеточного ядра выложено в открытом доступе.
По ядру есть система команд открытая: multiclet.com/community/projects/examples/wiki/R1_ISA
По компилятору Си89: multiclet.com/community/projects/mcc-lcc
По собственным наработкам: multiclet.com/community/projects/mcc-lime
По примерам программ: multiclet.com/community/projects/examples/wiki
хороший ответ. он демонстрирует ваше понимание концепции «Open Source» в виде «выложим все и само все появится». как я написал выше, выкладывание в открытый доступ не создает сообщества, не способствует распространению и вообще не является синонимом «Open Source» в сегодняшнем его понимании. Собственно, не успех огромного количества проектов подтверждает мой тезис.
По компилятору особого желания что-то попробовать сделать (на сколько мне известно) никто не проявлял.
Понятно, что мы должны выделить конкретные блоки, которые необходимо закончить, написать статью на Хабре о том как у нас все устроено. Также нам необходимо подумать о поощрении разработчиков. Да, у нас нет опыта работы в концепции «Open Source». Поделитесь вашим видением того, что мы должны сделать, чтобы достичь успеха.
давайте по порядку. Чего мне не нравится в проекте мультиклет и чего как мне кажется не хватает чтобы сделать из него популярный проект.

1. Железо
* Из того что я вижу на сайте LDM-systems, на нем представлено две отладочные платы. Сами по себе отладочные платы не очень интересны. Мне как разработчику приятнее видеть модуля. Сегодня я разрабатываю на отладке, завтра заказывают свою материнскую плату, послезавтра заказываю у вас 100 модулей на пилот, через неделю делаю сам тысячу устройств на ваших процессорах. Gumstix/IGEP являются отличным примером — минимальный модуль и десятки разных материнских плат. Открытая схемотехника интерконнекта открывает возможность для разработчиков сторонних проектов. В теории инноваций эта концепция называется «Открыте инновации» — вы создаете вокруг себя облако заинтересованных в вашей продукции компаний и упрощаете процесс прототипирования/пилотирования.
* Цена. Если вы перейдете к модульному дизайну, возможно вам получится уменьшить стоимость минимального отладочного комплекта.

2. Софт.
* Во-первых эмулятор. Я признаюсь некоторе время назад перестал следить за проектом, но когда мне очень не хватало эмулятора из коробки. Не все хотят покупать железку для каких-то экспериментов. Года два назад был просто фурор в отрасли, многие мои знакомые интересовались, все хотели посмотреть. Но новость была, так никто не потрогал, остался очень негативный осадочек. Я бы сделал все, что бы тем кому интересно, могли как протестировать железо удаленно, так и скачать эмулятор и запустить набор ваших killer-app сразу. Ключевой момент сразу — качнул тарбол и запустил, а не потратил два дня на установку компилятора, отладчика, разруливания совместимостей.
* Во-вторых killer apps. Это связано с позиционированием проекта. Я прошел по вашей ссылке выше — там ничего нет. Написано «примеры программ» — а внутри по R1 вообще пусто, а по P1 внутри нет описание killer app. У каждого процессора есть примеры классических задач которые они решают. Посмотрите проекты TI под DSP, огромное количество алгоритмов ЦОС разложены и сделаны примером. Современная работа разработчика сводится к поиску готовых имплементации и компоновки (конечно с разработкой) конечного приложения. Никто с нуля не пишет имплементацию вейвлет, свертки или бфт для DSP — люди хотят брать готовое. И при изучении нового проекта самый первый вопрос — а что там есть уже готового, какую работы вы сделали уже за нас? У вас есть примеры кода по интерфейсам — претензий нет, но по алгоритмам? Многие задаются вопросом — чем же вы лучше, чем вы отличаетесь от VLIW или SIMD? в ответ вы даете какую-то теорию с картинками, а ARM дает тесты для NEON, TI показывает свертку на его DSP, даже мцст не к ночи будет сказано, пытается продавать свой эльбрус демонстрируя x86 совместимость и какую то математику.
* Я был бы рад сказать «а еще вам нужен супер дупер компилятор чтобы легко можно было переносить существующий код» но нет, я так не скажу. Я не считаю что компилятор в данном случае будет залогом успешности. Под PIC сишного компилятора не было, но PIC был супер популярен и востребован. Почему? В нем были готовые примеры, удобное IDE, доступные отладки и отладчики, отличный сапорт, литература и мероприятия. Компиялтор под PIC16 появился намного позже, и ничего, без него делали проекты. Ничто не мешает создавать вокруг вашего проекта с вашими компиляторами свои среды, где люди будут писать на имеющихся языках (и жрать кактус), но они должны получать что-то, что не может дать им ни один другой проект. Чувство причастности в данном случае это не то чувство, на котором стоит играть.

3. Позиционирование
* Мы с вами не знакомы, но мы в одно время заходили в Сколково, и как то в руки мне даже попала ваша заявка. Так вот, вы продавали свой проект как «Постнеймоновских архитектуру» с бесконечно большой производительностью и низким потреблением. Люди ломонулись смотреть что это, а получили никакой процессор с никакой переферией. Расчетные гигафлопсы рассыпаются об отсутствующий интерконнект, а от пафоса «постнеймоновской архитектуры» многих тошнит. Это особенность позиционирования отечественных продуктов. Уж если что-то сделали — так утерли нос интелу. Так не стоит делать. Open Source сообщество капризно и не любит пафос, ведь оно горизонтально и космополитично по определению. За громкими словами люди хотят видеть достойные продукты. Убийца айфона никогда не называет себя убийцей афона до того как он действительно убивает айфон. И это лично то, что мне не понравилось в продвижении вашего продукта.

4. Open Source
Если бы я сейчас занимался бы созданием open source сообщества вокруг вашего проекта, то я бы предпринял несколько шагов:
* Нашел бы способ существенно уменьшить способ отладочных плат, сделав их модульными, попытно выложив в откртый доступ схемотехнику. Цель — поставлять модуля множеству организаций, создающие другие отладки или прикладные киты на основе вашего процессора
* Объявил бы конкурс исследовательских работ по имплементации каких-то алгоритмов на вашу платформу. Провел бы конференцию разработчиков, обсудил бы с ними проблемы и результаты. Лучший код привел бы в порядок, сделал бы из него BSP, раздавал бы бесплатно вместе с железом. Killer app должен быть найден, иначе ваш процессор бесполезен и никакой Open Source его не спасет.
* Эмулятор/симулятор/удаленный доступ. Не все могут позволить себе железо
* Открытый образовательный проект по программированию вашего процессора. Общая теория, getting started in one day, ииплементация алгоритмов. Должны появляться специалисты знакомые с вашими IDE и процессором.
* Создание зонтика сторонних проектов на основе вашей платформы. Я бы не стал на вашем месте делать все сам, а остановился бы на модульной платформе. А значит, вам нужны последователи, которые создают конечные устройства (или другие платформы) на вашем процессоре. Сейчас мода на IoT, встраиваемые/киберфизические системы. Пускай это делают последователи, вам лишь нужно стимулировать их появление. На FOSDEM (https://fosdem.org/2016/) выставляют массу встраиваемых проектов, научитесь делать также. Главное, чтобы ваша открытая железка решала какую-то простуд задачу, лучшем чем какие-то другие. Open Hardware не обязует вас раскрывать архитектуру и выкладывать RTL процессора, но вы будете создавать открытые (сообществу) платформы.

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

* подумайте об организации чего-нибудь вроде пресейла или консалтинга, в больших вендорах есть такие люди. они не столько продают, сколько конслуьтируют по использованию своего процессора для решения каких-то задач. Они же занимаются поддержкой (концептуальной) BSP и всяких examples.
Отвечу только по opensource.
Схемотехника выложена, симулятор есть, killer app ом насколько я понимаю является криптофлешка.
Мне кажется вы описываете путь который хорош для Intel, но нужно учитывать специфику и размер компании Мультиклет.

P.S. Категорически не соглашусь с ненужностью компилятора. Когда PIC был популярным другого не было, сейчас компилятор это must have, никакого сообщества у вас без него не получится, слишком дорого будет.
Отвечу подробнее по всем пунктам:
1) Железо.
Отладочный комплект если смотреть на сами платы состоит из двух частей: базовая плата и процессорная с R1. Так вот процессорная плата уже сейчас является самодостаточной за исключением того, что к ней еще нужен программатор.
LDM-Systems к сентябрю обещали выпустить более дешевую версия программатора, а также появится возможность заказать минимальную комплектацию процессорной платы. Т.е. вы купили процессорную плату запитали, например от ПК через USB, используете программатор и получаете результат. В итоге все выйдет раз в 5 дешевле, чем полный комплект. В сентябре по этому вопросу у нас будет отдельная статья на Хабре.

2) Софт.
У нас есть функциональная модель и эмулятор UART. Скачиваем IDE Geany с нашего сайта, открываем руководство по быстрому запуску. Максимум за полчаса все настраиваем и запускаем. Документация сейчас активно редактируется. Примеры программ также в большом количестве сейчас на стадии оформления. На следующей неделе я надеюсь выложим больше материала на сайт.

3) Позиционирование.
В последнее время мы практически не занимаемся пиаром. Мне самому режет слух, когда говорят «инновационная» технология.
У нас просто процессор на новой архитектуре, разработанный в Екатеринбурге и ориентированный на максимальное быстродействие в распараллеливаемых вычислениях с распределением вычислительных ресурсов.

4) Open Source.

Постараемся приложить максимум усилий для развития данной тематики.
Можете подсказать, как на ваш взгляд следует развивать сообщество?
Мое ИМХО. В России есть очень хорошее сообщество вокруг дистрибутива Fedora. Среди участников есть инженеры из Red Hat, которые напрямую связаны с поддержкой различных процессорных архитектур на уровне ядра линукс и компилятора. На сайте можете найти их irc канал и пообщаться с ними.
Т.е. я хочу сказать, если вы сможете запилить поддержку своего проца в этот дистрибутив, это уже будет огромный толчок для развития сообщества. Люди сами к вам потянутся.
Мне кажется, что вы не до конца понимаете, что это не процессор общего назначения. И поставить на него Линукс, я уж не говорю о Федоре, задача совсем не тривиальная. Как минимум сначала нужен полноценный gcc.

А так идея хорошая, сделать что нибудь для какого нибудь существующего сообщества!
хм, PDP-11/x, VAX 11/x это набор плат на логических элементах (программируемой логике), а все вместе и есть процессор общего назначения, а по частям — контролер. Если хотите CPU & Linux Inc. комплектуйте. Требовать от контролера USB2 возможностей ARM, как мне кажется, наивно. К сожалению, архитектура мультиклета мне никогда не нравилась, они решают «проблему», котороя никак не проблема [ если есть линейный кусок, то раскидать его по ядрам не есть «постфон-неймановская» архитектрура, абстракт последовательного вычисления остается ].

По этому, gcc — не поможет, все равно нужен процессор общего назначения. Мультиклет — сопроцессор или контролер, в зависимости от обвязки. и его место в SoC вместе с армом или мипсом, на флешке.
Мультиклет — всё?
Сайт лежит.
Хаброэффект в действии, сайт подняли.
видимо я опять пропустил момент, когда он работал =)
/community/ работает, а основной-нет
Да, сайт по техническим причинам пролежит до понедельника. В дальнейшем мы сделаем все возможное, чтобы данная ситуация не повторилась. Пока доступен только наш форум multiclet.com/community/projects/community/boards
В общем, для целочисленных переменных можно записать просто:

#define max(a, b) ((a) > (b)? (a): (b))
#define min(a, b) ((a) < (b)? (a): (b))

Как так только для целочисленных? В теории этот код должен работать с любыми типами данных которые можно проверить на больше\меньше, а не только с целочисленными. Хотя может я что-то не понимаю и на Российском процессоре все не так.

Более того тут:

/** return the larger of @a a and @a b */
#define max(a, b) \
({ \
typeof(a) __max_a = (a); \
typeof(b) __max_b = (b); \
__max_a > __max_b? __max_a: __max_b; \
})

Чем обусловлено создание двух переменных __max_a \ __ max_b и предварительное помещение в них значений. Подобные подход я уже встречал ранее, но там были матричные операции и большое число обращений к значениям переменных, поэтому что бы вместо дальних обращений получить относительные использовали такого типа кэширование, но тут как то нерационально, ведь всего два обращения на получение значения и непонятно зачем эти значения помещать в память временных переменных перед сравнением.
Sign up to leave a comment.