Особенности программирования БВК АМС

[Вадим Семенов]

:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.

Кухонным ножём можно отрезать палец, а можно сделать салат. Аналогия ясна?

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

Детские ошибки в Си легко отлавливаются различными рантайм чекерами.

В рантайме после обнаружения ошибки остается только застрелиться.

В совокупности со статическими верификаторами и полноценным тестированием это даст высокую надёжность.

Увы. Статические верификаторы не умеют читать мысли разработчика, а сам язык средств выразить эти мысли компилятору не предоставляет.

[avp]

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

Это полуправда. Для современных процессоров Intel компиляторы действительно вылизаны и оптимизированы хорошо, для AMD всё уже значительно не так радужно. Для процессов других архитектур или даже для 186 уже всё очень и очень печально.

Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров. Попробуйте перемножить матрицы на векторном процессоре на ассемблере. Или попробуйте вручную загрузить конвейер для эффективной обработки той же матрицы. Причем речь не о встроенных конвейерах АЛУ, а именно о внешних, управляемых пользователем. Трансляторы же с ЯВУ делают это значительно лучше.

Эффективный компилятор для архитектуры VLIW (эльбрус, итаниум) так и не написан, т.к. это очень трудоёмкая задача. Ручная загрузка конвеера тут пока позволяет добиваться лучших результатов, особенно в синтетических тестах.

[avp]

Уж извините, из песни слов не выкинуть - в Эрланговской ВМ целые числа имеют размерность ограниченную только объемом ОЗУ.

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

[avp]

:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.

Кухонным ножём можно отрезать палец, а можно сделать салат. Аналогия ясна?

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

Вот вы почти уже поняли.  Такой нож невозможен без резкого снижения эффективности инструмента. Можно заставить повара работать тупым ножём, чтобы случаем не порезался или не убил кого.

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

Детские ошибки в Си легко отлавливаются различными рантайм чекерами.

В рантайме после обнаружения ошибки остается только застрелиться.

Имеется ввиду фаза тестирование (debug сборка).

[Artemkad]

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

Простите, но похоже Вы так-же не сильно в курсе возможностей СОВРЕМЕННЫХ компиляторов. В них есть возможность раздельной компиляции нескольких кусков проекта, а потом их линковка. Это позволяет не перекомпилировать весь проект при каждом изменении, а только его малую часть в которой эти изменения произошли. Это в разы ускоряет процесс правка-компиляция-проверка.
ЗЫ. Естественно для использования этой возможности надо во первых о ней знать, а во вторых ее использовать.

[avp]

Простите, но похоже Вы так-же не сильно в курсе возможностей СОВРЕМЕННЫХ компиляторов. В них есть возможность раздельной компиляции нескольких кусков проекта, а потом их линковка. Это позволяет не перекомпилировать весь проект при каждом изменении, а только его малую часть в которой эти изменения произошли. Это в разы ускоряет процесс правка-компиляция-проверка.

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

[zyxman]

Простите, но похоже Вы так-же не сильно в курсе возможностей СОВРЕМЕННЫХ компиляторов. В них есть возможность раздельной компиляции нескольких кусков проекта, а потом их линковка. Это позволяет не перекомпилировать весь проект при каждом изменении, а только его малую часть в которой эти изменения произошли. Это в разы ускоряет процесс правка-компиляция-проверка.

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

Вот для этого и нужны ВМ с поддержкой понятия модуля кода. Чтобы код системы загружался не целиком и не в жестко прописанные адреса, а был перемещаемым с динамическим связыванием (аналог позднего связывания, только работающий и после загрузки). Плюс в системе должно быть предусмотрено возможность такой перезагрузки на уровне языка и стандартов кодирования, путем исключения сторонних эффектов.
Вобщем получается чистый функциональный подход с асинхронными сообщениями.
Итого конечно на функциональщину и асинхронность будут потери, но зато избавляемся от необходимости кустарщины и получаем полноценное промышленное решение 24/7/365.

[zyxman]

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

Это полуправда. Для современных процессоров Intel компиляторы действительно вылизаны и оптимизированы хорошо, для AMD всё уже значительно не так радужно. Для процессов других архитектур или даже для 186 уже всё очень и очень печально.
..
Эффективный компилятор для архитектуры VLIW (эльбрус, итаниум) так и не написан, т.к. это очень трудоёмкая задача. Ручная загрузка конвеера тут пока позволяет добиваться лучших результатов, особенно в синтетических тестах.

Анекдот про "неуловимого Джо" знаете? - Он неуловимый потому что никому не надо его ловить..
Ну так вот фирма Intel просто традиционно решает проблемы в своих процессорах улучшенным компилятором, а фирма AMD просто сделала такой процессор что там в таком серьезном вылизывании нет необходимости.
С 186 и VLIW ситуация аналогичная, но специфика чуть другая - просто этих процессоров настолько малое количество (в сравнении с Intel x86), что никто не хочет вкладываться в разработку оптимизатора.

[zyxman]

Уж извините, из песни слов не выкинуть - в Эрланговской ВМ целые числа имеют размерность ограниченную только объемом ОЗУ.

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

Есть у американцев такое мудрое понятие "Good Enough", то есть буквально "Достаточно Хороший".
- Эрланг не предназначен для вещей которые хорошо делаются на ассемблере. Вместо того чтобы доходить до фанатизма и делать одним инструментом всё (за счет обязательных проблем - то-ли трудоемкости использования инструмента, то-ли сложности, то-ли еще чего-то), нормальные люди имеют набор инструментов, каждый под свою область, с универсальным интерфейсом для их совместного использования.
То есть если вам нужно, есть несколько способов подключить к ВМ двоичные модули. Один из способов прилинковка двоичного модуля к ВМ.

Но вообще тк Эрланг был предназначен для телекома, а там есть множество бинарных протоколов, соответственно в язык ввели поддержку работы с бинарными полями - в первом приближении идеология этого расширения похожа на regex. Если хотите распишу подробнее.
И бинарными полями можно при желании "через левое ухо" посчитать что угодно, контрольную сумму даже наверное получится красиво.

[TAU]

я вижу море программеров окошек, делающих свою работу спустя рукава, небрежно и плохо

Увы, можно лишь согласиться  Зачастую еще и сопровождается неумеренным апломбом "я самый умный".

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

И он прав!

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

Безусловно.

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

Еще бы. Поэтому важен комплекс мер обеспечения надежности и качества БПО. Напишу подробнее ниже.

[TAU]

на асме действительно создавать высоканадёжный код... медленно.

По моему опыту - с некоторого размера нет!
Кроме того во весь рост встает проблема совместной работы нескольких программистов над одним кодом

Вот! Голос не мальчика, но мужа!   Ключевые вещи названы.

[TAU]

- ОАО ИСС ведет разработку на собственной кросс-платформе на базе языка Модула-2, которая для покрытия большего числа платформ включает в свой состав фронт-компилятор в язык Си. Т.е. там ассемблера вообще в принципе быть не может ни на каком этапе.

Ну уж прям.   Некоторые подпрограммы там наверняка на ассемблере

Да, в публикациях вроде проскальзывало об использовании ассемблера.

[TAU]

вопрос к разработчикам космического софта?
Есть ли формальные технические требования (format technical requirements), для софта, которые реально НАДО выполнять?
В авиации очень с этим строго

Весьма уместный и актуальный вопрос!

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

[TAU]

Итак, попробую обобщить.

Для построения высоконадежного ПО БВК АМС (и вообще ПО КА, РБ и РН а также наземных комплесов управления) нужен целый комплекс мер. Мое мнение:

1. Приведение заработной платы и престижа профессии программиста БВК к соответствующих значимости и сложности решаемых задач уровням. Это - необходимое условие! При этом - воспитание ответственности и аккуратности у разработчиков, поддерживаемое комплексом соответствующих организационных мер.

2. Полноценная наземная отработка изделий, включая многоэтапную  отладку ПО, включая моделирование внешней среды и использование натурного БВК, интерфейсов и аппаратуры.

3. Выработка минимальных стандартов, обязательных для реализации при создании ПО в отрасли (пример из авиации здесь приводился) , создание нормативной основы в области процессов создания ПО (в виде рекомендаций, требований, стандартов). Аттестация на основе единой шкалы критериев, качества процессов и технологий создания ПО на предприятих отрасли.

3. Активное внедрение в отрасли современных достижений науки и практики в области программной инженерии, включая формальные методы верификации - доказательства правильности, model checking, и пр., проблемно-ориентированных языков спецификаций и программирования.

4. Разработка на основе анализа отечественного и зарубежного опыта базовых принципов методологии и технологии создания высоконадежного отказоустойчивого ПО.

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

6. Создание отраслевой "базы знаний" по принципам, методологии, языкам, моделям, инструментальным средствам разработки высоконадежного ПО для передачи накопленного квалифицированными сотрудниками опыта молодым и обеспечения "связи поколений".

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

Вероятно, при их выполнении надежность ПО систем управления несколько повысится. Какие будут дополнения, предложения?

[Artemkad]

А зачем нам рассматривать 8-битные машины, когда давно летают 32-битные?

Потому, что жрать 1 Вт для задачи у которой есть 10мкВт слегка не разумно. На данный момент 8 битники все-же наиболее отлажены, меньше всего жрут и имеют наибольшую надежность.

Если же ну очень нужно выжать все из архитектуры конкретного контроллера - ну пожалуйста, используйте вставку _asm_ . Но зачем всё корячить на ассемблерной коленке?  

Вставлять вставки не имеет смысла - не эффективно. Как правильно заметили, мелкие куски компилятор делает эффективнее. Тут или все писать на Асме или все на Си.

[PIN]

Ветка ушла в совершенно нерелевантную проблематике сторону, ИМХО.

Кто-нибудь имеет статистику или лиично сталкивался с проблемами в бортовом ПО? Я - да, причеим, с ПО, разработанным с использованием совсем разных инструментальных средств и на разных языках разными подрядчиками. И 90% проблем связаны с алгоритмическими ошибками на ранних стадиях разработки и ошибками в требованиях (технических заданиях).

[Not]

Скажите прямо, пока я еще на форуме, вы что-то создали своим руками ? От задумки, квадратов, моделирования алгоритмов на языке высокого уровня, до железа+программ, до тестов образцов, испытаний ? Я - да.

Кто-нибудь имеет статистику или лиично сталкивался с проблемами в бортовом ПО? Я - да

Это только у меня в глазах двоится?

 :mrgreen:

[Дем]

Итак, попробую обобщить.
[....]
Вероятно, при их выполнении надежность ПО систем управления несколько повысится. Какие будут дополнения, предложения?

Всё в принципе верно. Но нужно не столько ПО заниматься, а идти глубже - начиная с определения самой архитектуры борта.
А не по принципу "вот мы тут контроллер наразводили - спаяли, давай программируй!"

[bs]

Кто-нибудь имеет статистику или лиично сталкивался с проблемами в бортовом ПО? Я - да, причеим, с ПО, разработанным с использованием совсем разных инструментальных средств и на разных языках разными подрядчиками. И 90% проблем связаны с алгоритмическими ошибками на ранних стадиях разработки и ошибками в требованиях (технических заданиях).

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

[Дем]

Это интересно, только не совсем понятно, что имеется в виду под алгоритмическими ошибками.

Алгоритмические - это не когда a*b+c вместо a*(b+c) написали, а когда вообще функцию вызвать забыли.