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

[Unispace]

34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:

Ну так в 1992-м году x286 и был почти пределом совершенства

А то! Но решались!

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

[belov2018]

Ни НПО Маш ни НПО Энергия на R-3000 под VxWorks в 1992-1993 г не решились. Мы все время опаздываем. А потом второпях запускаем через 20 лет.

[belov2018]

И совсем не с VxWorks

[Aleks1961]

Вадим Семенов пишет:
 

Aleks1961 пишет:
 

Вадим Семенов пишет:
 

bs пишет:
 

Дело не просто в надежности. Динамическая типизация ...
 Но я имел ввиду не принципиальную теоретическую невозможность, а лишь то, что все эти малополезные для ПО КА примочки скорее осложняют задачу.

Согласен - простота, это надежность и легкость в отработке! Лучше 100 простых алгоритмов, чем один монстр! :lol:

[Aleks1961]

34 задач, непрерывные, периодические и циклические. Решались чуть ли не на х286 процессоре :lol:

Ну так в 1992-м году x286 и был почти пределом совершенства

А то! Но решались!

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

Жесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:

[Unispace]

Жесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:

А что было после 1994 года ?

[Aleks1961]

Жесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:

А что было после 1994 года ?

Полное разделение РКОтраслей России и Украины, только КА Океан-О и остался :cry: Потом долгий путь к сотрудничеству..., но как было не вернуть, пока :cry:

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

Больше всего страдает надежность, поскольку в результате буйного преобразования типов получается неизвестно что. Скажем преобразование вещественного в целое дробная часть отбрасывается. Возможно, в данной задаче подобная потеря точности недопустима, но компилятор/интерпретатор этого не заметит.

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

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

А вот статическая проверка типов в этом плане иногда расслабляет - достаточно где-то выполнить ошибочное явное приведение типов, чтобы компилятор не ругался, и забыть о нем через пару часов.

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

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

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

Здесь не могу ничего сказать, так как нет опыта в работе с автоматическим управлением памятью в ОС РВ. Хотя очевидно, что в этом направлении работы тоже активно ведутся: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Real-time_garbage_collection

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

В общем же, ВМ не обязательно подразумевает автоматическое управление памятью.

Нк обязательно. И куча для даного рода задач не нужна. И даже стек не нужен и нежелателен. (возможно переполнение стека) Достаточно статического распределения памяти на этапе компиляции.

Основная задача, как мне кажется - это упростить реализацию защиты от серьезных непредвиденных ошибок за счет возможности контроллировать корректность каждой операции на уровне байт кода. Это не мешает реализовать неавтоматическое распределение памяти, если язык позволяет (например компилировать С/С++ в байт-код ВМ).

Мне байт-код представляется неактуальным. Байт-код это всего лишь еще один ассемблер (некоей виртуальной машины) в который генерит код компилятор. Ничего принципиального полезного он не добавляет. Байт-код и виртуальная машина нужны для портабельности уже скомпиленной программы. Но в данном случае это совершенно не актуально. Ну и С/C++ не самый лучший язык по причине весьма вольной работы с указателями.

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

Если там есть обмен сообщениями, то дедлоки могут быть. Задача А ожидает сообщения от задачи Б и засыпает. В это время задача Б начинает ждать сообщения от задачи А но никогда его не дождется. Понятно, что реальная цепочка может быть более чем из двух звеньев и весьма трудно обнаружима.

[bs]

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

Да да, когда-то настоящие разработчики, прокалывая перфокарты, смеялись над неразработчиками, вводящими шестнадцатеричные дампы.

Какой смысл доказывать, что можно все, что угодно разработать на ассемблере и запустить на 186-м? Это и ежу понятно, как и сопутствующая низкая эффективность, да и об этом ли речь на данный момент? Мы жестко отстаем по космическим программам и разработкам. При этом еще имеем копеечный бюджет. А хочется все сделать покруче и побыстрее.

Именно поэтому и начали появляться вопросы и идеи насчет более эффективных средств разработки. Что плохого в том, что современная аппаратная часть позволяет не считать циклы, а довериться работающему "как часы" планировщику? Какой смысл чахнуть годами над ассемблером, если можно получить качественную реализацию на С++ на порядок быстрее?

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

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

Жесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:

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

[Unispace]

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

Ээ, вы не так восприняли. Я не за ассемблер, а за разумное соответствие задачам инструментария. Меня никто не убедит, даже разработчики ФГ (хотя, надеюсь, и не стали бы), что там позарез нужна динамическая память, сборщики мусора, виртуальные машины и прочее. Я вообще удивляюсь, что тут так много этому уделяют внимания. Ощущение, что и на этом форуме сисадмины и кодировщики ширпотребконвейера от программистики занимают немалое место. Диалог между реальными инженерами-программистами-разработчиками протекал бы совсем по-иному. Оставляю себе право на ошибку

[Aleks1961]

Жесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:

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

Переход к решению следующей задачи если они не связанны, с записью в ТМИ о нерешенной. И на стенде будут знать что и как. От-латка продолжится! :lol:

[Дем]

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

Взаимодействие контроллеров всё-таки более предсказуемо по последствиям, чем взаимодействие находящихся в общей памяти программ.
А протоколы надо использовать стандартные и массово используемые (а следовательно вылизанные), чем изобретать велосипед непредсказуемой кривизны.

[Aleks1961]

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

Ээ, вы не так восприняли. Я не за ассемблер, а за разумное соответствие задачам инструментария. Меня никто не убедит, даже разработчики ФГ (хотя, надеюсь, и не стали бы), что там позарез нужна динамическая память, сборщики мусора, виртуальные машины и прочее. Я вообще удивляюсь, что тут так много этому уделяют внимания. Ощущение, что и на этом форуме сисадмины и кодировщики ширпотребконвейера от программистики занимают немалое место. Диалог между реальными инженерами-программистами-разработчиками протекал бы совсем по-иному. Оставляю себе право на ошибку

Ругаются на стенде, при анализе результатов, а до этого инженеры-программисты живут в другом мире! :shock:

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

Жесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:

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

Переход к решению следующей задачи если они не связанны, с записью в ТМИ о нерешенной. И на стенде будут знать что и как. От-латка продолжится! :lol:

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

[bs]

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

Золотые слова! Именно об этом я и говорю. Т.е. по факту даже при статической типизации нужны средства контроля (аудит, тестирование, и т.п.). Но тогда нет никакого выигрыша

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

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

Нк обязательно. И куча для даного рода задач не нужна. И даже стек не нужен и нежелателен. (возможно переполнение стека) Достаточно статического распределения памяти на этапе компиляции.

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

Байт-код и виртуальная машина нужны для портабельности уже скомпиленной программы.

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

Но в данном случае это совершенно не актуально. Ну и С/C++ не самый лучший язык по причине весьма вольной работы с указателями.

Что вольного в работе с указателями на С++? Ассемблер тогда вообще кошмар наяву

Если там есть обмен сообщениями, то дедлоки могут быть. Задача А ожидает сообщения от задачи Б и засыпает. В это время задача Б начинает ждать сообщения от задачи А но никогда его не дождется. Понятно, что реальная цепочка может быть более чем из двух звеньев и весьма трудно обнаружима.

Бесспорно, однако в этой модели потоки сообщений наглядны и позволяют выполнять детальный анализ, возможно даже формальный. Надо покопать.

[Aleks1961]

Жесткое и жестокое выделение памяти, ограничение циклов на решение задач и стенд, стенд и стенд с полетами в три смены! Правда до 1994 года :cry:

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

Переход к решению следующей задачи если они не связанны, с записью в ТМИ о нерешенной. И на стенде будут знать что и как. От-латка продолжится! :lol:

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

Редкое сочетание входных данных это случай! Но в другой ветке уже писал о фильтрации ИД при начале работы СПО, модулей и тд

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

Взять одну троированную ЦВМ

Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".

[Aleks1961]

Взять одну троированную ЦВМ

Про троированную ЦВМ было бы интересно почитать, например на ту которая на КК Союз применяется. Что там представляет одельный модуль и на каком уровне производится "голосование" со сравнением результатов. И что делает тот модуль, который в голосовании "остался в меньшинстве".

2 из 3 и третий не в счет, в этот раззз. По времени, величине и как в алгоритме :!: И так всегда :!: Третий лишний :!:

[Unispace]

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

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