На чем пишется софт для КА?

Автор hudvin, 06.05.2009 15:28:09

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

hudvin

ЦитироватьДа ладно ... Smile
Обходит, обходит. В крайнем случае переписывание на асме даст прирост производительности 10-15%.  Поэтому на нем щас и пишут только либо сильно системные вещи, только очень(ОЧЧЕНЬ!) числодробильные.
Но справедливо для обычных процов и обычного софта. А как в космонавтике - не знаю, поэтому и спрашиваю.

Инженер проекта

ЦитироватьВ крайнем случае переписывание на асме даст прирост производительности 10-15%.  Поэтому на нем щас и пишут только либо сильно системные вещи, только очень(ОЧЧЕНЬ!) числодробильные.
С оптимизацией команд согласен, но я ещё имел ввиду оптимизацию алгоритма, а здесь компилятор не поможет  :) Думать за вас он не будет, это дано только человеку. "Умный" компилятор - это всего лишь приятное дополнение. Спецподход вылазит из за специфики работы с железками - реалтайм однако  :)
«И каждый мнит себя стратегом,
Смотря на бой со стороны»

Bell

ЦитироватьТоже такое слышал. Некоторые вроде под DOSом летают.
Летать под дисковой операционной системой конечно можно.
Если знать - под чьей ;)
Иногда мне кажется что мы черти, которые штурмуют небеса (с) фон Браун

hudvin

ЦитироватьС оптимизацией команд согласен, но я ещё имел ввиду оптимизацию алгоритма, а здесь компилятор не поможет Smile Думать за вас он не будет, это дано только человеку. "Умный" компилятор - это всего лишь приятное дополнение. Спецподход вылазит из за специфики работы с железками - реалтайм однако Smile
ну тормозной алгоритм тормозить везде будет.
опять же, смотря какой реальтайм и на чем. Одно дело на вообще голой железке, другой - на железке под управлением RTOS

ДмитрийК

Цитировать... пишут на AHDL'е, Verilog'е, VHDL'е и подобном.
ПЛИС это замечательно но все-же кесарю-кесарево а слесарю-слесаево :) У ПЛИС и у процессоров какбы совсем разные ниши. Они конечно пересекаются до некоторой степени но в большинстве случаев выбор между С и VHDL очевиден.

Цитироватьи поддержка разработчика хорошая,
А можно поинтересоваться, о каком вендоре/платформе идет речь? Я пришел (а точнее вернулся) в железо из софта и если честно, был поначалу просто шокирован низким качеством ПО. MSVC просто недосягаемый идеал качества по сравнению напр. с Xilinx ISE или ModelSim.

Потом, вот еще какой вопрос. Компилятор - штука хорошо известная. В СССР/России была/есть?  своя неплохая школа. На худой конец в качестве отправной точки всегда есть OpenSource. Т.е. иметь/поддерживать/развивать свой инструментарий разработки ПО не должно быть особых проблем. Если честно не знаю как обстоит дело в России со своим софтом для разработки ПЛИС, но судя по тому как с этим в мире (хреново - софта мало, он дорогой, кривой и глючный), смело предполагаю что не очень. А каким образом режимный ФГУП получит нормальную поддержку от иностранного вендора - для меня загадка. В смысле как ей пользоваться?
- "Але, вендор, у меня PAR слетает, internal error 123"
- "Ну хорошо, пришлите нам ваш нетлист, мы посмотрим"
 - :shock:  :shock:  :shock: Ага, вот так щас прям и пришлю :shock:  :shock:  :shock:
У нас в контора ни с какими государственными/военными секретами дела не имеет, только обычная коммерческая тайна как у всех, и то пляски с бубном начались вокруг этой NDA на техподдержку.

Цитировать...проще в отладке.
Или вы шутить изволите или мы в параллельных вселенных обитаем. Для софта отладчик  (мелкософт) меня вполне устраивает, все что нужно в нем видно без проблем. Компилируется софт практически мгновенно (если мало изменений). Железо варится 40 минут, чтобы увидеть что происходит внутри надо на уши встать, одну запятую поменял - опять 40 минут сидишь читаешь форум НК :) Про ModelSim в моем случае вообще можно забыть. Вечером ставлю, с утра прихожу - он еще на середине пути.

Цитировать...за один вечер собственный процессор вида CISC со всеми феничками...
Да, все мы этим грешны :) Раньше говорилось что каждый настоящий программист должен хотя бы раз в жизни написать свой язык и свою ОС, теперь к этому добавился еще и процессор с периферией :) Не, свой процессор это круто, в хорошем смысле слова, вот только если играть по правилам то надо стопкой сложить спецификации, архитектурный / детальный дизайн, руководств по системе команд, описание интерфейсов, тест-план, и пр. и посмотреть сколько вместе дофига сантиметров получается. Я иронизирую конечно но только отчасти, потому что через нечто подобное проходил.

ЦитироватьВ целом я думаю, каждая большая IT контора в итоге имеет собственный микропроцессор, который её удовлетворяет и устраиват, собственный язык и тп.
А смысл? Процессоры они все похожи как близнецы-братья, в конце концов они все делают одно и тоже. Вот сейчас мы выбираем микроконтроллер для одного проекта.  Критерии - цена, производительность, как сделан DRАМ и DMA интерфейс, площадь корпуса, потребляемая мошность. Все. Какая там будет система команд - всем глубоко пофиг. Ну а если хочется/нужно иметь свой самопальный процессор, есть замечательные готовые системы команд и интерфейсы которые можно "позаимствовать". С языками похожая ситуация - по производительности они все примерно сравнялись а от навороченных абстракций часто приходится отказываться ради жесткого контроля программиста над тем что же на самом деле происходит. Поэтому какой-нибудь вариант embedded C будет не намного хуже любого другого. Или Модула если ее так любят, все один хрен. Зато когда новый человек приходит в команду, он может читать код сразу и без словаря.

А вообще программы (и железо) у нас в конторе пишут в основном в ворде, поверпойнте и визио,  еще на матлабе и питоне :)

ДмитрийК

ЦитироватьС оптимизацией команд согласен, но я ещё имел ввиду оптимизацию алгоритма, а здесь компилятор не поможет  :)
Зато его отсутствие может сильно помешать. На С человек может посмотреть на функцию и сказать "а дай-ка я здесь попробую хеш-таблицу вместо линейного списка". На ассемблере человек потратит полдня на то чтобы сэкономить 4 байта кода и 3 цикла, код будет красивый и изящный, но просто вот все бросить и переписать чтобы "попробовать" хеш-таблицу ему и в голову не придет. По себе знаю :)

ДмитрийК

ЦитироватьНо справедливо для обычных процов и обычного софта. А как в космонавтике - не знаю, поэтому и спрашиваю.
А что летает-то в основном? RISCи всякие по большей части, MIPSы и SPARCи вроде как если я не ошибаюсь? А для них на ассемблере писать - дело неблагодарное.

jettero

Понятно что основные проги для КА пишут на высоком уровне, где-то я встречал, что в НАСА на питоне часто пишут, на асме это убиться можно пока отладишь, да и ошибок можно больше пропустить.
А ассемблерный код, PIC'и, ПЛИС'ы и прочая мидлварь это более низкий уровень системы – это исполнительные механизмы, а основные программы стоят выше и обычно они под RTOS крутятся.

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

Not

ЦитироватьС оптимизацией команд согласен, но я ещё имел ввиду оптимизацию алгоритма, а здесь компилятор не поможет  :)
Это смотря какой компилятор. Если компилятор достаточно совершенен, то он в состоянии 1) глобально оптимизировать ваш алгоритм с учетом известных входных данных. 2) Вывести более оптимальный алгоритм из существующего с учетом частично известных входных данных. Очень простой пример: предположим вам в программе нужно извлекать квадратный корень из числа. Вероятно вы или воспользуетесь стандартной подпрограммой sqrt(x), или даже напишете свою, оптимальную для вашего железа. Что сделает обычный комплилятор? оттранслирует ваш код в вызов функции. Что сделает глобально-оптимизирующий компилятор? Первым делом он проверит, не является ли значение, передаваемое в функцию, константой. Константным оно может стать где угодно на пути к этой функции, потому и речь о глобальной оптимизации. Далее, если оно константно, то значение корня тут же будет вычислено и подставлено вместо вызова функции sqrt(x). Это был простейший пример, но естественно возможны значительно более интересные и малопостижимые на первый взгляд ситуации. Отсюда и ускорение работы программы в десятки раз. Можно пойти еще дальше, применив суперкомпилятор, который не просто определит константность выражений, но преобразует алгоритм исходя из правил эквиваелнтных преобразований.
Подробности можете найти на сайти www.refal.net от Института прикладной математики.

YuriyV

Цитировать
ЦитироватьС оптимизацией команд согласен, но я ещё имел ввиду оптимизацию алгоритма, а здесь компилятор не поможет  :)
Это смотря какой компилятор. Если компилятор достаточно совершенен, то он в состоянии...
Для иллюстрации. Была написана программа на C++ с ассемблерными вставками. В новой версии решили отказаться от ассемблера и переписали вставки на С++. После компиляции с оптимизацией код стал компактнее и быстрее. Посчитали, оказалось, что оптимизированный код на С++ быстрее и компактнее "ручного" ассемблера процентов на 30. Не оптимизация ли это алгоритма? :-)

Not

Цитировать
Цитировать
ЦитироватьС оптимизацией команд согласен, но я ещё имел ввиду оптимизацию алгоритма, а здесь компилятор не поможет  :)
Это смотря какой компилятор. Если компилятор достаточно совершенен, то он в состоянии...
Для иллюстрации. Была написана программа на C++ с ассемблерными вставками. В новой версии решили отказаться от ассемблера и переписали вставки на С++. После компиляции с оптимизацией код стал компактнее и быстрее. Посчитали, оказалось, что оптимизированный код на С++ быстрее и компактнее "ручного" ассемблера процентов на 30. Не оптимизация ли это алгоритма? :-)
Возможно, нужно смотреть на параметры компилятора. Хотя, скорее всего компилятор оптимальнее сгенерировал код для конкретного процессора. Можно ведь и на ассемблере писать достаточно обще. Например, можно по-разному описывать пролог-эпилог вызова функции, что резко скажется на размере и скорости работы кода.

natsvin

у как
Цифровой Прогресс запустили аж в 2008 году..............
может Шарп или Нумерле наконец освоют...
а то наш балет тут непрокатывает...
все в Сомали и Кению строить космодром! Остальные на стройку ПЖД!!!

Juni

А ГРАФИТ-ФЛОКС (ДРАКОН технологию) нельзя использовать для создания софта для КА? Только для РН и МБР используют?

Guest03

С/С++. Все в зависимости от процессора бортовой машины. Некоторые вещи на ассемблере.
Компилятор оптимизирует код прекрасно. Зачем гнаться за оптимальностью в ассемблере, если скомпиленый код на СИ дает показатели удовлетворяющие всем критериям?

mOleg

а Форт не хотите?
http://forth.gsfc.nasa.gov/
это кстати и по поводу Шаттла, и процессора, если не ошибаюсь RTX2000 , который Форт-процессор :)

Александр Куприянов

ЦитироватьВ кодах БЦВМ. И прошиваются буквально. Зато минимум памяти, надежно и никаких вирусов.


http://www.fastcompany.com/magazine/06/writestuff.html

Для Шаттлов пишут в Hal/S - довольно любопытная технология "письма". Высоконадежная. Стоимость пронраммирования в 1600 (вроде так) раз дороже некосмических продуктов.
Allex

Александр Куприянов

ЦитироватьВ кодах БЦВМ. И прошиваются буквально. Зато минимум памяти, надежно и никаких вирусов.


http://www.fastcompany.com/magazine/06/writestuff.html

Для Шаттлов пишут в Hal/S - довольно любопытная технология "письма". Высоконадежная. Стоимость пронраммирования в 1600 (вроде так) раз дороже некосмических продуктов.
Allex

Александр Куприянов

ЦитироватьС/С++. Все в зависимости от процессора бортовой машины. Некоторые вещи на ассемблере.
Компилятор оптимизирует код прекрасно. Зачем гнаться за оптимальностью в ассемблере, если скомпиленый код на СИ дает показатели удовлетворяющие всем критериям?


Для Шаттлов пишут на HAL/S. Посмотрел последнее по нему руководство программиста - 441 страница.
Качество процесса программирования определяется не только $35 000 000 годовым бюджетом на 260 сотрудников, но и особенностями процессов:

And no coder changes a single line of code without specs carefully outlining the change. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.

The developers have even begun their own formal inspections of the code in carefully moderated sessions, a rigorous proof-reading they hope will confound the testers. The verifiers, in turn, argue that they deserve credit for some errors found before they even start testing. "From the verification group's perspective," says Pat McLellan, a senior manager, "we're aware that if there was no independent verification group, the developers would tend to be more lax. Just the presence of our group makes them more careful."

Importantly, the group avoids blaming people for errors. The process assumes blame - and it's the process that is analyzed to discover why and how an error got through. At the same time, accountability is a team concept: no one person is ever solely responsible for writing or inspecting code. "You don't get punished for making errors," says Marjorie Seiter, a senior member of the technical staff. "If I make a mistake, and others reviewed my work, then I'm not alone. I'm not being blamed for this."
As the rest of the world struggles with the basics, the on-board shuttle group edges ever closer to perfect software.

Admittedly they have a lot of advantages over the rest of the software world. They have a single product: one program that flies one spaceship. They understand their software intimately, and they get more familiar with it all the time. The group has one customer, a smart one. And money is not the critical constraint: the groups $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations
Allex

bsdv

Немного не в тему, но для Боингов ПО написано на С, процессор PowerPC.

Pavel

ЦитироватьНемного не в тему, но для Боингов ПО написано на С, процессор PowerPC.

А в МО США используется Ада. И что?  Ничего.. Вообще эти битвы стороников разных языков програмирования так умиляют... На мой взгляд идеальных языков нет и быть не может...
Вообще когда я изучал различные языки програмирования больше всего меня впечатлил Пролог.. Дейстительно вериться, что на его основе можно создать подобие искуственого интелекта.