Однако редкий трэш. Я про вот это: mov byte ptr [rsp - 16], 0
......
mov rcx, qword ptr [rsp - 16]
mov qword ptr [rsp - 16], rcx
......
test cl, cl
Объяснение по ссылке выглядит убедительным (хотя для меня не очень понятным, ну да ладно), однако вообще это выглядит как, скажем так, некий приговор, если не языку, то использованным идиомам. Меньше кортежей, меньше…
Вы не видите разницы между программной эмуляцией и исправлением непредсказуемых косяков железа с помощью программы, на этом же железе исполняемой?
Гм, вот что я точно не вижу, так это суть выражаемой в данном предложении мысли. Можете развернуть ее более понятно?
А вы тут пропагандируете новое слово в надёжности, когда исправляются непредсказуемые ошибки, нарушающие гарантии
Щито? Во-первых я тут пока ничего не пропагандировал, а во-вторых я похоже опять должен вас спросить — что вы имеете в виду, какие такие непредсказуемые ошибки?
Я уже устал отвечать на подобные размышлизмы. Знаю одно — я не хотел бы быть вашим коллегой.
Ну, при таком уровне аргументации я вас на работу и не возьму никогда.
А вы пробовали не спрашивать, а прочитать ветку, в которую постите? Вот прямо мой первый комментарий, там ясно написано:
Это я прочитал, но это касается только компилтайма. А вы там дальше уже про корректный враппер интов для рантайма пишете, и именно про него я спросил. То, что он также наследует желаемое вами поведение в компилтайме, я никак не оспариваю. Впрочем, поскольку обработка в рантайме в конечном итоге важнее всего, то в общем вариант с default все так же достаточен для решения основной задачи.
Вы тоже собираетесь исправлять аппаратные проблемы программой, которая на этой же аппаратуре исполняется?
Ну, вообще говоря отчасти это так и делается. Например если нет аппаратного скраббера, то делается программный, кроме того многие ошибки в аппаратуре только выставляются, но обрабатываются софтом.
Как верно выше заметили — безсбойной аппаратуры не бывает, но число и опасность сбоев можно сильно понизить за счет ряда решений, в основном аппаратных, но софт — тоже всегда часть этого решения.
Но вообще я другое хотел спросить. Вот вы выше привели пример, как бы вы использовали switch, в нем нет дефолта, да, но простите — в чем было бы отличие, если бы все-таки был default, в котором как раз было бы return {}?
Ну это все же выглядит как оправдание. Да, проблема в общем была в «прокладке между рулем сайдстиком и сиденьем», но будь у них тактильная обратная связь (необязательно прямая механическая), возможно они бы быстрее догадались.
Опять же, уход от классической «прямой» системы управления к Fly By Wire позволил существенно (чуть ли не на порядок) поднять безопасность полетов за счет наличия, скажем так, определенных «защит от дурака», они же protections. Говоря русским языком — самолет будет сопротивляться до последнего от того, чтобы его вогнали в планету. Это огромный плюс.
Не буду возражать, но насчет «на порядок» хотелось бы уточнений. Где есть такой анализ? И чтобы именно от ЭДСУ был профит, а не от прочих разных улучшений. Потому как в реале ЭДСУ и разных своих приколов добавляет, и это еще вопрос, нет ли там взаимной компенсации плюсов и минусов. Может такой анализ и есть, я в открытой печати не встречал…
В свое время читал статью, где было написано, что АБСУ-154 стала причиной (правда при неверной эксплуатации) чуть ли не пяти аварий (но без ссылок, так что может быть преувеличение), и при этом предотвратила порядка сотни разных «сложных ситуаций» (ну то есть не аварий, но чего-то такого опасного, и тоже хз откуда осетр), то есть оценивай как знаешь… Формально по статистике Ту-134 и Ту-154 были безопаснее, чем Ту-104 и Ил-18 например, но думается мне не из-за АБСУ.
Если же этого не сделать и попытаться одновременно управлять с правого и левого сайдстика, то самолет орет дурниной «DUAL INPUT»
Тем не менее минимум один самолет так упал… Имхую, что если бы там были штурвалы, то летчики бы раньше сообразили, что что-то пошло не так. Тем более что КВС пошел куда-то гулять и ВП вместе со стажером в его отсутствие не догадались нажать кнопку приоритета на одном из мест.
Именно — точнее и быстрее. Одна из ключевых вещей, которым теперь мало учат. Мне иногда приходится долго убеждать наших конструкторов и технологов сделать упор под кисть в зоне выполнения какой-то небольшой ручной операции на какой-нибудь технологической установке. Потому что работая всей рукой оператор будет работать дольше и накосячит больше.
Плюсую. Дело не в том, что указанные товарищи открыли всем глаза на проблему эргономики и вообще, это все было задолго до них известно. Просто они были одними из регулярно появлявшихся на исторической прямой «адвокатов человека». Оные были и в стрелковке, и в оружейном деле, и в атомпроме, и в индустрии ПК… И, да, пример с «Джоном Маккейном» тоже, в ту же кассу, и по тому же месту — о человеке подумали мало, хотя казалось бы предъявить разработчикам обвинение в невнимании к интерфейсам ни разу нельзя.
И да, «размером в кулак» вполне работает в смысле радиационной защиты. Возмущения от прилетевших частиц получаются просто ниже порога изменения состояния.
Теоретически да (хотя надо смотреть конкретные условия). Но на практике есть еще такой фактор, как много худшая устойчивость «кулачных» топонорм к TID.
Вот это как раз одно из популярных заблуждений в отношении современной микроэлектроники для космоса.
Не совпало — перезагружаем всё и пересчитываем, делов-то.
Надёжное — но медленное. А дальше пошли компромиссы, в тонкостях которых мне (и, боюсь, Вам тоже) уже не разобраться.
В тонкостях космических БЦВМ я конечно не разбираюсь, но если говорить о промышленных ЦВМ с повышенными требованиями к надежности и безопасности, то тут могу утверждать компетентно — метод «все остановить и перезагрузить» конечно рабочий и часто используется, но мягко говоря безыдеен и не имеет перспектив (и потому не ставится во главу угла в перспективных разработках). А в системах для маневренных транспортных систем и вовсе этот метод неприемлем.
Ну вы погодите атаковать, я же не говорю, что все космические БЦВМ должны использовать только такие процессоры и только такую архитектуру. Само собой все идет от задачи — в случае космических БЦВМ как минимум от типа миссии. Мне показалось, что выше мы обсуждали дублирование/троирование itself, без привязки к отрасли, так что дискуссия носит общий характер. А мои комментарии по конкретным приемам защиты идут от того, что мне более-менее близко, а именно от коммерчески доступных изделий для промышленности, не для космоса. Впрочем и в случае космоса яркий пример тех же самых приемов — упомянутый HPSC.
Ну нет, я же не говорю просто об одном дублированном процессоре вместо одного троированного. Речь об N дублированных процессоров с быстрым избыточным интерконнектом. Это то, что коммерчески востребовано в промышленности и в результате обеспечивает тот же уровень сбоеустойчивости, а также более высокий уровень живучести, чем один сильно избыточный процессор.
Во-первых, не надо путать отказо- и сбоеустойчивость. Это вообще разные вещи, с разными подходами к защите.
Да, конечно. Выше я написал все наоборот, следует везде читать «сбой» вместо «отказ».
Во-вторых, сбои тоже бывают разные, в памяти/триггерах и в логике. И в обоих случаях дублирование можно эффективно применять, если даунсайды вас устраивают.
Ну так я как раз и говорю о том, что DCLS вполне эффективен.
Но речь, разумеется, не идёт о том, чтобы просто поставить рядом два процессорных ядра
В рамках одного изделия конечно по меньшей мере нужен delayed lockstep и геометрические отличия, я о таких процессорах только и говорю.
Мда, кони и люди, галопом по Европам, и это на сайте, где вопрос тащемта уже неплохо раскрыт в последние пять лет. Разве что про HPSC едва ли не первое упоминание, и то какое-то куцее вышло (а проект интересный, заслуживает статьи на Хабре).
mov byte ptr [rsp - 16], 0......
mov rcx, qword ptr [rsp - 16]
mov qword ptr [rsp - 16], rcx
......
test cl, cl
Объяснение по ссылке выглядит убедительным (хотя для меня не очень понятным, ну да ладно), однако вообще это выглядит как, скажем так, некий приговор, если не языку, то использованным идиомам. Меньше кортежей, меньше…
Fixed.
Гм, вот что я точно не вижу, так это суть выражаемой в данном предложении мысли. Можете развернуть ее более понятно?
Щито? Во-первых я тут пока ничего не пропагандировал, а во-вторых я похоже опять должен вас спросить — что вы имеете в виду, какие такие непредсказуемые ошибки?
Ну, при таком уровне аргументации я вас на работу и не возьму никогда.
Это я прочитал, но это касается только компилтайма. А вы там дальше уже про корректный враппер интов для рантайма пишете, и именно про него я спросил. То, что он также наследует желаемое вами поведение в компилтайме, я никак не оспариваю. Впрочем, поскольку обработка в рантайме в конечном итоге важнее всего, то в общем вариант с default все так же достаточен для решения основной задачи.
Ну, вообще говоря отчасти это так и делается. Например если нет аппаратного скраббера, то делается программный, кроме того многие ошибки в аппаратуре только выставляются, но обрабатываются софтом.
Как верно выше заметили — безсбойной аппаратуры не бывает, но число и опасность сбоев можно сильно понизить за счет ряда решений, в основном аппаратных, но софт — тоже всегда часть этого решения.
Но вообще я другое хотел спросить. Вот вы выше привели пример, как бы вы использовали switch, в нем нет дефолта, да, но простите — в чем было бы отличие, если бы все-таки был default, в котором как раз было бы return {}?
рулемсайдстиком и сиденьем», но будь у них тактильная обратная связь (необязательно прямая механическая), возможно они бы быстрее догадались.Не буду возражать, но насчет «на порядок» хотелось бы уточнений. Где есть такой анализ? И чтобы именно от ЭДСУ был профит, а не от прочих разных улучшений. Потому как в реале ЭДСУ и разных своих приколов добавляет, и это еще вопрос, нет ли там взаимной компенсации плюсов и минусов. Может такой анализ и есть, я в открытой печати не встречал…
В свое время читал статью, где было написано, что АБСУ-154 стала причиной (правда при неверной эксплуатации) чуть ли не пяти аварий (но без ссылок, так что может быть преувеличение), и при этом предотвратила порядка сотни разных «сложных ситуаций» (ну то есть не аварий, но чего-то такого опасного, и тоже хз откуда осетр), то есть оценивай как знаешь… Формально по статистике Ту-134 и Ту-154 были безопаснее, чем Ту-104 и Ил-18 например, но думается мне не из-за АБСУ.
Тем не менее минимум один самолет так упал… Имхую, что если бы там были штурвалы, то летчики бы раньше сообразили, что что-то пошло не так. Тем более что КВС пошел куда-то гулять и ВП вместе со стажером в его отсутствие не догадались нажать кнопку приоритета на одном из мест.
Теоретически да (хотя надо смотреть конкретные условия). Но на практике есть еще такой фактор, как много худшая устойчивость «кулачных» топонорм к TID.
Вот это как раз одно из популярных заблуждений в отношении современной микроэлектроники для космоса.
В тонкостях космических БЦВМ я конечно не разбираюсь, но если говорить о промышленных ЦВМ с повышенными требованиями к надежности и безопасности, то тут могу утверждать компетентно — метод «все остановить и перезагрузить» конечно рабочий и часто используется, но мягко говоря безыдеен и не имеет перспектив (и потому не ставится во главу угла в перспективных разработках). А в системах для маневренных транспортных систем и вовсе этот метод неприемлем.
Да, конечно. Выше я написал все наоборот, следует везде читать «сбой» вместо «отказ».
Ну так я как раз и говорю о том, что DCLS вполне эффективен.
В рамках одного изделия конечно по меньшей мере нужен delayed lockstep и геометрические отличия, я о таких процессорах только и говорю.