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

[Not]

Profiler вам в помощь  :wink:

Если все потом смотреть профайлером и дебаггером - какой смысл в языке высокого уровня?

Все смотреть не нужно. Смотреть нужно узкие места. Если вы  не вписываетесь в отведенный вам квант времени для данной операции - вот там и смотрите. Прописные ж истины...

[bs]

А вот например я веду статистику и вижу, что у меня блок памяти стал давать много ошибок - и я хочу его исключить из работы - вот такую возможность надо предусмотреть для КА - это ведь нормально? Свой менеджер памяти надо писать, стандартный не покатит. Вот допустим в параллельно работающих машинах я меряю джиттер по исполнению - и когда он превышает определенную величину, отключаю процессорную секцию - это кем-то уже написано для ЯВУ?

Это все безусловно очень круто, но это логичнее было решать на уровне ОС, а не в СПО.

Вполне реально на асме написать с резервированием пары регистров - и когда космические лучи или еще какая хрень выбъет регистр - по результатам тестирования код самомодифицируется и будет использовать резервный регистр. И так далее.

Я уже видел такое в фильме "Терминатор 2"  :!: :twisted:

Правда, по нынешним временам наверное дешевле воткнуть 100500 ява-процессоров от разных производителей мобилок по баксу и мажоритарно определять, кто прав...

Патентуйте идею! Я просто уверен, что каждый раз отваливать по $200-300k за RADx000 не айс.

[zyxman]

Ну и дополним тем, что ваш алгоритм некорректен в смысле отстутствия проверки на переполнение при умножении и сложении. То есть появляетя третья и четвертая, пятая и так далее ветви, на каждой некорректной арифметической операции. Разные процессоры ведут себя по разному. Одни генерируют аварийное прерывание. Другие присваивают значение NAN и умывают руки. Ну а вы, как программист чешете репу и пытаетесь понять, откуда взялись неучтенные ситуации.  :wink:

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

Коллеги!
Я считаю что вы оба правы, но вижу что один недопонимает, а другой не может объяснить. Попробую объяснить я.
Суть в том, что действительно обработать ВСЕ ситуации сколько-нибудь сложной системы действительно невозможно, НО возможно декомпозицией разбить сложную систему на совокупность простых систем, каждую из которых проверить точно можно.
И уж извините, но из песни слов не выкинешь - рантайм вроде Ады и Эрланга, с проверками диапазонов переменных и входных параметров во время исполнения позволяет сделать действительно всё надежно, тк блоки кода будут вызываться ТОЛЬКО с заранее протестированными данными.

[Not]

Суть в том, что действительно обработать ВСЕ ситуации сколько-нибудь сложной системы действительно невозможно, НО возможно декомпозицией разбить сложную систему на совокупность простых систем, каждую из которых проверить точно можно.

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

[zeaman]

Очень интересная дискуссия.

А можно вопрос к разработчикам космического софта?

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

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

Вот например, С++ coding guideline. Читаешь- сердце радуется :-)
http://www2.research.att.com/~bs/JSF-AV-rules.pdf

[zeaman]

dup

[bs]

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

Снова здравствуй модель асинхронных агентов? Я знал, что в этом что-то есть.

[zyxman]

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

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

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

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

[bs]

Вот например, С++ coding guideline. Читаешь- сердце радуется :-)
http://www2.research.att.com/~bs/JSF-AV-rules.pdf

Ух ты. Это просто подарок, вещь! Теперь я знаю куда тыкать мордой брыкающихся молодых жеребцов, то и дело норовящих поставить открывающую "{" не на новой строке :twisted: Lockheed Martin и баста. :!:

Ну и в целом приятно видеть, что за годы разработки были набиты правильные шишки :lol:

[zyxman]

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

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

Кстати да. Я несколько лет назад писал статью как раз про эти самые анализаторы кода, и тогда пришел к выводу что их огромное количество в случае Си и C++ вызвано слишком большой вольностью в языке, вкупе с низкой выразительностью языка.
Причем для С/C++ есть крайне неприятный момент, что для него например невозможно сделать программу автоматической проверки соответствия стандартам кодирования без привлечения ИИ или ручного труда.
Я не говорю что это проблема только С/С++, но для них это проблема вселенского масштаба ввиду колоссальных объемов готового кода.

[zyxman]

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

Ну это вас жестоко развели! :wink:

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

[zyxman]

.
Ну это вас жестоко развели! :wink:

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

Это не специфика задачи, а специфика недостатков используемых вами инструментов.
- В виртуальных машинах горячая замена отдельных модулей без перезагрузки системы вполне рядовое явление. Такое ТОЧНО есть в Эрланг ВМ (которая BEAM), а также в ВМ исполняющей Enterprise Java Beans (подробности уточню по запросу).

[zyxman]

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

Снова здравствуй модель асинхронных агентов? Я знал, что в этом что-то есть.

Ну дык Эрланг неглупые люди делали :lol:

[Unispace]

Я бы сформулировал по-другому: либо система была НЕграмотно спроектирована или плохо реализована, что любое изменение приводило к перекомпиляции огромного объема кода, либо низкокачественные средства разработки не умеют использовать элементарное кеширование уже скомпилированных блоков кода.
.

Да, 6 стран и фирмы, капиталистические, по вашему определению, включая Bell Labs, не умеют проектировать, куда им до zyxman. Повторяю, я перестал вас воспринимать серьезно, уж не в обиду. Вы несете бред с гордым видом человека, который не может себе представить ничего из того, что не укладывается в его мирок. И не знаком со многими вещами, как организационными, так и технологическими, а свое незнание трансформирует в стандартный вариант "они дураки, а мы умные". Увы, часто все наоборот. Не пишите мне более по техническим темам.

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

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

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

Религия запрещает? Бездоказательное и ошибочное утверждение.

Только оценка на уровне алгоритма и выбранных форматов данных. Задачи уменьшения ошибок при интенсивных математических расчетах весьма сложны.

Именно. Поэтому не стоит делать их в ручную. Человеку свойственно ошибаться.

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

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

Вообще тут очень большой перекос в сторону формального тестирования непонятно чего.

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

ЗЫ Тот факт, что вы где-то работали и что-то разрабатвали ни коим образом не отменяет сей факт. Такое встречается сплошь и рядом.

[avp]

Ну по аналогии при необходимости всегда можно сделать библиотеку типов со вставками на асме с такой жесткой проверкой всех операций и генерацией исключений по результатам проверок. Так что даже такая глобальная паранойя вполне реализуется и на ЯВУ.

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

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

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

Нет, это просто прекрасно!

Вы мне напомнили мой давний диалог с одним очень бородатым и очень умудренным опытом программистом на FoxPro, который руководил отделом ИТ в Русславбанке и в частности был отцом их системы банк-клиент по состоянию на 2006-й год. Я тогда регистрировался как ИП и подбирал банк для расчетных счетов. Будучи человеком не далеким от ИТ я естественно расчитывал никак не меньше, чем на нормальную систему управления счетами по инету. Так вот, когда я засыпал операционистку вопросами по банк-клиенту, она просто отвела меня в ИТ отдел и отдала его мне на растерзание. Там мне с ярким пламенем в глазах рассказали про их уникальную систему. Клиент на FoxPro, работавший в dos-box'е, все распоряжения сгружал в папку в виде email, подтверждения операций также приходили обратно по email. Далее в работу вступал замечательный почтовый клиент The Bat!, который требовалось запустить, потом импортировать в него сгенерированную банк-клиентом почту, отправить ее, дождаться ответной почты, экспортировать ее в папку банк-клиента и выполнить синхронизацию в последнем, чтобы увидеть, что же там в итоге получилось. Оценив невероятный успех коллектива, я задал всего два вопроса: "Что за х@#я?" и "Где нормальный веб-клиент?" Если бы у меня была с собой хотя бы отвертка, я бы высек ответ в гранитном полу прямо у них в ИТ-отделе. Потому что поучительным тоном бородатый начальник сообщил мне: "Молодой человек, если бы вы хоть немного бы разбирались в теме, то вы бы знали, что страницы в интернете не позволяют записывать данные". 2006-й год :shock:

В общем блестящий пример, как один страшный порок рождает другой, еще более страшный, асболютно незаметно для жертвы :lol:

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

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

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

Содержательных аргументов, нет один художественный свист. Ну и психоанализ личности оппонетна - вообще классика форумной демагогии.   Так что без комментариев, нечего комментировать.

[avp]

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

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

Детские ошибки в Си легко отлавливаются различными рантайм чекерами. В совокупности со статическими верификаторами и полноценным тестированием это даст высокую надёжность.

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

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

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

Кстати да. Я несколько лет назад писал статью как раз про эти самые анализаторы кода, и тогда пришел к выводу что их огромное количество в случае Си и C++ вызвано слишком большой вольностью в языке, вкупе с низкой выразительностью языка.
Причем для С/C++ есть крайне неприятный момент, что для него например невозможно сделать программу автоматической проверки соответствия стандартам кодирования без привлечения ИИ или ручного труда.
Я не говорю что это проблема только С/С++, но для них это проблема вселенского масштаба ввиду колоссальных объемов готового кода.

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

[avp]

Вообще-то это делается еще на этапе создания/наполнения оптимизатора в компиляторе. Как пример могу привести реализацию циклического сдвига на Си для 1 байтного числа которую компиляция очень часто приведет к одной/двум(зависит от камня) процессорным командам с использованием бита переноса.

Код Выделить Развернуть


// циклический сдвиг влево движок форума не пропустил :roll:
x=((x >> 1)  |  (x << 7)); // циклический сдвиг вправо


Причём тут оптимизатор? Речь о том что языковые средства ЯВУ не позволяют легко контролировать флаги как у процессора так и у сопроцессора. Простая задача сложить два числа и в случае переполнения что то сделать превращается в хакерский трюк вместо простого jo на ассемблере.

По моему опыту - с некоторого размера нет! Начинаешь терять суть кода в отдельных кусках. Приходится урезать самому себе набор доступных "хаккерских" приемов т.к. "спецэффекты" вылазят полным ходом в самых разных местах.

А никто и не говорил что будет легко. Стоимость кода для КА на порядок или даже на два и так будет дороже обычного коммерческого кода.

Могу ограничить объем Асм-кода для одного высококлассного разработчика примерно 40-60кБ (правда туда можно засунуть всю логику работы ФГ ) - дальше время получения надежного кода улетает за десятки лет разработки.

Всю программу действительно нет смысла делать на асме. Высокоуровневую логику, склеивающую функционал, можно сделать на ЯВУ. На асме вполне можно написать расчётные чистые функции и IO.

Особенно для малых контоллеров асм всё ещё применяется. Перед глазами вижу пример какк делают прошивку для блока питания.