Comments 25
Мда… и ЭТО даже не перевод.
Что-то я не понял: статья о программисте, который пишет на азме, а в итоге:
> Я по роду работы занимаюсь только языком C и C++. Сейчас есть потребность и желание детально погружаться в ассемблер, чем собственно и занимаюсь.
> Я по роду работы занимаюсь только языком C и C++. Сейчас есть потребность и желание детально погружаться в ассемблер, чем собственно и занимаюсь.
Интересные дела происходят: в промышленной автоматизации запрещено использовать языки низкого уровня, так как легко "выстрелить себе в ногу". Автор пишет о асме, говорит о том, какая разница с высокоуровневыми ЯП. Но, ведь все это исключительно из за отставания компонентной базы и общей консервативности отрасли. А в РКТ вообще жуть: результатом этого процесса явилось появление spacex, которых не тянет этот тяжёлый груз прошлого. Ждём в авиации аналогичного подхода: асм на свалку.
Вопрос, что в промиышленной автоматизации счиатать языками низкого и высокого уровня. Вот тот же IL никто не запрещает использовать и не заставляет кодить исключительно на Flowchart.
Дело даже не в вероятности прострелить себе ногу и не в сложности поддержки. Дело в доказывании безглючности компилятора. Траслятор ассемблера в машинные коды предельно тупой, и его корректная работа может быть доказана. А компилятор C может (и будет) иметь множество «недокументированных особенностей» даже с выключенными оптимизациями. Поэтому вычислительные ядра пишут на ассемблере, за неимением сертифицированных компиляторов с языков выского уровня для данного микроконтроллера, или же в связи с очено высокой их ценой. Всякую обвязку (вывод информации, логирование и пр.) наверняка пишут на языках выского уровня, да и реализовано оно не на микроконтроллерах.
«Но опять же — это вопрос к разработчикам системы MCAS для компании Boeing и Airbus.»
Простите, Airbus то здесь каким образом?
Повторюсь еще раз: учитывая многообразие отказов систем современных высокоавтоматизированных ВС с Fly-By-Wire, вопрос только в том, какой риск считать приемлимым при уходе от живых людей в контуре управления — это применительно к гражданской авиации, с военными и беспилотниками цифры будут совершенно другие. И еще раз повторюсь, автоматика и существенное повышение надежности агрегатов ВС позволило существенно уменьшить эти риски, но появились новые проблемы, требующие более глубокого знания и понимания логики работы систем, и более скажем так продуманных действий в аварийных ситуациях (и это не смотря на всякие ECAM, QRH, FCOM и.д.) Довольно часто несколько казалось бы совершенно независимых отказов могу дать дать что то новое (привет MELу).
Немного пруфоф и интересного чтива от Airbus здесь
Простите, Airbus то здесь каким образом?
Повторюсь еще раз: учитывая многообразие отказов систем современных высокоавтоматизированных ВС с Fly-By-Wire, вопрос только в том, какой риск считать приемлимым при уходе от живых людей в контуре управления — это применительно к гражданской авиации, с военными и беспилотниками цифры будут совершенно другие. И еще раз повторюсь, автоматика и существенное повышение надежности агрегатов ВС позволило существенно уменьшить эти риски, но появились новые проблемы, требующие более глубокого знания и понимания логики работы систем, и более скажем так продуманных действий в аварийных ситуациях (и это не смотря на всякие ECAM, QRH, FCOM и.д.) Довольно часто несколько казалось бы совершенно независимых отказов могу дать дать что то новое (привет MELу).
Немного пруфоф и интересного чтива от Airbus здесь
Традицыонный вопрос про вакансии.
Зелёные крокодилы, под куполом цирка. ©лошадь.
Для электрических схем есть всего две неисправности: обрыв, и кз. Обе проблемы возникают на проводниках, проводах, разъёмах, кабелях, и так далее. На всём том что нельзя резервировать, и должно выполняться монументально и максимально надёжно.
Хотя выход есть — распределённая сеть передачи данных.
Когда всё что могло уже сдохло — данные гоняются по вайфаю.
Для электрических схем есть всего две неисправности: обрыв, и кз. Обе проблемы возникают на проводниках, проводах, разъёмах, кабелях, и так далее. На всём том что нельзя резервировать, и должно выполняться монументально и максимально надёжно.
Хотя выход есть — распределённая сеть передачи данных.
Когда всё что могло уже сдохло — данные гоняются по вайфаю.
Интересно как менеджмент смотрит на разработку проекта целиком на ассемблере? Такой код очень сложно и дорого развивать и поддерживать в сколько-нибудь заметных промышленных масштабах. Спору нет, программистам очень интересно писать на ассемблере, а вот бизнесу может оказаться очень вредно.
Мы начале 90-х делали проект кассового аппарата с серьезными ограничениями по размеру ROM. Бодро добежали до 100К строчек ассемблера и усе, развитие просто остановилось — новые баги вылезали чаще чем фиксились старые. Людям сложно объяснить почему у них в фискальном отчете неожиданно вылезло пару миллионов продаж из-за не всегда корректного учета флага переноса. В итоге дешевле оказалось добавить ROM и таки перейти на Си. Сейчас там под миллион сишных строчек, на ассемблере написано менее процента (кусочек RTOS, кое-что из HAL и криптография для скорости), целиком на ассемблере это неописуемо (сказала собачка, глядя на баобаб).
Мы начале 90-х делали проект кассового аппарата с серьезными ограничениями по размеру ROM. Бодро добежали до 100К строчек ассемблера и усе, развитие просто остановилось — новые баги вылезали чаще чем фиксились старые. Людям сложно объяснить почему у них в фискальном отчете неожиданно вылезло пару миллионов продаж из-за не всегда корректного учета флага переноса. В итоге дешевле оказалось добавить ROM и таки перейти на Си. Сейчас там под миллион сишных строчек, на ассемблере написано менее процента (кусочек RTOS, кое-что из HAL и криптография для скорости), целиком на ассемблере это неописуемо (сказала собачка, глядя на баобаб).
UFO just landed and posted this here
В старые добрые времена, до суперскалярных процессоров, переписав грамотный сишный код на ассемблер можно было выиграть процентов 25-30 скорости и процентов 50 по размеру кода. Сейчас же глядя на CPI (clocks per instruction- 0.25 это отлично) в vTune для Xeon-а и оценивая порядок инструкций в листинге — понимаешь что на ассемблере такое на трезвую голову не напишешь. Там масса нюансов которые учитывает современный компилятор, включая учет ресурсов конвейеров и работу предсказателя ветвлений для конкретного семейства. И если не хватает 20-30 процентов скорости и надо писать на ассемблере — то это нормальный такой залет с выбором платформы.
Согласен с предыдущими ораторами и поддерживаю, что общее ощущение от статьи — люди отважно создают себе проблемы и потом со сладостью мазохиста их преодолевают.
"не можем себе позволить открытое ПО" — да вы что?? git вылизан раз в 100 лучше чем любой внутриведомственный аналог. Или даже в 102.
А байки и вынужденность ютиться в килобайты и целочисленные процессоры? Риали?? Вот прям самолёт не осилит взять на борт процессор(ы) от современного телефона? Ладно, его более простой и надёжный аналог, но все равно в тысячу (миллион?) раз более производительный.
Процентов на 99 уверен, что все дело в том, что в совке никому не надо ничего менять. Делали так 40 лет — и дальше так будем.
В общем, что-то не стыкуется у ответчика…
Если это оборонка, например, то можно долго развлекаться на государственные деньги. А вот если это бизнес, живущий с реальных продаж своих разработок — тогда ой, оно не выживет. Конкуренты поставят контроллер на доллар дороже и с дополнительным мегабайтом флеша, и на Си быстрее напишут, отладят и сертифицируют функционал и усе.
Среды разработки ПО, к примеру, Code Composer от Texas Instrumensts и не только, содержат внутри так называемые дизассемблеры, то есть это функционал, позволяющий посмотреть в процессе отладки кода на симуляцию его работы или через эмуляцию работы ПО непосредственно на целевом вычислителе, как и какие asm-команды сложения, пересылки, записи в аккумулятор, используются при выполнении той или иной команды или функции, написанной на языке высокого уровня.
Это мне уже пора уйти домой и поспать или тут всё же что-то не так?
И всетаки, когда автоматические системы управления полностью заменят и превзойдут людей, в кабину самолета всерано будут сажать человека в форме пилота и собаку. Зачем человека? — А потому что пассажирам так спокойнее, они уверены что если что то пойдет не так, пилот сможет всех спасти. Зачем собаку? — А чтобы кусала человека, если тот попытается управлять самолетом.
Жаль, что не написали название конторы, в которой трудится сей работник. Наверное — во избежание виртуальных спелых томатов, летящих в их сторону. НИИ АО или иная часть ОАКа? ;)
Минимум IIIC имеют очень мало самолетов и еще меньше аэропортов. Это жутко дорого — содержать на довольствии такую систему, сейчас весь мир плавно переходит на RNAV/GNSS-заходы.
Про память: мало того, что вся авиационная техника разрабатывается очень долго, а еще дольше — сертифицируется, и пока это происходит, она морально устаревает, и позавчерашнее «ДОФИГА ПАМЯТИ» завтра вдруг оказывается «ОЙ ЧЁ КАК МАЛО?!?», и все требуемые для выполнения полета навигационные объекты не вмещаются в маленькую старенькую микросхему.
Про документацию: у нас этим большой провал, некоторые документы RTCA/Eurocae худо-бедно перевели на русский и узаконили — типа сами разработали, но список стандартов мал, и документы почти не актуализируются :(
Минимум IIIC имеют очень мало самолетов и еще меньше аэропортов. Это жутко дорого — содержать на довольствии такую систему, сейчас весь мир плавно переходит на RNAV/GNSS-заходы.
Про память: мало того, что вся авиационная техника разрабатывается очень долго, а еще дольше — сертифицируется, и пока это происходит, она морально устаревает, и позавчерашнее «ДОФИГА ПАМЯТИ» завтра вдруг оказывается «ОЙ ЧЁ КАК МАЛО?!?», и все требуемые для выполнения полета навигационные объекты не вмещаются в маленькую старенькую микросхему.
Про документацию: у нас этим большой провал, некоторые документы RTCA/Eurocae худо-бедно перевели на русский и узаконили — типа сами разработали, но список стандартов мал, и документы почти не актуализируются :(
Что это было? (с)
По тексту сложилось впечатление, что опять DataArt лютует вместе с былинными дедами, но нет, это какой-то другой блог.
Точно можно сказать одно — да, здесь речь про российскую разработку.
По тексту сложилось впечатление, что опять DataArt лютует вместе с былинными дедами, но нет, это какой-то другой блог.
Точно можно сказать одно — да, здесь речь про российскую разработку.
Ухх, еле дочитал. Прямо кровь из глаз. Такое ощущение, что задачей человека, дающего интервью было сказать как можно больше непонятных слов, нагнать важности.
При этом, человеку, работающему в этой сфере видно столько ляпов, что создается ощущение будто интервью дает какой-то студент-практикант. В тексте явно прослеживается многократное повторение одного и того же.
Про git особенно порадовало.
Постоянное противопоставление разработчиков на ПК и МК наводит на мысль, что человек, дающий интервью никогда не писал для ПК. Ну или стояла задача показать, насколько все сложно и запутанно.
В общем, идея такого интервью может была и хорошая, но вот реализация…
При этом, человеку, работающему в этой сфере видно столько ляпов, что создается ощущение будто интервью дает какой-то студент-практикант. В тексте явно прослеживается многократное повторение одного и того же.
Про git особенно порадовало.
Постоянное противопоставление разработчиков на ПК и МК наводит на мысль, что человек, дающий интервью никогда не писал для ПК. Ну или стояла задача показать, насколько все сложно и запутанно.
В общем, идея такого интервью может была и хорошая, но вот реализация…
А какая зп у них?
Sign up to leave a comment.
Assembler в авиапроме: Интервью с разработчиком автопилотов на ASM для самолётов и беспилотников