В ИСС испытывают новую БЦВМ

[SGS_67]

Not пишет:

SGS_67 пишет:

TAU пишет:

SGS_67 пишет:
развитием (бесплатных!) средств проектирования на основе С, да и вообще, GNU, для разнообразных платформ занимаются крупные международные сообщества, а не отдельные конторы

Ага. И уровень поддержки (сопровождения), к сожалению, продуктов этих "сообществ" зачастую оставляет желать лучшего.

Приведите пример такого непотребства.

OpenSSH Heart Bleed.

 
Какое отношение имеет Heartbleed к OpenSSH?
И, в особенности, какое он имеет отношение к средствам проектирования ПО??
Уважаемый, прежде, чем написать следующую бредятину, хорошо подумайте о жизни и о своём месте в ней.

SGS_67 пишет: 
ЗЫ. Если Вы ещё не поняли: современные средства разработки, приложения, библиотеки, драйвера сейчас можно найти в ИСХОДНИКАХ.
Тестировать, править и сопровождать самостоятельно, или с привлечением поддерживающих организаций, никто не запрещает.

Можно, только что вы будете делать с этими миллионами строк кода? 

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

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

Совершенно пересекающиеся.
(Тоскливо глядя на ПО Фобосов, в т.ч.,и Грунта).
Прежде, чем судить о надёжности, попробуйте её обеспечить хотя бы в своём курятнике, а дотоле не суйте нос туда, где вы ни ухом, ни рылом.

[SGS_67]

dmitryskey пишет:
Добавлю свои пять копеек, почему подход ИСС по крайней мере разумен. При наличии в конторе сложившейся методологии разработки и тестирования (в данном случае на Модула-2) гораздо проще, надежнее и дешевле при переходе на новую аппаратную базу перерабатывать toolchain и адаптировать его к новым платформам, чем переписывать код.

Попробуйте поставить себя на место специалиста ИСС, и ответить на простой вопрос: где брать ОС для новой платформы, типа Леона, и как её поддерживать при помощи Модулы-2 ?

dmitryskey пишет:
 Математические расчеты. Большая часть кода в библиотеках (а он по прежнему тут вне конкуренции) написан на древнем как дерьмо мамонта Фортране IV/66...

Когда Facebook только начинался, писали его по быстрому на PHP...

Исторически JavaScript был простым скриптовым языком, созданным на заре интернета Netscape буквально на коленке, и не счесть попыток замены его на что-то более приличное. Но в итоге в 2008 году Google сделал JIT компилятор V8, быстро после этого подтянулись Mozilla, Microsoft и Apple. То бишь снова оказалось проще toolchain улучшить...

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

Собственно, ровно то же самое сделал ИСС в 2000-2003 году (как уже Not упоминал в рамках договора №109, (кросс-система программирования на языке Модула-2 для OBC-1750 (с участием ООО "Эксельсиор" )) , да и где гарантия, что они потом просто не прикрутили к GCC кодогенератор для OBC-1750 и перешли на GNU Modula-2?

Когда кросс-система ИСС получит в мире такой уровень популярности и поддержки, как те же С и Джава, тогда и будет смысл об этом говорить.

И еще замечание про кросс-компиляцию. Если транслятор Modula-2->Ansi C дает код, что удовлетворяет требованиям на скорость исполнения в Real-Time - то ИСС можно было дальше и не улучшать ничего.

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

[SGS_67]

TAU пишет: 
1. Иногда бывает, что один прав, а большинство - заблуждается. По сути, гораздо правильнее использовать Модулу-2, нежели Си, при создании критически важных приложений. Весь мир "не стоит на месте", возможно, по пути к пропасти? )

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

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

Технология создания любого программного обеспечения далеко не сводится к используемому языку программирования.
А технология создания БПО не имеет никаких особенных отличий от технологии создания любого ПО, поскольку использует лишь конечное подмножество приёмов и методов последнего.

В том же ИСС используется огромное число специфических инструментов для поддержки различных сторон их технологии.

Коль скоро Вы в теме, опишите, пожалуйста, в двух словах хоть парочку специфических именно для ИСС инструментов поддержки их неповторимой технологии создания ПО.

 То есть приходящему на работу (кстати, не следует также забывать, что Железногорск - ЗАТО, и вопросы трудоустройства/переездов носят специфический характер) в любом случае приходится очень много чего нового изучать. 

Иными словами, приходящему в ИСС предлагают подписать договор о продаже души и тела без возможности его расторжения, верно?

3. Повторю. Ничего, повторение - мать учения. Особенности разработанной и тщательно выверенной технологии создания БПО позволили ИСС повысить скорость разработки.

Нда?
А вот мне, судя по контрактам, показалось, что только на создание кросс-системы для каждой новой платформы уходит в среднем 3 года.
Разубедите, пожалуйста, или скажите тогда, что Вы понимаете под "повышением скорости разработки"?

[dmitryskey]

SGS_67 пишет:

Echidna пишет:
30% уже конечно многовато. ЕМНИП, для систем с ОСРВ не более 10% должно быть. Ну на худой конец 15%.

Это не так.
Как раз ОСРВ и нужны для того, чтобы производительность платформы использовать по максимуму, без падений и подвисаний.
МСМ, 70-80%, загрузки - вполне нормальный показатель, при условии достаточной квалификации создателей ПО под ОСРВ.
Другое дело, что при его достижении вполне стоит подумать о разработке железа с бОльшими ресурсами по части быстродействия.

Не совсем корректное утверждение. ОСРВ не дает максимальной производительности в среднем - а гарантирует время отклика. Условно говоря, если исполняющий механизм на реакторе или двигателе отрабатывает за 10мс в силу чисто механических ограничений, это дает верхнюю оценку времени реакции софта. Выходит за нее ни в коем случае нельзя во избежании условного Чернобыля (по этой причине стандартные ОС просто нельзя использовать в таких условиях), сильно быстрее делать смысла большого нет. Но на практике даже на ОСРВ программное обеспечение уровня user-space стараются писать с загрузкой вроде вышеуказанной - береженого Бог бережет, да и зачастую очень сложно и дорого прорисовать граф исполнения и сделать максимальные оценки. Или же эти оценки дают в сумме больше 50% загрузки CPU (что при реальном исполнении не происходит), вот и делают все с запасом.

Чисто технологически, по крайней мере классические ОСРВ вроде QNX, VxWorks или Minix делаются на основе микроядра и наборов сервисов в слое user-space. Постоянный обмен сообщениями приводит к потерям в 15-35% при системных вызовах за из-за неизбежно возникающего overhead при проверках форматов и проч. Ну и до кучи читаем классическую переписку Грозного-Курбского в виде дискуссии Танембаума и Торвальда. Linux вполне себе монолитное ядро, уж точно не заточенное на гарантированное время отклика. Есть расширения типа RTLinux - про него не знаю, также как и не знаю, как SpaceX решает эту задачу. Зная их подход - они вполне могли и просто делать запас по ресурсам системы - а не бодаться с жестким Real-Time, это дело дорогое.

Изначально микроядерные Windows NT и Mac OS X достаточно быстро промутировали в т.н. гибридные ядра - когда есть микроядро - на над ним много монолитного кода. В основном, это связано с тем, что больше половины кода ядра состоит из драйверов и их реально тяжело разбить на сравнительно мелкие сервисы в духе Minix. Linux просто не заморачивается в силу доступности исходников - ядро одним кусков собирается (плюс компилируются подгружаемые модули)

[SGS_67]

dmitryskey пишет:

SGS_67 пишет:
Это не так.
Как раз ОСРВ и нужны для того, чтобы производительность платформы использовать по максимуму, без падений и подвисаний.

Не совсем корректное утверждение. ОСРВ не дает максимальной производительности в среднем - а гарантирует время отклика.

Ключевые слова выделил.

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

Но на практике даже на ОСРВ программное обеспечение уровня user-space стараются писать с загрузкой вроде вышеуказанной - береженого Бог бережет, да и зачастую очень сложно и дорого прорисовать граф исполнения и сделать максимальные оценки. Или же эти оценки дают в сумме больше 50% загрузки CPU (что при реальном исполнении не происходит), вот и делают все с запасом.

Это может говорить лишь о невысокой культуре создания ПО.

В целом, написание софта под ОСРВ требует чёткого понимания её функционирования, и владения приёмами создания "хороших" алгоритмов обработки данных. Т.е., достаточно высокой квалификации программиста.
При соблюдении этих условий, никаких особых "запасов" не требуется.

ЗЫ. Так что насчёт ОС для Леона?

[dmitryskey]

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

Мы, кстати, много обсуждали разработки на Модуле-2. А какая операционка в аппаратах ИСС используется? Или код просто напрямую прошивается и запускается из bios/monitor/etc.

И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

P.S. Википедия, конечно, это моветон, железячники должны авторитетно рассказать. Но по поводу Леона все выглядит очень прилично - разработан ESA, ISA Sparc-V8 (а по нему компетенции очень неплохие в России - давно уже рабочие станции делают на МЦСТ R-500/1000 c Spark-V9, причем частью процессоры в России производятся), лицензия хоть GPL, хоть коммерческая

LEON is a 32-bit CPU microprocessor core, based on the SPARC-V8 RISC architecture and instruction set. It was originally designed by the European Space Research and Technology Centre (ESTEC), part of the European Space Agency (ESA), and after that by Gaisler Research. It is described in synthesizable VHDL. LEON has a dual license model: An LGPL/GPL FLOSS license that can be used without licensing fee, or a proprietary license that can be purchased for integration in a proprietary product. The core is configurable through VHDL generics, and is used in system-on-a-chip (SOC) designs both in research and commercial settings.


Как обычный Sparс поддерживается кучей OC, включая Real-Time

The Real-time operating systems that support the LEON core are currently RTLinux, PikeOS, eCos, RTEMS, Nucleus, ThreadX, OpenComRTOS, VxWorks (as per a port by Gaisler Research), LynxOS (also per a port by Gaisler Research), POK (a free ARINC653 implementation released under the BSD licence) and ORK+ an open-source real-time kernel for high-integrity real-time applications with the Ravenscar Profile.

[thunder26]

SGS_67 пишет:
Попробуйте поставить себя на место специалиста ИСС, и ответить на простой вопрос: где брать ОС для новой платформы, типа Леона, и как её поддерживать при помощи Модулы-2 ?

Я может что то пропустил, но почему ИСС что то должно сделать для Леона?

[SGS_67]

thunder26 пишет:
Я может что то пропустил, но почему ИСС что то должно сделать для Леона?

Действительно, корректнее вместо "типа Леона" употреблять сочетание "процессор с архитектурой SPARC V8"; это было сделано ради краткости.
Итак, где предполагается брать ОС для данного процессора, и каким образом осуществлять её поддержку?

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

Мы, кстати, много обсуждали разработки на Модуле-2. А какая операционка в аппаратах ИСС используется? Или код просто напрямую прошивается и запускается из bios/monitor/etc.

Чего-чего?
К Вам аналогичный вопрос: предложите ОС для Леона, которую можно было бы поддерживать при помощи Модулы-2.

[thunder26]

SGS_67 пишет:
Итак, где предполагается брать ОС для данного процессора, и каким образом осуществлять её поддержку?

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

[dmitryskey]

Я, право, несколько смущен и запутан. Modula-2 НЕ является языком системного программирования, т.е. с таким же успехом можно спросить, где мы собираемся брать и поддерживать ОС при разработке на Java или, прости Господи, JS/NodeJS.

Помимо перечисленных выше ОСРВ (кои применимы к именно к ситуации ИСС), Sparc V8 (это 32-битная архитектура, для embedded systems 64-битные архитектуры избыточны) поддерживаются (навскидку) следующими ОС

[/li]
• Solaris
• Linux
• FreeBSD
• OpenBSD
• NetBSD
  

В качестве средств разработки для Solaris идут компиляторы С от Oracle, Linux & NetBSD/OpenBSD GNU/gcc, FreeBSD LLVM/clang или GNU/gcc.

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

[Павел Фишер]

Not пишет:
Ну, распараллелить можно только алгоритм, а не язык,

Not пишет:
Анализировать фортрановскую программу значительно проще

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

[dmitryskey]

Ну все-таки не стоит смешивать векторизацию и параллелизм (кому интересно, почитайте историю взаимоотношений CDC 8600 и Cray-1). Векторизация - это применение одной и той же операции к вектору данных, параллелизм - исполнение кода (вообще говоря, необязательно разного) в несколько потоков. Есть языки, хорошо приспособленные к автовекторизации вроде Фортрана, "чистые" функциональные языки по крайней мере в теории легко допускают параллельное исполнение (правда, накладные расходы на вызовы функций, передачу данных и запредельная сложность программирования именно численных расчетов выводит их за рамки нашей дискуссии).

В векторных расширениях gcc/clang и OpenCL, безусловно, помечаешь данные как векторные (или используешь предопределенные - пишешь что-то вроде int  - и потом применяешь одну операцию. Но инициализация векторов и чтение из них данных пишется достаточно специфическим образом, код зависит уже от расширения. В общем - простого покрытие атрибутами в С не происходит. 

[bsdv]

dmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня.
http://www.ghs.com/AerospaceDefense.html

[bsdv]

bsdv пишет:

dmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня, очень специфичная...
 http://www.ghs.com/AerospaceDefense.html
http://www.ddci.com/products_deos/

И на Аде пишут, и С не брезгуют...
Но там все завязано на сертификацию летной годности. Естесственно никакого опен сорс....

[SGS_67]

thunder26 пишет:

SGS_67 пишет:
Итак, где предполагается брать ОС для данного процессора, и каким образом осуществлять её поддержку?

Вроде в первом сообщении темы написано, не?

Писать врукопашную на Модуле, чтоль??

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

Беспокойства особого нет.
Просто интересно, как решаются подобные вопросы в рамках столь противоречивой концепции.

[SGS_67]

dmitryskey пишет:
Я, право, несколько смущен и запутан. Modula-2 НЕ является языком системного программирования, т.е. с таким же успехом можно спросить, где мы собираемся брать и поддерживать ОС при разработке на Java или, прости Господи, JS/NodeJS.

Вот именно.
Тогда поясните, какой средой должны, по Вашему разумению, пользоваться системные программисты ИСС?

Помимо перечисленных выше ОСРВ (кои применимы к именно к ситуации ИСС), Sparc V8 (это 32-битная архитектура, для embedded systems 64-битные архитектуры избыточны) поддерживаются (навскидку) следующими ОС

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

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

Мне, например, понятно, почему Леон (а, с вероятностью, близкой к 100%, речь идёт именно о нём) может представлять интерес для ИСС.
А с Вашей точки зрения, почему выбор устаревшей SPARC-based архитектуры является очень разумным подходом?

[dmitryskey]

bsdv пишет:

bsdv пишет:

dmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня, очень специфичная...
 http://www.ghs.com/AerospaceDefense.html
 http://www.ddci.com/products_deos/

И на Аде пишут, и С не брезгуют...
Но там все завязано на сертификацию летной годности. Естесственно никакого опен сорс....

Спасибо большое, очень занятно! Интересно, как регламентируется использование Ады, все-таки больше 30 лет просто с того знаменитого конкурса Минобороны. Да и с тех времён язык очень сильно вперёд ушёл.

[dmitryskey]

SGS_67 пишет:

dmitryskey пишет:
Я, право, несколько смущен и запутан. Modula-2 НЕ является языком системного программирования, т.е. с таким же успехом можно спросить, где мы собираемся брать и поддерживать ОС при разработке на Java или, прости Господи, JS/NodeJS.

Вот именно.
Тогда поясните, какой средой должны, по Вашему разумению, пользоваться системные программисты ИСС?

Помимо перечисленных выше ОСРВ (кои применимы к именно к ситуации ИСС), Sparc V8 (это 32-битная архитектура, для embedded systems 64-битные архитектуры избыточны) поддерживаются (навскидку) следующими ОС

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

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

Мне, например, понятно, почему Леон (а, с вероятностью, близкой к 100%, речь идёт именно о нём) может представлять интерес для ИСС.
А с Вашей точки зрения, почему выбор устаревшей SPARC-based архитектуры является очень разумным подходом?

Возможно, что среда разработки своя - а нет, так тогда все можно сделать так же, как и для Вашего HTC - берем сертифицированный Linux (можно взять ОС МСВС, хоть на x86/x64, хоть на Sparc), Eclipse с соответствующим модулем или просто Vim/Emacs для любителей консоли, GNU Modula-2/GDB (вместо Android SDK) - и вперед, пишем код, тестируем на эмуляторе (понятно, что никто не станет на реальном железе разработку вести). Потом пересобираем при помощи кросс-компиляции (и вышеуказанный договор о разработке вполне мог касаться именно его), прогоняем некий набор тестов - и вперед, на стенд к реальному аппарату.

По архитектурам. 10 лет назад на ужине в Бостоне (оплаченном, кстати, Гуглом) инженер Intel и Broadcom донес до меня следующую мысль. После бурных войн 80-90 архитектуры ушли каждая в свои ниши.

• x86/x64 - максимально возможная общая производительность, максимальная поддержка со стороны ПО.
• ARM - гибкое лицензирование, максимальная производительность на ватт мощности - поэтому и занял практически мобильную нишу
• MIPS - гибкое лицензирование, максимальная производительность на единицу стоимости. Как ни странно, по количеству CPU это самая распространенная архитектура - ставится в сетевые устройства.
• Sparc - открытое по GPL лицензирование, что в ряде случаев критично из соображений безопасности (не все же делать нелицензионный MIPS как китайцы)
• Power - максимальная производительность по float point (хотя понятно, что тут все меняется быстро), это своя архитектура IBM, она им важна для бизнес применений, до недавнего времени (до PS-4 и XBox One) практически все игровые консоли строились на этой архитектуре.
• s390 - как правильно писали - сквозная поддержка ПО для майнфреймов.
  

Единственная приходящая в голову действительно устаревшая архитектура - это IA-64. Причем она даже скорее не взлетела просто, так и не смогли написать достойные компиляторы для EPIC.

[SGS_67]

bsdv пишет:

bsdv пишет:

dmitryskey пишет:


И может, кто просветит, что на сей счет американская военщина использует на том же F-35?

У них своя кухня, очень специфичная...
 http://www.ghs.com/AerospaceDefense.html
 http://www.ddci.com/products_deos/

И на Аде пишут, и С не брезгуют...
Но там все завязано на сертификацию летной годности. Естесственно никакого опен сорс....

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

Желающим повторить подобный "подвиг" хочется пожелать попутного ветра в корму.

[sychbird]

По поводу F-35. Когда полный набор функциональности, запихнутый в один девайс, переходит некий порог по объему, наступает  состояние принципиальной не полной стабильности  набора функциональности в процессе производства  .и интеграции его с ПО, а также и работы девайся. Вероятность ошибок при воспроизведения ПО и интерфейсов, аппаратных средств и прочей требухи становиться велика просто в силу их общего количества. 


В качестве аналогии - психические заболевания человека. Шизофрения и т.п.