В этом посте я хочу рассказать о наших усилиях по использованию российского процессора с оригинальной архитектурой Мультиклет. Нам интересен перенос нашей ОСРВ Embox на данную платформу, так как это даст возможность использовать довольно большое количество приложений, которые у нас имеются — например, SIP-телефон, о котором мы уже рассказывали.Речь пойдёт о проблемах, с которыми мы столкнулись в процессе переноса, и о том, как мы эти проблемы устраняли. Возможно, это будет интересно не только тем, кто планирует использовать данный процессор, но и тем, кому по каким-то причинам будет необходимо перейти со стандарта c99 и gcc на стандарт c89 и какой-нибудь несовместимый с gcc компилятор. Также в заключении я позволю себе добавить личные ощущения от взаимодействия с данной платформой.
О российской действительности
Комплект, который мы купили, является топовым, и стоит довольно приличных денег. Конечно, он не такой дорогой, как Эльбрус, но и с той же малиной не сравним. Впрочем, если об этом забыть, то присланный комплект выглядел довольно прилично. Цену, по моему мнению, стоит списать на ограниченность партии, ведь это почти что ручная работа.
Ещё одной особенностью, с которой мы столкнулись, стало время поставки. Комплект должен был прийти ещё в феврале, а пришел в июле. Впрочем, несколько пинков с нашей стороны, заверения и гарантийные письма со стороны мультиклета — и вот, к нам, наконец, пришла долгожданная посылка.
Приступаем к портированию
Когда мы убедились в существовании отечественного процессора, мы приступили к тому, для чего и покупали этот отладочный комплект, — к портированию нашей ОСРВ на данную платформу. Как я уже говорил, идея заключалась в том, что поддержка мультиклета нашим проектом автоматически позволила бы использовать на нём широкий класс приложений с многозадачностью, сетевым стеком, файловой системой, ну и блекджеком, конечно.
Как человек опытный и однажды лично сталкивающийся с оригинальными процессорными архитектурами, я сразу попытался установить контакт с теми, кто сможет ответить на наши технические вопросы. К сожалению, на первом этапе я не особо преуспел в этом вопросе. На вопросы о компиляторе мне дали ссылку на страницу, с которой его можно скачать, и описание работы с процессором, также присутствующее на сайте.
Не очень обнадёживающая ситуация, но, по крайней мере, компилятор был! Хоть и c89, он компилировал сишный код и предоставленные примеры. Оптимизм внушал ещё и тот факт, что мы уже встречали статью о портировании на данную архитектуру FreeRTOS. Поэтому мы решили двигаться, пока не упрёмся в трудную задачу, которую не сможем обойти с помощью костылей.
Технические подробности компилятора
Компилятор С для Мультклета основан на lcc, который, к сожалению, не совместим с мэйнстримовыми gcc/llvm/icc во всём, в том числе — по интерфейсу командой строки. Первая же попытка скомпилировать хотя бы один файл выявила массу неподдерживаемых флагов. Самым неприятным было отсутствие опции компилятора -include x.h. Эта опция включает файл x.h для препроцессинга, как если бы первой строкой компилируемого файла было #include <x.h>.
В принципе, это не стандартный приём, но таким способом очень удобно передавать, к примеру, сгенерённые конфигурационные файлы (а их у нас много), или, как в нашем случае, параметры компилятора, о которых пойдет речь немного дальше.
Следующим отличием было предоставление компилятора публике. Дело в том, что lcc — это только компилятор, а gcc — это скорее набор утилит для компиляторов (ld, as, cc, ..). Сам же gcc служит своеобразной оберткой для всех этих утилит или проще говоря является драйвером компилятора. То есть правильно вызывать ассемблер или линкер через gcc, который пробросит все параметры соответствующей утилите с правильно установленным окружением. В общем, пришлось вводить отдельные переменные для сборки LD и AS, а утилиту AR брать с хостовой машины. Если раньше к названию кросстула, например mips-elf просто можно было приписать -ld, -as и -ar, а вызывались они вообще через СС c соответствующими флагами, то в данном случае пришлось в явном виде вызывать утилиты.
Линкер, естественно, тоже преподнёс свои сюрпризы.
Первым из них было отсутствие флага -r (--relocatable) для создания промежуточных объектных файлов. Мы используем эти объекты при генерации своей метаинформации — например, подсчитываем контрольные суммы для проверки целостности для каждого модуля системы. Ну и вообще, это довольно полезная штука, если речь заходит об использовании динамических модулей и библиотек.
Дальше — больше. Работа со статическими библиотеками оставляет желать лучшего. Мало того, что библиотеки могут передаваться только с помощью опции -l, так они ещё и не могут содержать полный путь. Из-за этого принципиально не получится линковать разные библиотеки с одинаковыми именами. Кроме того, неприятно отсутствие поддержки --start-group/--end-group.
Могу также добавить довольно интересный и неприятный факт, относящийся уже к компилятору: в нем переопределена опция -l. В lcc это синоним --lccdir.
Опция ликера -r, или --relocatable
Полный путь к библиотекам
Опции --start-group/--end-group
Опцию -l для компилятора зарезервировать под линкер, хотя это и мелочь
Модификация исходников
Теперь перейдем к самим исходникам. Напомню, что они у нас являются c99 или даже gnuc, а компилятор — c89. Понятно, что должны были возникнуть проблемы. Первые проблемы возникли даже не с компилятором, а с препроцессором. В данном компиляторе используется препроцессор mcpp. В общем, сходу выяснилось, что макросы с переменным количеством аргументов в нём обрабатываются иначе, чем в gcc: “хвост” не может быть пустым, т.е. макрос с одним обязательным аргументом нельзя вызывать меньше чем с двумя аргументами. Пришлось менять, например, такой макрос, как assert. Раньше он у нас мог принимать не только выражение для проверки, но и строку сообщения об ошибке, что порой очень удобно. В принципе, это не стандартное поведение макроса, поэтому мы просто сделали еще один макрос assertf() и не компилировали исходники, где он встречался.
Вернёмся к компилятору. Ключевое слово inline появилось в c90, и компилятором мультиклета оно не поддерживается. Мы широко используем static inline функции как замену макросов. Выходом стало введение файла compiler.h, в котором через ifdef’ы определяется отсутствие поддержки inline, и в таком случае inline объявляется пустым макросом (#define inline /* nothing */).
Компилятор не поддерживает назначенный инициализатор (designated Initializers). Эту проблему невозможно решить с помощью препроцессора, а ухудшать исходный код для поддержки старого стандарта нам очень не хотелось. На помощь пришел инструмент c99-to-c89, который на лету превращает c99 код в c89.
Кроме того, компилятор не поддерживает ключевое слово typeof, которое является расширением gnuc. Мы его используем, например, для описания макросов min и max:
/** @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; })
/** @return the smaller of @a a and @a b */
#define min(a, b) ({ typeof(a) __min_a = (a); typeof(b) __min_b = (b); __min_a < __min_b ? __min_a : __min_b; })
В общем, для целочисленных переменных можно записать просто:
#define max(a, b) ((a) > (b) ? (a) : (b))
#define min(a, b) ((a) < (b) ? (a) : (b))
что мы и сделали в нескольких местах, просто выкинув включение заголовочного файла и определив его таким образом.
Самой большой проблемой оказались атрибуты. В компиляторе не поддержаны возможности установить выравнивание, упаковку структур, размещение данных или кода в определенных секциях. Обходиться без этих вещей крайне сложно. Например, у нас очень активно используется работа с секциями: даже загрузка системы основывается на принципе размещения указателей в определенных секциях. К сожалению, данную проблему мы не смогли решить, поэтому на текущем этапе решили ограничиться только выводом в последовательный порт строки о запуске системы.
Когда мы приступили к, собственно, поддержке архитектуры мультиклет, у нас сразу же возник ряд вопросов. На этот раз я решил схитрить и связался с сотрудниками мультиклета, которые что-то писали на Хабре. Огромное спасибо krufter. Он действительно быстро отвечал на мои вопросы и, благодаря ему, у нас появился stdarg.h для архитектуры мультиклет. Загрузочный код мы взяли из примеров, которые также были присланы им, но, в принципе, их можно было скачать и с сайта мультиклета. Возникали и некоторые недоразумения, о которых я не хочу распространяться. В итоге решили, что будет лучше, если вопросы будут задаваться на форуме мультиклета.
Заливка образа на плату
После компиляции мы распаковали наш комплект. Как я уже говорил, выглядел он вполне достойно.
Но когда мы собрались подключить jtag, выяснилось, что в документации на плату нет информации о том, как это сделать. Там были команды для прошивки, но там не было информации о том, как правильно воткнуть в разъем jtag. При этом, было два разъёма, к которым он прекрасно подходил. Опытным путём мы выяснили, что правильно это делать следующим образом:
На самом деле, мы задавали вопросы мультиклету, и они, вроде бы, уже обновили руководство, добавив фотографию разъема.
Запуск образа
Последним препятствием на пути к заветной строчке оказался баг в линкере, который они уже исправили с нашей подачи.
Суть в том, что готовые примеры работали, а образ Embox, по сути дела, с тем же кодом — нет. У меня сразу возникли подозрения о неправильном размещении в памяти объектов программы. Сначала мы грешили на стек, так как у нас образ был существенно жирнее, чем в примерах, и мы думали, что стек, указывающий на конец памяти в 256кБ, мог просто что-то затирать, такие прецеденты были. С помощью readelf выяснилось, что с размерами все в порядке, и мы стали грешить на стартовый адрес. То есть, мы хотели проверить, что программа правильно слинкована. Тут выяснилось, что в комплект разработки не входит дизассемблер. В итоге, после вывода линкером адресов меток предположение подтвердилось. Разница между Embox и примерами заключалась в том, что первым объектным файлов в примерах всегда был crt0.o.
Я попросил добавить поддержку директив .section в ассемблер и соответствующую поддержку в линкере, на что получил ответ на форуме “читайте документацию”. Прочитал, проверил и привел пример исходников, которые показывали, что это не работает. В общем, с помощью всё того же krufter -а проблема решилась.
И я, наконец, увидел долгожданную строчку:
К сожалению, дальнейшее продвижение без добавления пары фич в компилятор довольно сложно, и я решил пока подумать, что же с этим делать дальше: то ли самим пилить компилятор, то ли ждать неопределённое время, пока в мультиклете не доделают компилятор. Последнее кажется не сильно перспективным, поскольку они решили сделать с99-совместимый оптимизирующий компилятор. Причем не брать за основу gcc или llvm, а пилить свой, сославшись на то что, у них не регистровая организация машины.
Личные ощущения
Как и предупреждал, позволю себе высказать личные ощущения. В конце концов, разработчики мультиклета сами просили об этом в статье.
Я не буду останавливаться на аппаратной составляющей, об этом довольно прилично написал barsmonster в своей статье. Я лучше посмотрю на проблему
Итак, процессор физически существует. Это, конечно, радует, но непонятно когда же российская электронная промышленность поймет, что процессор не нужен сам по себе. Intel вкладывает огромные деньги в ПО, причём эти вложения превышают их вложения в разработку и непосредственное производство процессоров.
Все остальные производители тоже понимают, что таблички с производительностью не имеют никакого смысла, если нет возможности разрабатывать приложения и запускать уже написанный софт. На сегодняшний день статьи типа “Как я тестировал IDE компании «Мультиклет»” выглядят странно. То есть реально предполагается писать код на ассемблере? Нет, я, конечно, понимаю, что всё, что нужно современному программисту для встраиваемых систем — это IDE с возможностью залить свою программу прямо на плату. Я даже готов согласиться с выводом из этой статьи:
Таким образом, несмотря на простоту реализации, предлагаемого функционала вполне достаточно для полноценной отладки даже больших и сложных проектов. Обновленный функционал инструментального пакета позволяет значительно увеличить скорость разработки за счет предоставления интуитивно понятного и удобного интерфейса.
Но вот никак не пойму, как мне это поможет хотя бы повторить функционал Arduino, не говоря уже об STM?
Или расчёт на то, что “К Вам на предприятие придут специалисты уже обученные работать на отечественном процессоре”? Вот именно на отечественном! Нет, вы серьезно? Сейчас специалистов учат работать на каком-то конкретном процессоре?
В общем, мои личные впечатления двояки. С одной стороны, радуют люди, которые пытаются делать новое, а с другой — очень уж данный подход сквозит университетщиной. Сделали процессор, отчитались на тестах о проделанной работе, сказали: “Мы самые лучшие, причём всё делаем сами!”, — а продавать? Кому это нужно, кто захочет и сможет использовать этот продукт?
Закончить я хочу вопросом к сообществу.
Как вы считаете существует ли отечественный процессор Мультиклет, если для него пока не создано реальных приложений?
P.S. Эмоциональное заключение — это исключительно мои личные ощущения.
P.P.S. Код, описанный в статье, лежит в бранче нашего репозитория. Само собой, он может быть скачан и проверен на аналогичной плате.
Комментарии (95)
BalinTomsk
19.08.2015 16:57+5----Сейчас специалистов учат работать на каком-то конкретном процессоре?
Для этого бесплатно полсотни комплектов разработчиков с подготовленными методичками должны раздатся в каждый универ каждого областного вуза и на 80-90% профинансироваться государством, как этого сделали в Англии и разрешить компенсировать их оплату в вузы налоговыми льготами.
abondarev
20.08.2015 10:01Тут дело даже не в раздаче методичек и комплектов для отладки, а в том что когда изучают микроконтроллеры изучают общую архитектуру, ну и практика, не так важно на чем. Точнее важно, если поставить IAR то выпускники будут просить его когда придут на предприятия. И тут мы опять возвращаемся к тому что средства разработки важнее самого процессора.
Нет знание процессора и данной архитектуры нужно, но скорее для системных программистов (компиляторщиков и так далее), а для прикладников требуют только иметь общее представление об архитектуре.
Krey
19.08.2015 18:34-1>>Intel вкладывает огромные деньги в ПО, причём эти вложения превышают их вложения в разработку и непосредственное производство процессоров
Пруф? А то мне всегда казалось, что все вложения Интел в ПО окупаются несколькими покупателями их компилятора, слишком дофига он стоит.abondarev
19.08.2015 18:51+1Какого рода доказательства Вам нужны?
Что вложения превышают ...?
Если честно это я на лекции какого то директора Intel слышал, что разработкой софта занимается гораздо больше людей чем разработкой и производством процессоров, ссылку дать не могу. Но то что Intel покупает mcafee за несколько миллиардов, а это именно разработчик ПО, что он вкладывается в всякие ОС, Meego и так далее, что его компилятор один из самых (если не самый) лучших для x86, мне кажется это достаточное доказательство.Krey
19.08.2015 19:00Ну хотелось услышать откуда у этого слуха ноги растут. Проверку логикой то он не выдерживает. Вы хоть представляете себе сколько стоит фаба со всем оборудованием? А за нее ведь наликом надо платить а не акциями :)
А про компилятор я уже сказал. Посмотрите на его цену. Разработчики этого компилятора уже своих внуков по жизни обеспечили.abondarev
20.08.2015 09:48+1К сожалению цену фабрики не знаю! Возможно Вы нас просветите?
На самом деле это хорошо, что Вы так внимательно читали статью! Но если это единственный момент который Вас «зацепил», то мне не удалось донести свои мысли, по крайней мере до одного читателя:(Krey
20.08.2015 16:02С остальным я был уже знаком по форуму ixbt, где кстати бывает разработчик мультиклета. С вашими мыслями я был согласен, не согласен был только с мыслью, которая оказалась не вашей :)
цену заводов можно подсмотреть в новостях, аналитике и отчетах Интел. К примеру «старые новости»: corp.cnews.ru/news/top/index.shtml?2010/10/28/414023
DrPass
20.08.2015 14:45Фабы и процессоры — это разные виды бизнеса. Первые сами себя окупают, выполняя как заказы процессорного подразделения и других подразделений Интел, так и ОЕМ-заказы от других клиентов.
areht
19.08.2015 21:19+3> что разработкой софта занимается гораздо больше людей чем разработкой и производством процессоров
Насколько я понимаю, в производстве процессора нужны не люди в большом количестве, а очень дорогие заводы.
tyomitch
20.08.2015 12:14Это ведь не «Старкрафт», что заплатил сотни минералов — и завод перенёсся в Калифорнию из соседнего измерения.
Сколько, по-вашему, достаточно людей, чтобы разработать техпроцесс, спроектировать и изготовить оборудование, обеспечить всю логистику для постройки и эксплуатации завода, и, в конце концов, работать на этом заводе руками?areht
20.08.2015 14:17-1> Сколько, по-вашему, достаточно людей, чтобы разработать техпроцесс, спроектировать и изготовить оборудование, обеспечить всю логистику для постройки и эксплуатации завода
Людей или программистов?
Вы же помните, что тезис был про «разработкой и производством процессоров», а не про количество турков на производстве рабочей одежды молдован строящих заводы?tyomitch
20.08.2015 14:49Ну значит, полупроводниковые технологии разрабатывают молдаване-строители.
Кто ж ещё, точно ведь не программисты.
А станки для литографии делают турки, в свободное от пошива прозодежды время.
Ясно ведь, что все, кто не программисты — низкооплачиваемая чернь.DrPass
20.08.2015 15:54+1Производители микросхем, как правило, не делают оборудование для литографии. Интел тут не исключение, свои производственные линии они покупают у ASML, впрочем, владея значительной долей акций этой компании. А «освоение нового техпроцесса» на заводах Интел — это наладочные и калибровочные работы совместно со специалистами ASML, а не разработка нового оборудования.
tyomitch
20.08.2015 11:33+6Не знаю про Intel, но могу сказать про ARM, что в разработку компиляторов, симуляторов и отладчиков, в т.ч. в бесплатные GCC и LLVM, вкладываются огромные деньги.
Эти затрыты не отбиваются покупателями коммерческих версий ПО; они покрываются из прибыли от собственно процессоров, справедливо полагая, что процессоры ARM (в т.ч. STM) никто бы не покупал, не будь ПО для них общедоступным.
amartology
19.08.2015 19:33+1Насчет Intel не знаю, а разработка софта для микроконтроллера или ПЛИС с оригинальной архитектурой совершенно точно на порядки более дорога и трудоемка, чем разработка собственно кристаллов.
grossws
19.08.2015 19:30+5
Лучше что-нибудь в таком роде:#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) { ... }0xdde
19.08.2015 21:08+4Спасибо за замечание!
В исходниках используется именно безопасный вариант, но в статье тоже не помешает исправить.
Ссылка на коммит
Да, тут перепутаны знаки «больше» и «меньше», но позже это было исправлено :)
abondarev
20.08.2015 09:53Спасибо! Конечно вы правы! В статье поправили.
Мы эти пару мест решили вообще не вносить в мастер, как и многие другие, слишком странные изменения:) В указанном бранче они есть. В мастер были внесены, compiler.h и еще несколько нормальных изменений для всех платформ.galaxy
20.08.2015 15:38Скажите, а в вашем исходном варианте зачем дополнительные переменные вообще?
0xdde
20.08.2015 16:19+1Чтобы избегать ситуаций, подобных следующей:
min(foo++, bar)
С дополнительными переменнымиfooбудет инкрементирована один раз, а без них — дважды.
Ещё есть более экзотический пример (возможно, надуманный, но всё же возможный), когда может нарушиться согласованность. Если передавать в качестве аргумента разыменованный указатель, после сравнения аргументов может произойти переключение контекста, изменяющее содержимое соответствующего участка памяти. В таком случае макрос может вернуть значение, которого ему не передавали.
Salabar
20.08.2015 00:52+2Проблема с этими Эльбрусами и Мультиклетами в том, что для них нет рынка, кроме чего-то полураспильного. Делаете процессор, так хотя бы на какой-то общепринятой системе команд (да хоть пиратьте, кому вы нужны). Это автоматически решает 99% проблем с софтом.
Если хотите оставить реальный след, то явно не процессором. Скажем, сейчас в тренде распознавание образов. Сделайте чип, который умеет ускорять какие-то операции из нейронных сетей. Покажите, что умеете в распознавание голоса точнее и энергоэффективнее существующих решений. Лицензируйте производителям SoC. Это в любом случае будет проще, чем решать проблемы согласованности кешей или написание компилятора для VLIW. Я не говорю, что что-то такое гарантированно принесет золотые горы, но, блин, всё лучше, чем сливать деньги на что-то совершенно бессмыленное.amartology
20.08.2015 10:20+3А пиратить-то зачем? Лицензии на ядра продаются стоят приемлемых денег.
Более того, если вы собираетесь не пилить, ампотом кому-то что-то продать, то «кому вы нужны» скорее всего не прокатит.
У «Эльбруса» есть, кстати, свои задачи, которые он хорошо решает и под которые он, собственно, и заточён. Они, правда, совсем не рыночные, а военные.
А «Мультиклете» выглядит в основном как «делаем не то, что востребованно, а то, что нам самим интересно. Как это потом продавать — без понятия, но нам все равно».abondarev
20.08.2015 10:24Да, в мультиклете, это скорее фундаментальная наука и новая концепция, по крайней мере мне тоже так показалось.
Но может у них все таки что то получиться!:)
Salabar
20.08.2015 21:24Эльбрус прекрасно решал бы свои задачи, будь он обычным АРМом с числодробильными расширениями. Бонусом они бы получили Линукс и тулчейн, который пилят всем миром. И не надо пытаться пилить компилятор на котором Интел однажды чуть не надорвался.
beeruser
21.08.2015 01:00Когда начинали проектировать Эльбрус, ARM ещё не «выстрелил». Х86 был единственным вариантом популярной архитектуры.
abondarev
20.08.2015 10:21+3Не соглашусь, Эльбрус может быть прекрасной числодробилкой, а проблема в том что его пытаются пихать как процессор общего назначения.
Я как то на конференции OSDay спросил у сотрудника МЦСТ. Почему они не возьмут свой SPARC как ядро общего назначения, добавят свои ядра на E2K архитектуре, и получиться довольно интересный чип, эдакий аналог тексасовских OMAP ов. Получил ответ, что руководство считает по другому.
splav_asv
20.08.2015 10:41Я думаю его так пихают потому, что на числодробилку пока никто денег не даст, а вот на платформу общего назначения (хоть бы и для военных и прочих гос структур) дают. Может позже сделают, но маловероятно.
sartakov
20.08.2015 11:57эльбрус перегружен огромным количеством других функций, например поддержкой x86 и их защищенным режимом. вытаскивать из этого голый VLIW это фактически разработка нового ядра.
DrPass
21.08.2015 07:40Тут тоже вопрос спорный. На рынке числодробилок с хорошим параллелизмом тоже довольно тесно. Тут и специализированные процессоры, и мощнейшие GPU. Способен ли Эльбрус с ними на этом поле конкурировать?
krufter
20.08.2015 11:20+5Первое, что хочется сказать — большое спасибо представителям 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 выдаёт совсем не такой код.abondarev
20.08.2015 14:00На мой взгляд вам стоит прежде всего подумать не об оптимизации, а о gcc совместимом фронтэнде. Конечно лучше взять готовый (llvm, gcc). как минимум на этом этапе. А потом можно и свой компилятор создать.
32bit_me
22.08.2015 03:28+1Кто вам такое сказал про LLVM?
В LLVM существует несколько уровней представления программы. На входе бэкенда мы имеем код на языке LLVM, который вообще не заточен под какую-либо архитектуру. Из него можно сделать что угодно.
Дальнейшие рассуждения тоже не соответствуют, как мне кажется.
> одно и то же имя, например, "@1" может означать разные значения, не понятно как.
Мне тоже непонятно, если честно.
> для получения хорошего кода нужен некий адский анализ
О да, это так.
И небольшой оффтопик: Отправлял заявку на участие в семинаре, ответа не получил. Приходить или нет?32bit_me
22.08.2015 04:53+2Отвечу сам себе.
> одно и то же имя, например, "@1" может означать разные значения, не понятно как.
Понятно. Просто нужно пронумеровать команды уникальными номерами, а в конце, после всех оптимизаций DAG-а, расставить тэги. Не вижу проблем.
krufter
22.08.2015 07:53На семинар конечно приходите, 8 сентября в 11-00 (г.Екатеринбург, Челюскинцев д.2, офис 135) всё в силе.
У нас есть возможность уже сейчас сделать разметку вида:
habr: arg1:= getl 1 arg2:= getl2 addl @arg1, @arg2 complete
spot62
20.08.2015 11:38+1Старые как мир грабли. Российская элементная база это практически всегда вещь в себе.
Мораль же пмсм такова: не нужно изобретать «отечественное» на «отечественном», нужно изобретать «мировое» и использовать доступное.
С другой стороны, в военное время опыт собирать оружие из чего угодно ценнее позолоченных «кирпичей» с неформованными ногами. А пока ВПК бьется за ромбики, какой-нибудь моджахед прикручивает к боеголовке стоковый китайский смартфон. Так что можно смело заказывать на алибабе батут и запускать г-на Рогозина в космос посредством оного.abondarev
20.08.2015 12:35На счет батута не знаю. Но в военное время рассчитывать на поставку с алибабы, это…
В общем то я скептически отношусь с идее повсеместного импортозамещения, но все таки военным важно не зависеть от поставок компонентов.
Кстати, вполне себе используют доступное, сейчас просто доступного становиться меньше. А строгие правила касались очень узкого класса задач, типа РВСН.spot62
20.08.2015 16:30Вопрос приобретения проблемных комплектующих уже сейчас предлагается решаеть через посредников в Азии) Ссылку не подскажу, но точно читал такое в каком-то интервью одного из. Это только в новостях все герои — полное имортозамещение к 2018 году, а в реальности — вся надежда на «алибабу»…
Основным пунктом любого ТЗ вояки желают максимальное использование номенклатуры отечественых ЭРИ. При том, что эти ЭРИ производятся небольшими партиями в лучшем случае раз в квартал, поставки соответственно — вроде логично, кому такое эри и по таким ценам нужно, кроме обреченных…
Отсюда качество выпускаемых ЭРИ хромает ввиду не отлаженного тех.процесса, а координированием закупок отечественного и согласованием импортного ЭРИ на предприятиях-исполнителях вынуждены заниматся либо целые отделы, либо специальные группы сотрудников, численность которых иногда сопоставима с численностью группы разработчиков проекта. При этом в пресловутый ромбик вваливают бешеное количество денег.
Т.е. отечественная обороноспособность зависит не от потенциального врага, а от отечественного ВПК, что на практике еще хуже.
sartakov
20.08.2015 11:50+4Пообщавшись с разными производителями отечественных процессоров я в целом разделяю точку зрения автора. Только ситуация намного хуже. Кто-то получает ящиками деньги минпромторга ведет себя как монополист. Кто-то делает проекты таким образом, что создается впечатление, что целью работы является закрытие гештальта «отечественный процессор». Вообще это серьезная родовая травма/комплекс неполноценности, связанный с отсутствием отечественных технологий в рынке ИКТ — интеллу ничего так и не показали, майкрософту тоже. Все что можем — раз в пару лет брать государевы деньги на очередной клон линукса под названием национальная ОС. Тоже самое с процессорами. У меня стойкое ощущение, что никто в действительности не заинтересован в распространении отечественных процессоров, а они используются в всяких пропагандистских целях (смотрите какие мы классные) или там, где все стоит нерыночных денег (а-ля война). Объяснить отсутствие в открытом доступе тулчейнов, средств разработки, эмуляторов, доступных отладок под отечественные архитектуры я не могу! За последние десять лет через мои руки прошли несколько десятков отладочных плат под самые разнообразные архитектуры, и всегда можно было по щелчку пальца получить спорт, какой-то софт, IDE и прочее. Просто вендоры заинтересованы в распространении своих устройств.
Вторая существенная проблема которую я вижу, это отсутствие понимания того, каким образом происходит распространение технологий в обществе. Разработчики железа (да и софта) не видят социального контекста технологий (и инноваций). Им кажется, что стоит сделать что-то классное (с их точки зрения), так все сразу побегут и купят это. Это ведь величайшее заблуждение. С обществом нужно работать, нужно открывать (это метафора) технологию профессиональному сообществу, нужно работать с ним, нужно создавать собственные сообщества. Посмотрите как это делает _успешны_ Open Source, и как это делает неправильно любой другой неуспешный открытый проект. Даже редкостное говно при правильной работе с сообществом может быть востребовано, приведено в порядок и распространено. У нас же все ведется в закрытую, никто ни чем не делится, все все скрывают ото всех. Я не предлагаю открывать исходники процессора, но почему людей лишают возможности интеграции новых технологий в существующие проекты? Если разработчики не в силах создать свой компилятор, не способны купить специалистов на рынке, то почему они не хотят пользоваться силой Open Source? Код, софт, давно уже не является основной ценностью проекта. Это издержки, которые необходимы, но они не гарантируют успеха. Они его даже не приближают. А вот что точно приближает успех — так это грамотная работа с сообществом. Посмотрите, все успешные компании раздают сорцы на лево и направо. А если не разрают сорцы, так раздают тулчейны, SDK, бесплатные курсы, кто-то даже железки.abondarev
20.08.2015 12:28+1Если разработчики не в силах создать свой компилятор, не способны купить специалистов на рынке, то почему они не хотят пользоваться силой Open Source?
Вы же сами пишите, что это очень дорого создать сообщество. Порой даже дороже чем разработать в закрытую. Посмотрите на открытые проекты крупных компаний. Уже работающую базовую технологию открывают хотя сами продолжают пилить ее, то есть затраты на разработку продолжают капать, но добавляется еще работу с сообществом!sartakov
20.08.2015 12:32иными словами, конкуренция она не только в технологиях. сейчас не 80ый год, когда можно выложить ядро в опенсорс и сразу появится сообщество. сообщество нужно создавать, с ним нужно работать, это один из инструментов распространения технологии. он способствует, но не гарантирует. зато его отсутствие — это шаг назад, в прошлое, и методы прошлого уже не работают.
krufter
20.08.2015 13:02+2У нас почти все кроме мультиклеточного ядра выложено в открытом доступе.
По ядру есть система команд открытая: 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/wikisartakov
20.08.2015 14:09+1хороший ответ. он демонстрирует ваше понимание концепции «Open Source» в виде «выложим все и само все появится». как я написал выше, выкладывание в открытый доступ не создает сообщества, не способствует распространению и вообще не является синонимом «Open Source» в сегодняшнем его понимании. Собственно, не успех огромного количества проектов подтверждает мой тезис.
krufter
20.08.2015 14:18+2По компилятору особого желания что-то попробовать сделать (на сколько мне известно) никто не проявлял.
Понятно, что мы должны выделить конкретные блоки, которые необходимо закончить, написать статью на Хабре о том как у нас все устроено. Также нам необходимо подумать о поощрении разработчиков. Да, у нас нет опыта работы в концепции «Open Source». Поделитесь вашим видением того, что мы должны сделать, чтобы достичь успеха.sartakov
20.08.2015 15:21+1давайте по порядку. Чего мне не нравится в проекте мультиклет и чего как мне кажется не хватает чтобы сделать из него популярный проект.
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 процессора, но вы будете создавать открытые (сообществу) платформы.
Вот это то, что сходу мне приходит в голову.sartakov
20.08.2015 15:26* открытый образовательный проект не тоже самое что пойти в ургу и сделать там кафедру. Не поступайте так. открытый проект — доступ всем, вне зависимости от города или страны. университетское образование в данном случае только вредит проекту — это бессмысленная трата денег на людей которым это не нужно.
* подумайте об организации чего-нибудь вроде пресейла или консалтинга, в больших вендорах есть такие люди. они не столько продают, сколько конслуьтируют по использованию своего процессора для решения каких-то задач. Они же занимаются поддержкой (концептуальной) BSP и всяких examples.
abondarev
20.08.2015 15:52Отвечу только по opensource.
Схемотехника выложена, симулятор есть, killer app ом насколько я понимаю является криптофлешка.
Мне кажется вы описываете путь который хорош для Intel, но нужно учитывать специфику и размер компании Мультиклет.
P.S. Категорически не соглашусь с ненужностью компилятора. Когда PIC был популярным другого не было, сейчас компилятор это must have, никакого сообщества у вас без него не получится, слишком дорого будет.
krufter
21.08.2015 11:00+2Отвечу подробнее по всем пунктам:
1) Железо.
Отладочный комплект если смотреть на сами платы состоит из двух частей: базовая плата и процессорная с R1. Так вот процессорная плата уже сейчас является самодостаточной за исключением того, что к ней еще нужен программатор.
LDM-Systems к сентябрю обещали выпустить более дешевую версия программатора, а также появится возможность заказать минимальную комплектацию процессорной платы. Т.е. вы купили процессорную плату запитали, например от ПК через USB, используете программатор и получаете результат. В итоге все выйдет раз в 5 дешевле, чем полный комплект. В сентябре по этому вопросу у нас будет отдельная статья на Хабре.
2) Софт.
У нас есть функциональная модель и эмулятор UART. Скачиваем IDE Geany с нашего сайта, открываем руководство по быстрому запуску. Максимум за полчаса все настраиваем и запускаем. Документация сейчас активно редактируется. Примеры программ также в большом количестве сейчас на стадии оформления. На следующей неделе я надеюсь выложим больше материала на сайт.
3) Позиционирование.
В последнее время мы практически не занимаемся пиаром. Мне самому режет слух, когда говорят «инновационная» технология.
У нас просто процессор на новой архитектуре, разработанный в Екатеринбурге и ориентированный на максимальное быстродействие в распараллеливаемых вычислениях с распределением вычислительных ресурсов.
4) Open Source.
Постараемся приложить максимум усилий для развития данной тематики.
abondarev
20.08.2015 14:25+1Можете подсказать, как на ваш взгляд следует развивать сообщество?
1vertus1
20.08.2015 15:35Мое ИМХО. В России есть очень хорошее сообщество вокруг дистрибутива Fedora. Среди участников есть инженеры из Red Hat, которые напрямую связаны с поддержкой различных процессорных архитектур на уровне ядра линукс и компилятора. На сайте можете найти их irc канал и пообщаться с ними.
1vertus1
20.08.2015 15:42Т.е. я хочу сказать, если вы сможете запилить поддержку своего проца в этот дистрибутив, это уже будет огромный толчок для развития сообщества. Люди сами к вам потянутся.
abondarev
20.08.2015 16:02Мне кажется, что вы не до конца понимаете, что это не процессор общего назначения. И поставить на него Линукс, я уж не говорю о Федоре, задача совсем не тривиальная. Как минимум сначала нужен полноценный gcc.
А так идея хорошая, сделать что нибудь для какого нибудь существующего сообщества!
Duduka
21.08.2015 07:22хм, PDP-11/x, VAX 11/x это набор плат на логических элементах (программируемой логике), а все вместе и есть процессор общего назначения, а по частям — контролер. Если хотите CPU & Linux Inc. комплектуйте. Требовать от контролера USB2 возможностей ARM, как мне кажется, наивно. К сожалению, архитектура мультиклета мне никогда не нравилась, они решают «проблему», котороя никак не проблема [ если есть линейный кусок, то раскидать его по ядрам не есть «постфон-неймановская» архитектрура, абстракт последовательного вычисления остается ].
По этому, gcc — не поможет, все равно нужен процессор общего назначения. Мультиклет — сопроцессор или контролер, в зависимости от обвязки. и его место в SoC вместе с армом или мипсом, на флешке.
beeruser
21.08.2015 00:32Мультиклет — всё?
Сайт лежит.krufter
21.08.2015 08:55Хаброэффект в действии, сайт подняли.
beeruser
22.08.2015 02:22видимо я опять пропустил момент, когда он работал =)
/community/ работает, а основной-нетkrufter
22.08.2015 08:05Да, сайт по техническим причинам пролежит до понедельника. В дальнейшем мы сделаем все возможное, чтобы данная ситуация не повторилась. Пока доступен только наш форум multiclet.com/community/projects/community/boards
MrGobus
20.08.2015 15:44В общем, для целочисленных переменных можно записать просто:
#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 и предварительное помещение в них значений. Подобные подход я уже встречал ранее, но там были матричные операции и большое число обращений к значениям переменных, поэтому что бы вместо дальних обращений получить относительные использовали такого типа кэширование, но тут как то нерационально, ведь всего два обращения на получение значения и непонятно зачем эти значения помещать в память временных переменных перед сравнением.
BarsMonster
Спасибо за статью :-)
ИМХО и Эльбрус и Мультиклет сражены одной болезнью:
1) Раз нет 22нм — давайте увеличивать парралелизм.
2) Проектируем в HDL кодах, симулируем — на 2000МГц производительность рвет всех конкурентов. Ура, Интелу конец, какие же они тупые!
3) В железе получаем производительность 10% от планируемой, т.к. широкие архитектуры тормозят тем сильнее, чем тоньше нормы без очень большой работы по конвееризации.
4) Софт делаем по остаточному принципу, на волне сдутия энтузиазма… В реальности-то качество софта важнее скорости железа, +-20% производительности процессора на непередовых техпроцессах уже не имеют никакого значения, а вот наличие/отсутствие поддержки архитектуры в основной сборке GCC/LLVM — это постоянный гемор для всех и на всегда…
abondarev
Со всем согласен. Из перечисленных пунктов лично сталкивался с последним.
Когда делали вычислитель для военных, решили делать обязательно свое. Так на первом этапе процессор собрали, а показывать что он работает предлагали на симуляторе. Я сидел с разработчиком проца и пилили процессор, для того чтобы хоть что то показать, как раз впервые Embox пригодился:). На втором этапе уже убедили, что нужно взять открытый стандарт на архитектуру и сделать его реализацию. Там хоть все средства разработки есть.
Mirn
А ещё нашей электронике очень сильно не хватает своих CPLD и FPGA. Если поглядеть на контроллеры конкурентов, то можно заметить что они сильно отличаются периферией что в неё интегрирована. Но отечественная промышленность такую номенклатуру просто не вытянет и логично было бы поставить простое MCU с внешней шиной которая подключена к ПЛИС и уже на ПЛИС можно сделать любую периферию, даже аналоговую, например дельта-сигма цап и ацп.
Есть знакомый на гос предприятии, делают силовые привода и управление к ним, но очень сильно маются отсутствием ПЛИС и тем что на отечественных микроконтроллерах чертовски убогая периферия которая сводит на нет ARM Cortex M3 ядро. Пробовали заказывать плис — ответа нет ни от одной конторы, а они якобы делают клоны альтеры начала 90ых годов.
Ну и нужны не просто копии ПЛИС, а чтоб работал родной Квартус для них. Без среды разработки будет нереально что либо сделать вообще.
BarsMonster
Так проблема та же ) Софт для синтеза Verilog->RTL->Netlist->прошивка очень нетривиален, и по сложности в 100 раз превосходит разработку самой плисины.
Есть конечно возможности для срезания углов, но в любом случае, это задача.намного больше и сложнее еще одного процессора. И банкет оплачивать никто не спешит :-)
Mirn
но проблема даже не в софте, были бы аналоги альтеры — можно было бы пользоваться готовым квартусом. Но наших плис что то вообще не видно. Есть сомнительные конторы которые молчат и не отвечают. Есть производители БМК которые после получения нетлиста и объёмов тоже не отвечают и на этом всё и заканчивается.
В итоге гос предприятия разрабатывают всё на рассыпной логике дедовскими методами 70ых годов. И на фоне «импортозамещения» «санкций» и прочих пугалок им запретили вообще вносить в комплектацию нормальные чипы. Даже такие на которые нет отечественных аналогов, например техасовские 320 контроллеры заточеные под двигатели (гибкие шим и быстрые АЦП). Да блин просто 12 битные АЦП в десятки мегасемплов нереально найти.
splav_asv
Из отечественных ПЛИС, на сколько я знаю, есть живьем только клон Cyclone II без PLL… И всё…
Mirn
просьба дать контакты и наименования. Буду очень благодарен.
amartology
У вас явно какое-то очень неудачное общение было с производителями отечественных ПЛИС и БМК. Я вот лично знаю десятки людей, которые с ними успешно работают. Да и кое-кого из самих разработчиков ПЛИС и БМК тоже знаю. Это ни в коем случае не снимает упрека в никакущем качестве общения с потребителями с производителей, но вы все же сгущаете краски.
P.S. 12-битный АЦП на 40 мегасемплов от «Микрона» запущен в серию и называется 1299ПВ2У. 14-разрядники с эффективными 12 битами обещают в начале 2016 года.
Mirn
общался не я, а официальные представители с завода, на котором я не работаю,
но от координат / наименований не откажусь — мне лично самому интересно поддержать отечественную промышленность, если она по ценам подходит к задаче, и ПЛИС с АЦП мы используем.
amartology
У «Микрона» на обновленном недавно сайте есть закрытый раздел, в который дается доступ представителям потенциальных заказчиков. Контакты на сайте есть, отвечают они вроде нормально, и в целом начали хоть как-то выстраивать работу с потребителями.
Производимые на «Микроне» ПЛИС воронежской разработки там вроде есть. И вам еще наверное отдельно могут быть интересны аналого-цифровые БМК дизайн-центра «Союз», они как раз удобно сопрягают функционал ПЛИС и аналоговой обвязки.
www.dcsoyuz.com/products/cristals
en1gma
гибридные бмк в россии не только союз делает,
а так, всё желание связываться с бмк умирает ровно тот момент, когда озвучивается алгоритм разработки «прошивки». а затем контрольным выстрелом озвученная цена за мин партию. раз и навсегда.
по поводу взппшных 5576хс (они же «наши флексы 10к») — емнип, то младшая хс1 стоила порядка 75кр за штучку пару лет назад, старшая хс4 уходила далеко за 100кр. спасибо радхарду и, соответственно, только ромбику.
потом вышли «наши флексы10ке» в той же серии, еще более отрадхарденные…
с новыми взппшных 5578тс (они же «наши циклон2») не сталкивался. пока.
микроновские 5510ХС, вроде как, помёрли не появившись.
ниисовские даже номера не получили, не выбравшись из окра.
кто ещё у нас именно плисами занимался?
amartology
А никто и не говорил, что цены будут адекватными( Оно все радхард, с соответствующей серийностью и ценами. Это, причём, касается решительно любых российских микросхем, затраченных под ВПК (то есть почти всех). Так что тут экономика обычно очень больно наступает на горло патриотизму потребителей, работающих на рынке, а не с госзаказом.
«Микроновские новые ПЛИС» (они же новые воронежские, сделанные на «Микроне») в итоге появились. Цены лучше, видимо не стали.
abondarev
Вот вот, про софт почему то все забывают!
sergeyII
Забыли сделать целое министерство по организации отрасли. Незачем пинять на сапожника, что он пальто не предлагает к своим сапогам.
amartology
Ну нет, это скорее «а к пуговицам претензии есть?»
Покупателю нужен не просто процессор, а процессор, которым можно воспользоваться для решения каких-то задач.
abondarev
Вот вот, «к пуговицам претензии есть?»:)
sergeyII
А кто додумался заказывать разработку проца без программ? А кто должен был заказывать разработку и проца и программ к нему?
amartology
А никто не заказывал «Мультиклету» разработку ничего. Они сами решили, что хотят делать, а потом уже искать потенциальных покупателей. Вот по полной и огребают теперь плоды своего подхода.
sergeyII
Если они посылку пол года отправляют, то делают они проц не для этого.
krufter
Посылку отправили сразу же как у нас появилась отладочная плата. Первая отладочная плата потребовала коррекций для удобства пользователей. Я лично просил LDM-Systems внести правки, чтобы пользователям было удобно работать с платой. Те, кто занимаются у нас продажей выставляют счета заранее и указывают срок с расчетом, что плата придет и сразу заработает.
amartology
А как вы собираетесь на ПЛИС делать аналоговую периферию?
По сабжу:
1) +1 к BarsMonster, разработать кристалл ПЛИС — не проблема, проблема разработать софт для синтеза и прошивки.
2) Клоны альтеры действительно в России есть. Видимо, плохо заказывали.
Mirn
ПЛИС рулит аналоговым обвесом. Пример ЦАП — плис цифровая, выдаёт шим, на выход RC цепочка, очень сильно утрирую но примерно так.
не спорю, они есть, находили, писали — не отвечают, просто игнорируют крупное градообразующее предприятие.
amartology
«Пример ЦАП — плис цифровая, выдаёт шим, на выход RC цепочка, очень сильно утрирую но примерно так»
Ох, надо же предупреждать, когда вы такое пишете, у меня чуть сердечный приступ не случился. Это даже не забивание гвоздей микроскопом, а я даже не знаю, как назвать.
Во-первых, представьте себе скорость и разрядность такого «ЦАП». Два эффективных бита? Три?
Во-вторых, не проще ли рулить нормальными микросхемами аналогового обвеса вместо того, чтобы изобретать очень плохие велосипеды? Современные ЦАП и АЦП вполне себе снабжены удобными внешними интерфейсами.
Mirn
указанный способ только лишь грубый костыль в условиях когда вообще всё импортное запрещено, а что-то делать надо и лучше делать одну ПЛИС чем стопятьсот специализированных. «давайте будем быдлокодить хотябы без goto»
abondarev
Я думаю, что проблема комплексная, а если решать проблему только разработав кристалл или только железо, то вряд ли что-то дельное получиться. Пользователю нужно решение которое он сможет использовать. Это можно решать если делать совместимое железо/софт с уже существующими аналогами. Например, Мультиклет выпускает совместимые с gcc средства разработки, причем на первом этапе можно и без оптимизации обойтись.
Mirn
мне кажется более оптимальным сделать полную железную копию популярной АВР/СТМ32 и плис типа циклона, а софт использовать их. А исходники того-же GCC можно проверить на наличие закладок и желательно делать это не 5 лет.
abondarev
Согласен. Написал в комменте. Тоже пытались сделать оригинальную архитектуру, но через год, приняли решение реализовывать стандартную ибо, не понятнуть все сразу, а без софта проц не нужен. Но если уж Мультиклет существует, то нужно брать совместимые решения. Допиливать gcc/llvm, а поддержка своего компилятора, хм, дело уж точно неблагодарное.