На АЭС важна высокая надёжность программ.
На ассемблере легче допустить ошибку, чем на ЯВУ. С другой стороны, протестировать компилятор ЯВУ тоже проблематично. Очевидно, что и АЛУ процессора фиг протестируешь (как известная ошибка FPU Пентиума). Следовательно, ЭВМ может играть лишь вспомогательную роль, или должна контролироваться автоматикой в любом случае. Следовательно, минусов использования ассемблера больше, чем плюсов =)
Кто какие аргументы или факты может привести? =)
P.S. Леонид, Константин, исправил
11 февраля 2010 в 22:04
Тогда, видимо, на уровне АЭС действительно использование ПЛИС более эффективно.
А замена горючего в АЭС все-таки производится. В реакторах РБМК – без остановки, по мере работы.
11 февраля 2010 в 22:03
"Существенно сложнее" – не думаю, что вообще какую-то серъёзную сложность несёт. Ведь сам подумай: если разумно организовать ядро и форму кирпичиков, то загрузка-выгрузка может даже примитивным механизмом производиться =)
А вообще, на сколько мне известно, ядро собирают с топливом, когда он отрабатывает срок – разбирают. Да и надёжность там в любом случае столь высокая не требуется, как при работе.
Надо тоже отсечь случаи, которые не требуют высокой надёжности.
Управление стержнями – тривиально, единственная обратная связь видится…?
Аварийные стержни – параллельный автомат.
Что там ещё есть?
11 февраля 2010 в 22:02
А если сложнее ничего нет, то и нет преодоления порога сложности микропроцессора.
По поводу языков – никто и не говорил, что они примитивные, я же в скобках написал, о какой сложности идёт речь… вполне себе функциональные языки (читать: с наличием функций), ничем особо от других языков не отличаются. Ну разве что являются в большей степени декларативными – то есть даже более простыми, чем Фортран =)
По поводу синхронизации – в железе она выполняется гораздо проще, т.к. каждая частичка работает асинхронно. В железе применяются несколько иные методы "синхронизации" – подробнее можно посмотреть в сторону ТАУ, где рассмотрены вопросы организации систем управления и их составные блоки, а также СМО, где собственно речь идёт не столько о синхронизации, сколько о всеобщем взаимодействии, если так можно выразится….
Как считаешь?
11 февраля 2010 в 22:02
О да, я ещё SystemC забыл – хотя он применяется для иных целей, но можно на нём и ПЛИС программить, пожалуй =)
Это я к тому, что не VHDLом единым живы ПЛИС – там языков как грязи, щас я уже не помню их названий даже. VHDL самый распространённый просто.
А ещё есть штуки типа Симулинка – которых для "обычных" прог вообще нет. Ну это всё в сторону ТАУ и СМО катится. Конечно, данные теории и для программ применимы, но вот только программы многократно сложнее выходят и для них не делают подобных простых средств – неэффективно. Как пример – UML =)))) А для аппаратуры – запросто, см. Симулинк.
11 февраля 2010 в 22:02
А управление регулировочными стержнями выполняется тривиально?
Более сложное? Управление системой загрузки-выгрузки ядерного горючего, вероятно, существенно сложнее – если это не перекладывается на операторов.
11 февраля 2010 в 22:01
Хорошо, уточняю вопрос: речь идёт о простой автоматике, например, вброс аварийных стержней. Или управление регулировочными стержнями.
Что на АЭС есть более сложное?
11 февраля 2010 в 21:02
Но и на микроконтроллере реализация процесса реального времени не требует операционной системы. Более того, операционные системы реального времени тоже используют достаточно минималистические интерфейсы.
Что же до уровня языков программирования… Поглядел примеры на VHDL. Знаете, я бы не сказал, чтобы это был примитивный язык. Признаться, я плохо знаком с программированием ПЛИС. Насколько позволяют такие языки абстрагироваться от низкоуровневых вопросов? Разве там не требуется думать о той же синхронизации, особенно с учетом параллельности процессов в разных цепочках? Насколько удобно там работать с последовательной логикой, а особенно при необходимости проведения достаточно сложных вычислений?
На самом деле, удачным компромиссом мне кажется использование достаточно большой ПЛИС и процессорного ядра на ней. Это позволит аварийную и прочую простую логику реализовывать на уровне ПЛИС, а вычислительную часть, если она нужна – на уровне контроллера.
11 февраля 2010 в 20:00
#47 Для разработки ПЛИС используются ЯВУ, низкоуровневых языков я, например, не знаю =) Для ПЛИС, похоже, их и не существовало никогда? Т.е. твоя гипотеза ошибочна. Скорее даже наоборот. Сложность языка Си выше сложности VHDL (один из ЯВУ ПЛИС), который примитивен (по сложности использования =) примерно как Фортран. Т.е. даже программировать там проще.
Также соль в том, что на ПЛИС реализация "процеса реального времени" не требует никакой операционной системы. Также, как и "доступ к портам ввода-вывода" и т.п.
Да, я тоже считаю основным фактором ошибки разработки. "Человеческий фактор". Однако, общение с интерфейсами ОС много сложнее обхождения без оных – как указывал Дейкстра, человек не может следить за более чем одним процессом. В автоматике так и будет, а в программировании надо думать о синхронизации, например.
Вообще, предлагаю рассуждать не в терминах "что сужществует", а в терминах "что теоретически надёжнее". Т.е. теоретически – что использовать надёжнее =) К практике перейти всегда успеем, это не так интересно.
Последний фактор – вообще ни о чём =) Разработчиков ПЛИС чуть ли не больше, чем программистов =) Просто ты с этим не сталкивался, наверное. Ну, скажем, сколько человек обучаются у вас в вузе по специальностям ПОВТАС и ВМКСС? А ведь кроме ВМКСС ещё куче инженеров дают "микроэлектронику" (не хуже программирования).
Кроме того, откинув малозначащее вузовское образование, можете пошерстить по радиоэлектронным форумам – они покрупнее rsdn будут =) Вообщем, это не проблема. Да и не цель создания темы =)
11 февраля 2010 в 19:05
#45 быть может, и хотел, но сравни с тем, что сказал Денис =) Он изложил всё ясно и понятно одной фразой – "сложность автомата может присвысить сложность ЭВМ+ПО" =) У тебя такой цепочки не наблюдается, ты вроде как говорил о различиях элементной базе, о более качественных компонентах для ЭВМ и т.п. Это таки разные вещи, признай =)
11 февраля 2010 в 0:00
как бе хочется отметить, что модуль 4 кбайт ОЗУ весит несколько десятков кг…. там пеньков нету…какая ява???!О_о
10 февраля 2010 в 23:02
Второй вопрос – выбор между ассемблером и языком высокого уровня. Заметим, что и сам язык C появился как переносимая замена для ассемблера. Он позволяет не только абстрагироваться от деталей используемой платформы, но и добавить еще один уровень проверки кода. Он вносит типы переменных, структуры, удобные для записи и чтения программистом управляющие структуры. Все это ценой небольшого уменьшения скорости и некоторого риска получить ошибку от компилятора. Как правило, использование языка высокого уровня окупится.
И здесь возникает еще одна деталь, на которую хотелось бы обратить внимание. При современных системах – микро-ЭВМ, ПЛИС, компиляторах – как соотносятся риск ошибки, внесенной базой, и ошибки на уровне программы (или схемы в случае ПЛИС)? Поскольку если основную роль играют ошибки разработчика, а не среды разработки или элементной базы, то мы смотрим вообще не туда. В этом случае основными факторами, влияющими на надежность, будут уже не сложность ПЛИС и микро-ЭВМ, а сложность языков и сред разработки, сложность используемых систем с точки зрения разработчика.
Кстати, у меня такое впечатление, что для разработки ПЛИС используются в основном низкоуровневые языки. И если это так, то возникает серьезное сомнение в том, что надежность ПЛИС выше – именно за счет потери тех плюсов, которые дают языки высокого уровня.
И последний пункт, который мы пока что игнорировали и вряд ли сможем оценить – доступность кадров. Мы все-таки живем не в идеальной стране. С одной стороны, в нашей стране сейчас программистов и "вроде бы программистов" несколько больше, нежели разработчиков ПЛИС и железа. С другой стороны, разработчики железа, вероятно, в среднем более квалифицированные. Но и стоят они больше. Я не возьмусь сказать, как эти факторы повлияют на уровень продукции в условиях российского рынка. Скорее всего, они делают сравнение надежности разных схем просто бесполезным, так как ключевым фактором становится политика данной конкретой фирмы в найме персонала.
10 февраля 2010 в 22:05
Я написал, что примеры можно в принципе привести, а не что я готов их привести
На самом деле, у меня напрашивается аналогия с более привычным мне вопросом создания оконного интерфейса. Его можно делать визуальным компоновщиком, генерирующим не всегда известно, что, а можно писать вручную. Так вот тут я сторонник написания вручную, потому, что этот код более предсказуем, лучше изучен и прочее. Хотя визуальное программирование тоже имеет свои преимущества.
10 февраля 2010 в 22:04
> Так что на тему автомат против ЭВМ можно далее рассуждать только в цифрах, качественного решения здесь нет.
Именно это я и хотел сказать в сообщениях 24, 27.
Про элементную базу я ничего конкретного и не говорил, я лишь приводил простые примеры.
10 февраля 2010 в 22:03
#40 Потому мы и берём одинаковую элементныю базу – читай, одинаковые по надёжности транзисторы, чтобы была возможность решить задачу качественно. Иначе нам придётся всё это вычислять, да и всегда найдётся такой процессор, в котормо транзисторы будут ненадёжнее, чем в ПЛИС =) Вообщем, подход с рассмотрением различной элементной базы – путь в никуда. ну или предложи, к чему мы должны придти в результате? ЭВМ на реле, как я посмотрю, ты исключил… А хорошо бы было тебе почитать историю и выяснить количество простоев даже не электронно-механических, а ламповых эвм =) Сразу бы понял, что такое сложность ЭВМ супротив сложности автомата на двух деталях =)))
А если сравнивать процессор, собранный на "рассыпухе"? Факт, процессор будет много сложнее =) Только потому, что у него блоков больше. Впрочем, это вопрос спорный и количественного решения, как мы выяснили, не имеет (см. выше – ответ Дениса).
Так что не тему автомат против ЭВМ можно далее рассуждать только в цифрах, качественного решения здесь нет.
P.S. Но с элементной базой ты всё-таки сильно ошибаешься – ЭВМ не обязана быть однокристальной, может быть и механической, а автоматика это не всегда реле – может быть и единственная микросхема (пример – ПЛИС, или полузаказная).
10 февраля 2010 в 22:03
Еще раз повторюсь, что отвлекаясь от высоких материй и теорий, с житейской точки зрения, лифты на микроконтроллерах меня смущают. В сравнении с лифтами на реле с элементарными взаимоблокировками
По поводу ЯВУ против ассемблера: мне кажется, что вопрос либо риторический, либо опять нужен расчет для конкретного случая. Примеры можно привести в подтверждение обоих точек зрения.
10 февраля 2010 в 22:03
Александр, приведи пример в пользу ассемблера?
10 февраля 2010 в 22:02
А вот тут и вопрос. Кто сказал, что элементная база удельно (на один транзистор) одинаково надежна? Я могу предположить, что надежность "маленькой" логической микросхемы и "большего" процессора могут быть близкими. То есть "фишка" в том, что процессор хоть и сложный, но единый, неделимый и хорошо отлаженный. Или я не прав?
Другими словами, если для управления станцией сделать специальный однокристальный чип с количеством элементов много меньшим, чем в процессоре, то он будет надежнее процессора (если сделан по той же технологии). Но если сравнивать процессор и кучу стандартных логических микросхем, соединенных на печатной плате для того, чтобы реализовать требуемый алгоритм, то не факт, что процессор будет менее надежен.
Другими словами, в этих двух случаях элементная база – разная: один процессор или много микросхем/транзисторов.
10 февраля 2010 в 22:02
#38 Вполне обосновано. Похоже, нам придётся от качественных сравнений перейти к количественным и рассчитать надёжность ЭВМ и автомата для выполнения одинаковых целей. Для этого нужна исходная информация – во сколько раз блоки эвм будут более надёжными? И сколько блоков будет в эвм против автомата?
Всё же по первой части приведу несколько контраргументов.
Как, например, быть с известной ошибкой в FPU Pentium – вроде бы тестили-перетестили там всё?….
До кучи, если мы реализуем автомат из стандартных блоков – например, из есдинственной ПЛИС, то аппаратура по надёжности не уступает ЭВМ, т.к. структура ЭВМ явно сложнее структуры ПЛИС, да и ПЛИС проверена бОльшим числом пользователей.
Самая большая мера ненадёжности будет, и в том, и вдругом случае, при изготовлении логики (бизнес-логики). Т.к. она в единичном(ых) экземпляре, для нашей АЭС.
В случае с ЭВМ и автомата – каково количество логических блоков (программы и автомата соответственно)? Явно для программы их поболе – например, подсистема ввода-вывода, подсистема управления процессами, подсистема реального времени – целая ОС (пусть, как ты пишешь, хорошо протестированная, но, тем не менее, она есть и вносит ошибки). В случае автомата ничего такого не треба.
Т.е. логика автомата многократно проще логики программы. Итого:
ЭВМ = аппаратура (проц, память, сист. логика) + ОС + логика
Автомат = аппаратура (ПЛИС) + логика
Где компонент меньше? Какие из них стабильнее? Понятно, что аппаратура везде "протестирована", но как не тестируй – более сложное скорее выходит из строя. да и протестировать сложную микроэвм проблематичнее простой ПЛИС. ОС в ПЛИС вообще отсутствует, в ЭВМ она хоть и протестирована, но продолжает являться источником сбоев.
В итоге оба фактора – и аппаратная надёжность, и надёжность логики у автомата будут выше, т.к. они существенно проще. Логика у обоих уникальна, а аппаратура (хорошо, в ЭВМ туда включаем и ОС) проверена и там и там многократно и стандартизирована =)
Конечно, как справедливо замечено, будет какой-то момент, когда сложность автомата привысит сложность ЭВМ. В этот момент будет выгоднее использовать ЭВМ.
С другой стороны, используя принцип "не клади все яйца в одну корзину", можно никогда такого уровня не достичь – если можно обойти использование "центральнйо" эвм – то автоматика явно выгоднее, т.к. проще (конечно, если каждый канал управления не сложен =)
Как именно решить проблему количественно – сказать можно только на основе расчётов, расчитав надёжность отдельно для эвм и отдельно для автомата, затем сравнив. Простого качественного решения здесь, видимо, нет.
===
Так что, думаю, вопрос "ЭВМ против автомата" можно закрывать – универсального ответа нет. Спасибо Денису – на каком-то уровне сложности эвм может оказаться надёжнее автоматики. Но для каждого случая этот порог необходимо расчитывать.
Ещё мнения? Плюс, открыт вопрос "ЯВУ против ассемблера" =)))
10 февраля 2010 в 22:00
#37 Мыслишь ты всё верно, но упускаешь что при одинаковой надёжности элементной базы более сложная система будет менее надёжной. Из-за большего количества элементов, их связей. Это как бы и есть суть теории надёжности. Для наших целей это постулат =) Ну, так понятно?
10 февраля 2010 в 21:03
Хорошо, я постараюсь пояснить свою точку зрения.
При сравнении автоматики и ЭВМ следует учесть, что аппаратные блоки ЭВМ стандартны, широко используются и столь же широко тестируются. В случае же автоматики интегральная схема должна разрабатываться для каждого класса устройств заново. Так где разрабатывается больше компонент?
Кроме того, автоматика в "несколько реле" вряд ли достаточна для управления сложной системой. На уровне "несколько реле" это или аварийная автоматика, или управление достаточно простой системой. Не окажется ли, что с ростом сложности контролируемой системы вероятность отказа автоматики растет быстрее, чем ЭВМ, и вскоре ее перерастает?
Фактически, использование ЭВМ позволяет ценой появления лишнего источника ошибок купить дополнительный уровень абстракции – переход от разработки на уровне схемотехники к разработке на уровне программы. Абстрагироваться от времени прохождения сигналов, интерференции, помех, сдвиговых регистров и тайминга интерфейса. Разделить разработку системы на разработку ЭВМ, которая выполняется раз и служит многим проектам, разработку интерфейсной части, которая не включает в себя логику работы системы, и разработку программы, которая реализует логику и только логику. Каждый из этих модулей разрабатывается и тестируется, в общем, независимо от других.
В простейших случаях такое разделение не окупится. Но с ростом сложности системы сложность автоматики, объединяющей в себе все три роли, вероятно, растет быстрее, чем сложности отдельных компонент. На каком уровне переход от автоматики к микро-ЭВМ становится оправдан, на ваш взгляд?
10 февраля 2010 в 21:00
Собственно, моя точка зрения и заключалась в том, что надежность нужно рассчитывать. С теорией надежности, впрочем, я не знаком. Я считаю, что итоговый результат зависит не только от качественной ситуации (простая/сложная система), но и от количественной, то есть конкретных величин надежности исходных компонентов и проектирования. Из того, что было написано, я подумал, что то, что сложная система всегда менее надежна, чем простая – это постулируется. С этим я не согласился и привел примеры старых и современных компьютеров. Может быть, я неправильно понимаю понятие надежности? Вероятность отказа в единицу времени, что-то такое. (Ну то есть обратная величина, конечно).
10 февраля 2010 в 20:04
#31 прочитай пост #22, а то забаню.
10 февраля 2010 в 20:04
#33 это не наша тема, читайте теорию надёжности – одна из схем, например, мажорирование
10 февраля 2010 в 20:04
#32 В реальной жизни мы ничего такого не наблюдаем. В реальной жизни всё полностью соответсвует теории надёжности =)
Дискуссия к "личному" спору сводится всегда – это же форум =) Выпендрёж – это что?
Я предлагаю Вам или высказать свою точку зрения (пока она расплывчата), или согласиться с высказанной мной.
10 февраля 2010 в 20:03
> работает 3 компа, они делают одно и то же.
Вот тут меня всегда интересовал блок сравнения результатов вычисления разных компов, который принимает решение. Он один? Или тут тоже делается резервирование?
Интересно, как это обычно реализовывают.
10 февраля 2010 в 20:02
ну ващет там к примеру работает 3 компа, они делают одно и то же. результаты сравнивают, если все одинаково то норм, иначе либо тревога, либо 1 из 3 отрубается. как то так. у нас была лекция на эту тему, но тк мне не интересно я не особо вникал… и вроде данные со всех АЭС стекаются в единый центр. поэтому если будет что-то, об этом тут же узнает и москва , и другие страны…
10 февраля 2010 в 20:02
Ну ладно
Я основывался на следующем утверждении:
Допустим, надежность элемента процессора "мала". Следовательно и надежность всего процессора "мала" ("еще меньше"). Но т.к. в реальной жизни мы наблюдаем, что надежность процессора "больше" ("больше, чем мала"), исходное утверждение было неверно.
Не хочу спорить потому, что дискуссия, как мне кажется, ушла от темы, и перешла к нашему личному спору, и, уж извините, [взаимному] выпендрежу.
10 февраля 2010 в 20:01
> Плюс, Вы очень настойчиво игнорируете второй фактор – ошибки проектирования. Которые для сложной системы будут многократно больше.
С этим не спорю. Это нужно учесть. Но все равно я на практике наблюдаю также и надежные сложные системы, которые сложнее проектировать и ненадежные простые системы, которые проще проектировать
Ладно, выходит и правда софистика. Не хочу спорить.
Но я не понял, что вы пишите про мои выводы и следствия. Высокая надежность компонентов процессора – это необходимое условие его надежности, про достаточность я ничего не говорил.
10 февраля 2010 в 20:01
нет ничего практичнее хорошей теории =) "Не хочу спорить" – это ненаучно.
Вы изначально не указали на "недостаточность" =)
10 февраля 2010 в 19:04
Логика такова – мы абстрагируемся от низкоуровневой реализации, сравниваем подходы к проектированию логики (бизнес-логики), а не подходы к проектированию реализации этой самой логики. Почему? Моя фраза "Автоматика тоже может быть построена на интегральных схемах" подразумевает, что надёжность единичного элемента, физической реализации (транзистор или ещё что – не суть) может быть одинакова для ЭВМ и автоматики. ЭВМ тоже на реле бывают, да-да.
В результате первый фактор при одинаковой физической конструкции – сложность системы – в ЭВМ приводит к повышению вероятности сбоя.
Вообще, Вы имеете ряд чисто логических ошибок, переходите на софистику. Например, речь не о том, что "В целом же процессор – штука достаточно надежная, следовательно каждый его компонент – еще надежнее". Речь о том, надёжнее ли ЭВМ чем автоматика. Речь идёт о сравнении, а не только об ЭВМ. И мне видится, что такие фразы (включая "Если бы это было не так, то ничего бы и не работало") нарушают один из принципов логики – истинность следствия не означает истинность посыла (импликация). Поэтому вместо первой фразы правильнее использовать именно обратное рассуждение, иначе рискуете получить ложную причину, запутать и себя, и меня и наших читателей.
Плюс, Вы очень настойчиво игнорируете второй фактор – ошибки проектирования. Которые для сложной системы будут многократно больше.
Теперь понятно, что я имел в виду? Или надо прояснять дальше? Что конкретно непонятно? С чем не согласны?
10 февраля 2010 в 19:01
> … Тех же транзисторов в ЭВМ больше, чем в блоке автоматики …
Меня вновь смущают ваша логика. Я не спорю, что автоматика может быть надежнее, и она предпочтительна для важных систем.
Но то, что вы пишете о сравнении надежности по количеству компонеентов зависит от конкретных величин надежности (вероятности отказа). Например, простая схема, собранная на нескольких транзисторах, может быть менее надежной, чем процессор, содержащий миллионы компонентов. А может быть и наоборот. Утрированный пример – старые ЭВМ, которые содержали меньше логических компонентов, чем современные, но из-за технологии изготовления (шкафы с платами и разъемами и пр.) были значительно менее надежными. Таким образом, система, состоящая из большего числа компонентов, может быть и надежнее системы из меньшего числа элементов, так быть менее надежной.
10 февраля 2010 в 18:05
#24 Иногда лучше промолчать, если нечего сказать =)
Автоматика тоже может быть построена на интегральных схемах. Речь в моём посте о том, что вероятность ошибки тем больше, чем больше компонетов. Тех же транзисторов в ЭВМ больше, чем в блоке автоматики. А в ЭВМ и по блокам больше компонент (если отбросить транзисторы, вероятность выхода которых ничтожна – но не 0!), следовательно, ошибку проектирования допустить легче – это и будет в результате сбоем. Так понятнее?
#25 Наш мир вообще не идеален… Но в программировании он максимально приближается к идеальному – математическому миру. А вероятность того, что процесс просто умрёт не может быть нулевой – ещё Тьюринг установил, что невозможно определить конечность алгоритма =) Т.е. даже в идеальном мире программа – ненадёжная штука =)
P.S. Я имел в виду, что мы априори не можем сказать, что вероятность смерти процесса нулевая, т.е. не можем это доказать. В результате мы никогда не сможем создать гарантированно надёжную сколь-нибудь сложную систему.
Из-за того, что автоматика проще (см. пост про кол-во блоков и уровней организации ЭВМ), мы с большей уверенностью можем показать её надёжность.
10 февраля 2010 в 18:04
а какая реальная вероятность того, что процесс ПРОСТО УМРЕТ
поясняю. есть идеальная среда: идеальный комп, идеальный человек, написавший идеальную программу на асме(пусть будет идеальный язык).
идеальную программу запустили на идеальном языке.
пусть это будет вечный цикл, регулирующий что-то там.
какова вероятность, что он просто 1 раз не выполнится?
ну существует же, согласно уравнению Шреддингера, вероятность прохождения руки сквозь стену.
10 февраля 2010 в 18:03
> вероятность отказа (сбоя) суть произведение вероятностей отказа (сбоя) компонентов. В ЭВМ компонентов явно много больше, плюс, каждый компонент сложнее.
Это все так, но тем не менее, реальная вероятность сбоя "одного транзистора" в процессоре крайне мала. Если бы это было не так, то ничего бы и не работало. В целом же процессор – штука достаточно надежная, следовательно каждый его компонент – еще надежнее. Так что из того, что в процессоре "много транзисторов" еще не следует никакой вывод о его надежности.
10 февраля 2010 в 18:02
#5 Конечно, автоматика надёжнее ЭВМ. Это выходит из того, что вероятность отказа (сбоя) суть произведение вероятностей отказа (сбоя) компонентов. В ЭВМ компонентов явно много больше, плюс, каждый компонент сложнее.
Например, автоматика – несколько реле. ЭВМ – процессор (сюда включаем АЛУ, блок регистров, дешифратор и т.п.), память, системная логика, программа (которая тоже из компонентов, сюда и компилятор – даже в компиляторах ассемблера вероятность сбоя не 0).
Контраргументы?
10 февраля 2010 в 18:02
#4 Мой (а, точнее, признаный официальной наукой =) аргумент против ассемблера – отсутствие типизации (на асме организовать её невозможно, повышает вероятность спутать переменные). Отсутствие функций (их приходится организовывать вручную, повышает вероятность запороть стек, неправильно передать параметры и т.п.). Больший объём кода (повышает вероятность опечатки). Могу ещё чё-нить придумать.
Контраргументы?
10 февраля 2010 в 18:02
#7 И всем кто пишет о дублировании. Речь не об этом, т.к. дублирование применимо и к автоматике. Предлагаю обсуждать сабж, а не посторонние темы =)
10 февраля 2010 в 18:02
#13 Это да, теперь я тебя понял – оптимизирующий компилятор оптимальнее распределяет ресурсы процессора. Например, исключая лишние обращения к памяти благодаря "дальновидному" распределению ресурсов. Человеку это сделать проблематично, т.к. надо иметь трейсы в виде графов и их оптимизировать =) Решать всякие штуки типа задачи коммивояжера =)))
Раньше (да и сейчас наверняка такие есть =) компиляторы очень плохо эту работу делали – часто код получался гораздо менее оптимальным, чем у человека. Например, borland 3.1 частенько любил по нескольку раз загружать регистр, даже если там уже было нужное значение =))) Сейчас в большинстве случаев компилятор пишет качественный код… Хотя, конечно, всякие тонкости типа конвееров процессора, пожалуй, фиг где учитываются… Так что не всегда твоё утверждение верно =) Верен лишь принцип, что всегда можно написать такой компилятор, который будет в среднем оптимальнее человека =) Т.к. человеку свойственно ошибаться, а компилятору – не свойственно =))))
10 февраля 2010 в 16:04
Нет. В его конструкции, которая допускала работу при недопустимых вибрациях (датчики вибрации не были подключены к система аварийного останова; система контроля вообще недостаточно резервирована, защищена от той же воды и прочее). А также в халатности персонала, который знал о вибрации, значительно превышающей норму, но не остановил эксплуатацию этого блока.
10 февраля 2010 в 16:03
Тут беда была в давности сабжа, нет разве)?
10 февраля 2010 в 16:00
А вот на Саяно-Шушинской ГЭС вся электроника была исправна, но о разрушении генератора она не подозревала, пока ее саму не затопило.
Правда тут беда как раз в проектировании.
10 февраля 2010 в 12:04
на атомках сейчас все полностью на автоматике и централизовано. на любой станции туева хуча датчиков, в тч температуры и радиации, вся инфа кроме самой станции сливаается в реальном времени в центральный сервер, принадлежит он (центр) сразу нескольким странам, где работает туева куча спецов из разных стран. сделали это очень давно, через несколько лет после катастрофы в чернобыле. и да, там несколько дублирующих компов , с по от разных контор.в общем , чтобы произошла авария по вине автоматики или человека, нужно расхерачить сразу несколько пультов, которые находятся далеко друг от друга…
10 февраля 2010 в 10:05
> А механизм поднятия-опускания лопатки, конечно, не ломается?
Все ломается. Но данная механика более очевидна. Она проще устроена на несколько порядков, и поэтому в ней меньше подводных камней, неучтенных ситуаций, и прочего.
Кроме того, механика в нештатных ситуациях ведет себя более логично логично, а компьютеры могут выдать что угодно. Я про неисправности. Допустим, лопатка неисправна, и стала торчать выше, чем надо. Ну снесет ее поезд, и ладно. А теперь компьютер. Случилось в нем переполнение, скажем, одного байта за 127, и стало вдруг -128. Это качественно изменит все, и может выйти полный хаос.
10 февраля 2010 в 9:02
зря вы так про автоматику, где-то был даже механический компьютер – без единой электронной детали.
И кстати сказать, возможности механики, гораздо больше, чем их используют, и если бы компы возникли позже, очень многие вещи на которые сейчас ставят компутерное управление былибы механическими, что бывает и надёжнее.
Так что механической автоматикой можно сделать вообще всё, но многое из этого будет стоить, как переписать файерфокс на асм, и примерно столько же займёт времени.Но не неозможно.
10 февраля 2010 в 8:03
у меня друг на АЭС работает. инженером.
я не говорил "на чем писать ЛУЧШЕ", я сказал, на чем пишут, а поскольку у друга есть по работе друзья с другой АЭС и он сказал "ну все почти на асме пишут", то допустил "обычно".
достаточный аргумент?
вообще, я еще очень мал и очень глуп, но, как мне кажется, веселее писать на С. компилятор небольшой, а есть такие участки кода, которые быстрее на С, чем на асме.
10 февраля 2010 в 7:03
А механизм поднятия-опускания лопатки, конечно, не ломается?
9 февраля 2010 в 23:05
А, в этом смысле, согласен. Правда не все можно такой автоматикой продублировать.
9 февраля 2010 в 23:04
Вот в метро когда загорается красный, то около светофора внизу поднимается специальная лопатка. А у проезжающего поезда на этом месте тормозной клапан. Поезд даже при неисправности не может проехать на красный, потому, что у него сорвет тормозной клапан поднятой лопаткой.
9 февраля 2010 в 23:01
Автоматика не обязательно электронная, например, клапаны всякие закрыающиеся при повышенных давлениях итп
9 февраля 2010 в 22:05
Для АЭС пишутся программы с n (обычно n = 3) уровнями дублирования. Т.е. реализацию одной и той же фичи заказывают трем независимым конторам.
9 февраля 2010 в 22:05
> и в нем все зависит от программиста, на ЯВУ все зависит от компилятора,
И вы больше доверяете человеку? О_о
> Следовательно, ЭВМ может играть лишь вспомогательную роль, или должна контролироваться автоматикой
Не понял почему вы противопоставляете ЭВМ автоматике?
9 февраля 2010 в 22:04
Не доверяю лифтам на микроконтроллерах
9 февраля 2010 в 22:03
Константин Смотритель, а что, автоматика качественно лучше в плане безошибочности изготовления, тестирования и надежности?
9 февраля 2010 в 22:00
на ассемблере пишутся самые бысрыенадежные программы, дппустить на нем ошибку сложнее чем на ЯВУ, т.к. имеет ограниченнный (по сравнению с ЯВУ), и в нем все зависит от программиста, на ЯВУ все зависит от компилятора,
если предьявляются очень высокие требования к надежности, как вариант
- ставить взаимно дублирующие системы
9 февраля 2010 в 21:04
Причем тут атомные электростанции? о_О =))
9 февраля 2010 в 21:03
если не читать предыдущую тему, то непонятна связь с АЭС.
после исправления мой пост можно удалить