не, это конечно не низкий уровень, чтото среднее. Llvm имеет несколько жирных слоев для поддержания платформонезав симости. Частью это обертки, но частью вполне себе комбайны по переводу из одного представление в другое, а из другого в третье.
Вообще, цена якобы "универсальности" довольно высока, но это тема отдельного семинара.
обычные проверки: число (адрес) в указанном (допустимом) диапазоне, число в допустимом списке и тд. Там не очень много алгоритмов проверок но все они сводятся к защите что бы вы не выпрыгнули из песочницы :)
Си не имеет никаких защит "под капотом" и это прекрасно! Обратимся к микроконтроолерам: если вам надо сложить например адрес и адрес вы это сразу делаете, без скрытого чек листа языков "безопасных". И сразу видете что в указанной ячейке памяти, и можете сразу поменять это число. Даже если память эта например в таблице irq. Это скальпель.
На рс у вас этот фокус не пройдет. Ладно, механизмы виртуализации и защиты ОС, но теперь и языки включились в ресурсоемкую гонку безопасности. Опять таки, все правильно для ряда ниш: веб, операционки и тд. Но не следует считать это безальтернативным, о чем многие забывают.
Движение за безопасность это не только благие лозунги, но и задел для будущей мотивация продаж более мощных чипов, по мере того, как объем "безопасного" кода на рынке будет расти и компы начнут притормаживать...
в контексте темы? оперативку конечно) неидеальное использование переменных за счет того что используется не линейная модель памяти с единым пространством переменных четко оговоренного размера (как в чистом Си) ну и ресурсы цпу для обслуживания проверок и разной сопутствующей бизнес-логики.
Но это небольшие накладные расходы, в "бытовом программировании" на современных РС вы ничего не заметите.
Напомните, его компилятор, код с руста переводит в псевдо-си?
Современный мир декларирует безопасность, мягкие стенки, предупреждающие знаки, комфортный воздух с запахом ванили)
Почему бы и нет?
Безопасность поедающая вычислителтные ресурсы, выполняющая бесчисленные проверки, мягко подхватывающая юзера что бы он не оступился. Толстые прослоики абстракций, черные ящики классов покрашенные розовой краской. Современные новые программисты не могут без них.
Их код будет тяжелым и раздутым но безопасным. То что на Си++ весило 60кб будет весить мегабайт на безопасных языках и работать медленнее на проценты. Некритично: ресурсы cpu давно умчались с лихвой закрывая потребности безопасного кода. Для интернета и "грязной" зоны исполнения от безопасных языков не уйти.
Равно как и не уйти от Си там где нам нужна скорость и эффективность кода. Скальпель открытой памяти и жонглирования указателями остр, опасен, и дьявольски эффективен в умелых руках. И операции скальпелем это не масс-маркет программных продуктов. Это острие алгоритмов, фокус программирования. Там не может быть никаких защит - для работы скальпелем они вредны.
Так что - это просто разные ниши) Не надо их смешивать)
Автожир при выполнении определенных условий (на стадии проектирования) стабилен как трамвай. Например, внезапно дунул сильнейший боковик, развернувший вас? Вы скажете «Вау!», развернетесь на свой маршрут и полетите дальше. Ну еще обороты ротора слегка подрастут в момент прохождения порыва ветра. Ни колебаний, ни проблем с безопасностью, ничего. Планерам, дельтам, самолетам и вертушкам придется заметно хуже.
«Чуткость управления» у автожира самая обычная, все в опыт пилота упирается. (Для справки: в общем случае к самостоятельному вылету вы готовы уже на 15 часу полетов.)
Отказ двигателя не приносит проблем управляемости (кроме курсового управления хвостом, педальками, которое становится вялым). Если вы уберете горизонтальную компоненту скорости, «остановитесь на месте», борт просто начнет просаживаться, паращютировать. Для нормальной посадки нужна горизонтальная компонента которую набираем воздушной скоростью, крутым спуском. Без двигателя кривая глиссады автожира с непривычки пугает, это 30 и более градусов носом вниз, но на самом деле все безопасно, и далее садитесь как обычно. Если надо сесть в точку без пробега, то у самой земли вы резко тянете ручку на себя что бы снять вертикальную и горизонтальную компоненты, становите аппарат почти на дыбы. И мягко опускаетесь на остатках авторотации и экранном эффекте. Если встречного ветра нет, полностью горизонтальную скорость скорее всего не снимете но это будет примерно 20 км/ч при касании земли, не более.
Не надо горку делать) все остальные режимы не разгружают ротор (если он правильно подобран к массе аппарата)
Там основная проблема безопасности полетов это PIO (pilot induced oscillations), особенно если машина малостабильная от рождения (что является признаком плохого проектирования данного аппарата а не проблемой для автожиров как таковых).
Возможно. За давностью лет не помню кто там такой прожорливый был. himem.sys? ramdrive? Помню что регулярно боролся за килобайты и было где то 400 с копейками свободных. Может драйвер для виртуального диска? Был период когда слетел HDD и что бы не тратить ресурс дискет, откопировал все нужное на расходные 5.25 дискеты и создавал с утра ramdisk на 3 мегабайта (всего озу было 4), куда и сливал с расходных.
TSR были весьма ограниченны по функционалу. 640 кб, не забывайте. Да, можно было вешать драйвер мыши, русскоязычной раскладки, MSCDEX для счастливых обладателей CD, но ни о какой графике речи конечно не шло. Традиционно там килобайт 300...400 оставалось. Игре хватало? Ура! Не хватает? окей, пляски с бубуном — кто поедет из autoexec.bat на выход? (легкий случай) Или system.ini (потяжелее уже).
DOS4GW и прочие кто мог 16 мб оперировать (если они были эти мегабайты :) ) им для запуска вообще жуть сколько надо было. Вечная проблема где 20 кб еще вытащить.
Архитектура системы такова что единичные ошибки не могут сильно повлиять на поведение системы в целом. Но это выходит за рамки статьи. Серьезные фатальные ошибки засекаются еще на этапе проверки SoftwareInLoop через симулятор.
Позволю заметить, что оперативность внесения изменений выше. Алгоритмических ошибок бывает достаточно и в моем коде, но в отличии от чужого они решаются сразу, с ходу, без необходимости вникания в чужой код.
Это многопроцессорная система.
Один STM32F4 на главный алгоритм, один на оптику (с одной камеры). Есть доп процессор (послабже) на IMU и совсем слабенький на IO. Это что касается только автопилота не входя в тонкие материи шифрования радиообмена.
Вы совершенно правы, и если бы речь шла о создании проекта с нуля, важнейшими пунктами должностной инструкции программистов были бы относящиеся к написанию читаемого кода. Незаменимые люди в бизнес-процессах безусловное зло.
Более того, у армии есть требования к группам разработки, как раз касающиеся предотвращению возникновения ситуаций когда ведущего разработчика съела акула или он улетел на месяц на Алтай и все встало. Потому как кроме него никто не может разобраться в коде. Такие разработки не пройдут финансирования изначально.
я не имел в виду стандартные библиотечные функции и уж тем более malloc/free — даже и не претендую их переписывать. Речь шла про те что выходят за пределы стандартной библиотеки
Коллеги, среда разработки coocox (МК STM32) + версия для отработки это старенький Codegear CBuilder. Это один и тот же файл .c, просто на критических точках, где берется работа с реальными аппаратными датчиками и IO используются альтернативные ветки через #ifdef
Так что особых ограничений касаемо кода нет.
По спагетти-коду, совершенно верно прокомментировано что в данном случае функциональность и быстродействие ставится в некоторый ущерб портируемости.
Но не до степени граблей.
Код переписывался и рефакторился больше десятка раз.
Архитектура системы такова что некоторые функции "размазаны" по коду, что накладывает определенные ограничения. Опять таки, код насыщен комментариями буквально по всем строчкам. Почти каждая операция поясняется "зачем/почему", что получаем, и т.д. и при необходимости по каким меткам в коде искать относящиеся к ней элементы. Так что спагетти-код в моем случае это в меньшей степени техническое определение и в большей литературная аллегория.
Хм, согласен, формулировка неточна. Все коды конечно тестируются и проверяются на земле в первую очередь. Но если возникает некая проблема, и ее причина упирается в выбранный сторонний алгоритм (который для примера вы используете как готовое решение, не углубляясь и не вникая в него, только подключив к нему функции из своего кода), и вы раз за разом проходите по коду все больше убеждаясь что данный алгоритм не работает как надо — дальше есть два пути. Можно разбирать чужой код, как он работает, где делает "не так", или искать другие готовые алгоритмы. Или писать свой. Так вот, используя чужой код я не уверен на 100% что он во всех случаях отработает как надо. Если я его не разобрал построчно, и особенно все непонятные мне места. И часто с глубокой переработкой. Но не проще ли написать тогда свое?
не, это конечно не низкий уровень, чтото среднее. Llvm имеет несколько жирных слоев для поддержания платформонезав симости. Частью это обертки, но частью вполне себе комбайны по переводу из одного представление в другое, а из другого в третье.
Вообще, цена якобы "универсальности" довольно высока, но это тема отдельного семинара.
обычные проверки: число (адрес) в указанном (допустимом) диапазоне, число в допустимом списке и тд. Там не очень много алгоритмов проверок но все они сводятся к защите что бы вы не выпрыгнули из песочницы :)
Си не имеет никаких защит "под капотом" и это прекрасно! Обратимся к микроконтроолерам: если вам надо сложить например адрес и адрес вы это сразу делаете, без скрытого чек листа языков "безопасных". И сразу видете что в указанной ячейке памяти, и можете сразу поменять это число. Даже если память эта например в таблице irq. Это скальпель.
На рс у вас этот фокус не пройдет. Ладно, механизмы виртуализации и защиты ОС, но теперь и языки включились в ресурсоемкую гонку безопасности. Опять таки, все правильно для ряда ниш: веб, операционки и тд. Но не следует считать это безальтернативным, о чем многие забывают.
Движение за безопасность это не только благие лозунги, но и задел для будущей мотивация продаж более мощных чипов, по мере того, как объем "безопасного" кода на рынке будет расти и компы начнут притормаживать...
в контексте темы? оперативку конечно) неидеальное использование переменных за счет того что используется не линейная модель памяти с единым пространством переменных четко оговоренного размера (как в чистом Си) ну и ресурсы цпу для обслуживания проверок и разной сопутствующей бизнес-логики.
Но это небольшие накладные расходы, в "бытовом программировании" на современных РС вы ничего не заметите.
Напомните, его компилятор, код с руста переводит в псевдо-си?
Современный мир декларирует безопасность, мягкие стенки, предупреждающие знаки, комфортный воздух с запахом ванили)
Почему бы и нет?
Безопасность поедающая вычислителтные ресурсы, выполняющая бесчисленные проверки, мягко подхватывающая юзера что бы он не оступился. Толстые прослоики абстракций, черные ящики классов покрашенные розовой краской. Современные новые программисты не могут без них.
Их код будет тяжелым и раздутым но безопасным. То что на Си++ весило 60кб будет весить мегабайт на безопасных языках и работать медленнее на проценты. Некритично: ресурсы cpu давно умчались с лихвой закрывая потребности безопасного кода. Для интернета и "грязной" зоны исполнения от безопасных языков не уйти.
Равно как и не уйти от Си там где нам нужна скорость и эффективность кода. Скальпель открытой памяти и жонглирования указателями остр, опасен, и дьявольски эффективен в умелых руках. И операции скальпелем это не масс-маркет программных продуктов. Это острие алгоритмов, фокус программирования. Там не может быть никаких защит - для работы скальпелем они вредны.
Так что - это просто разные ниши) Не надо их смешивать)
«Чуткость управления» у автожира самая обычная, все в опыт пилота упирается. (Для справки: в общем случае к самостоятельному вылету вы готовы уже на 15 часу полетов.)
Отказ двигателя не приносит проблем управляемости (кроме курсового управления хвостом, педальками, которое становится вялым). Если вы уберете горизонтальную компоненту скорости, «остановитесь на месте», борт просто начнет просаживаться, паращютировать. Для нормальной посадки нужна горизонтальная компонента которую набираем воздушной скоростью, крутым спуском. Без двигателя кривая глиссады автожира с непривычки пугает, это 30 и более градусов носом вниз, но на самом деле все безопасно, и далее садитесь как обычно. Если надо сесть в точку без пробега, то у самой земли вы резко тянете ручку на себя что бы снять вертикальную и горизонтальную компоненты, становите аппарат почти на дыбы. И мягко опускаетесь на остатках авторотации и экранном эффекте. Если встречного ветра нет, полностью горизонтальную скорость скорее всего не снимете но это будет примерно 20 км/ч при касании земли, не более.
Там основная проблема безопасности полетов это PIO (pilot induced oscillations), особенно если машина малостабильная от рождения (что является признаком плохого проектирования данного аппарата а не проблемой для автожиров как таковых).
DOS4GW и прочие кто мог 16 мб оперировать (если они были эти мегабайты :) ) им для запуска вообще жуть сколько надо было. Вечная проблема где 20 кб еще вытащить.
Один STM32F4 на главный алгоритм, один на оптику (с одной камеры). Есть доп процессор (послабже) на IMU и совсем слабенький на IO. Это что касается только автопилота не входя в тонкие материи шифрования радиообмена.
Более того, у армии есть требования к группам разработки, как раз касающиеся предотвращению возникновения ситуаций когда ведущего разработчика съела акула или он улетел на месяц на Алтай и все встало. Потому как кроме него никто не может разобраться в коде. Такие разработки не пройдут финансирования изначально.
Так что особых ограничений касаемо кода нет.
По спагетти-коду, совершенно верно прокомментировано что в данном случае функциональность и быстродействие ставится в некоторый ущерб портируемости.
Но не до степени граблей.
Код переписывался и рефакторился больше десятка раз.
Архитектура системы такова что некоторые функции "размазаны" по коду, что накладывает определенные ограничения. Опять таки, код насыщен комментариями буквально по всем строчкам. Почти каждая операция поясняется "зачем/почему", что получаем, и т.д. и при необходимости по каким меткам в коде искать относящиеся к ней элементы. Так что спагетти-код в моем случае это в меньшей степени техническое определение и в большей литературная аллегория.