Действительно ли встроенные разработчики более консервативны, чем их рабочий стол brethrens? [закрытый]
Когда вы делаете
int(math.pow(14764352724, 6))
, вы получаете большое число, возведенное в степень, но используя метод с плавающей запятой, даже если аргументы являются целыми числами. Преобразование в целое число теряет точность (исходный результат - число с плавающей точкой: 1.0358251994780843e+61)
Когда вы делаете
14764352724**6
, вы получаете большое число, возведенное в степень с использованием двоичного кода метод power , использующий только целочисленное умножение.
Таким образом, второй результат является точным, тогда как первый не является
>>> int(math.pow(14764352724,6))
10358251994780842724998096890217137953445700726699419360034816 # wrong
>>> 14764352724**6
10358251994780842575401275783021915748383652186833068257611776 # correct
Давайте попробуем разобрать функции ** и math.pow:
import dis,math
def test(n):
return n ** 3
def test2(n):
return math.pow(n,3)
dis.dis(test)
dis.dis(test2)
output
4 0 LOAD_FAST 0 (n)
3 LOAD_CONST 1 (3)
6 BINARY_POWER
7 RETURN_VALUE
7 0 LOAD_GLOBAL 0 (math)
3 LOAD_ATTR 1 (pow)
6 LOAD_FAST 0 (n)
9 LOAD_CONST 1 (3)
12 CALL_FUNCTION 2 (2 positional, 0 keyword pair)
15 RETURN_VALUE
Как видите, функции не эквивалентны. BINARY_POWER вызывается в первом случае. Эта функция имеет шанс выполнить точное целочисленное умножение , когда параметры целые :
BINARY_POWER ()
Реализует TOS = TOS1 ** TOS
Двоичная мощность выдает то же значение, что и
math.pow, когда параметры не все целочисленные:>>> 14764352724**6.0 1.0358251994780843e+61 >>> int(14764352724**6.0) 10358251994780842724998096890217137953445700726699419360034816Примечание: что, вероятно, добавляет к путанице встроенную [ 1111] метод, который отличается от
math.pow(и переопределяется последним при использованииfrom math import pow), но эквивалентен оператору**при использовании без аргумента по модулю:pow (x, y [, z])
Вернуть x в степень y; если присутствует z, вернуть x в степень y по модулю z (вычисляется более эффективно, чем pow (x, y)% z). Форма двух аргументов pow (x, y) эквивалентна использованию степенного оператора : x ** y.
BLOCKQUOTE>
8 ответов
Действительно ли встроенные разработчики более консервативны, чем их рабочий стол brethrens?
Да, потому что они более обеспокоены последствиями совершения ошибок. Это - грандиозное предприятие исправить встроенное устройство. Не так для настольного приложения.
Разработка Waterfallish необходима во встроенном мире, потому что Вы обычно создаете аппаратные средства в то же время, что и программное обеспечение. Необходимо знать как можно скорее, сколько памяти, сколько скорости процессора, как большой флэш-память, что, если какое-либо специальное оборудование необходимо и т.д... Аппаратный дизайн не может завершиться, пока Вы не знаете эти ответы. После того как Вы решаете, это - в значительной степени это. Время выполнения заказа для восстановления платы является слишком длинным. Если Вы портите затем программное обеспечение, оказывается перед необходимостью работать вокруг любых недостатков. Не обычно идеальная ситуация.
Что касается инструментов, который является в основном на основе того, что поставщик обеспечивает и любая предвзятость разработчиков. На некоторых проектах я использовал Встроенный XP и получил в значительной степени все, что получает настольный разработчик.
XP, толпа, повторяющаяся, минимизированная/Гибкая:
Так как большая часть дизайна сделана впереди (при необходимости), и у Вас обычно нет рабочих аппаратных средств, когда пора кодировать, быстрые оборотные процессы действительно не предоставляют много преимущества.
Непрерывные Сборки Интеграции/Автоматизировать, Хорошие, чтобы иметь, но не действительно необходимый. Какой … требуется приблизительно 15 секунд, чтобы открыть IDE и нажать кнопку компиляции.
Автоматизированное поблочное тестирование
Никакая причина, почему это не должно быть сделано, но только часть кода, не может действительно быть автоматически протестирована, потому что другая часть или аппаратно-зависима или имеет некоторые другие зависимости как синхронизация. Таким образом, Вы не можете действительно сказать, работает ли код автоматизированными тестами.
Рефакторинг поддержки инструмента
Поставщики встроенного продукта процессоров являются процессором. Они оказывают поддержку IDE, чтобы поощрить Вас покупать их процессор. Они не могли возможно позволить себе заплатить за измеренную группу разработчиков Visual Studio для добавления всех дополнительных свойств к IDE, который не является даже их продуктом.
Мы все привыкли к тому, что наш настольный ПК отказывает время от времени (или по крайней мере приложение на рабочем столе внезапно исчезает). Это не грандиозное предприятие. Следующий патч зафиксирует его.
Во встроенном пространстве Вы создаете что-то, что не может быть исправлено. Жизни могут зависеть от Вашего устройства (в автомобиле, лифте или медицинской системе). Большинство устройств установлено и затем должно работать необслуживаемый в течение многих лет. Таким образом, встроенные люди склонны быть очень консервативными. TCP/IP часто "слишком современен". Они придерживаются своей испытанной последовательной шины с коммуникацией "стек", который является примерно 50 строками ассемблерного кода.
Что хуже, у Вас просто нет распространенности пространства на устройстве, что означает, что Вы не можете использовать один из последних языков программирования, которые делают TDD и автоматизированные сборки счастьем.
Затем, много встроенных сред разработки является собственным. Если Ваш поставщик не будет поддерживать его, то Вы не получите его. Linux начал ослаблять это в прошлых годах, но много устройств не достаточно мощно для выполнения Linux, все же. И даже если бы они были, то мощность ЦП использовалась бы для чего-то еще вместо того, чтобы выполнить необычную ОС, которая идет с источником.
Таким образом да, существуют мощные силы, работающие в фоновом режиме для хранения встроенного пространства, где это.
Эти некоторые причины я могу думать:
- Встроенные команды обычно меньше тот рабочий стол/Сеть команды. Кодовая база меньше.
- Тестирование системы намного более важно, чем поблочное тестирование. Программное обеспечение должно быть протестировано вместе с аппаратными средствами. Автоматизированное тестирование не возможно и может только быть применено к небольшой части кодовой базы.
- У встроенных инженеров есть другой набор навыков, чем разработчики программного обеспечения. Они взаимодействуют с аппаратными средствами, знают, как использовать осциллограф и анализатор логики. Обычно, трудная часть их задания должна найти незначительный сбой в аппаратных средствах. У них нет времени для принятия современного программного обеспечения methologies.
Встроенные программисты являются главным образом инженерами-электриками, не программистами или разработчиками программного обеспечения.
Они выделяются в их поле экспертных знаний. Они приносят более медленному больше методического подхода, чем большинство программистов. Когда дело доходит до программирования встроенного микропрограммного обеспечения инженеры-электрики знают как раз достаточно, чтобы быть опасными.
Вот некоторые вещи, я заметил инженеров-электриков, делающих в C:
- Весь код в ОДНОМ единственном файле
- Математика как имена переменной: x, y, z
- Никакое или недостающее добавление отступа
- Никакие stardard не комментируют заголовки
- Никакие комментарии вообще
- Слишком много комментариев
В их защите EE не обучался, чтобы быть программистами, это не их задание. Я думаю, что программное обеспечение является самой твердой частью создания встроенных устройств. Разработка PCBs и выбор компонентов требуют навыка, но бледнеют по сравнению со сложностью 10 000 строк кода.
Встроенные программисты также должны иметь дело IDE, которые смотрят и ведут себя как IDE 90-х.
Это просто, что встроенная среда делает более трудным реализовать новые методы или инструменты?
Это - частично вопрос масштаба. Программное обеспечение НЕ является продуктом, продуктом является продукт. однако, существуют тысячи различных типов микроконтроллеров и микропроцессоров там, и самая популярная тысяча имеет 3-4 различных компилятора, которые не абсолютно совместимы.
Таким образом, данный инструмент только будет используемым несколькими сотнями или тысячей инженеров.
В разработке окон, однако, существуют миллионы программистов многих уровней - инструменты производят программное обеспечение непосредственно, которое является продуктом, и таким образом, это собирается получить больше глазных яблок и больше денег.
Каждый новый продукт, который производит инженер, мог бы иметь различный процессор.
Случается так, что мышление встроенных программистов регулирует их далеко от новых инструментов/понятий?
Встроенные программисты обычно являются программным обеспечением или микропрограммными инженерами, в противоположность программистам. Разработка подразумевает определенное количество дизайна, анализа дизайна и доказательства дизайна до реализации - другими словами, тонна работы сделана, прежде чем первая строка кода записана, и документация, идеально, достаточно конкретна, что реализация просто поворачивает псевдокод как документация в компилируемый код.
Новые инструменты и понятия необходимы в стадии проектирования, не фазе реализации. IDE с intellisense может быть хорошим, но к тому времени, когда код пишется, это - бесполезный хлам - они уже знают то, в чем они нуждаются.
CAD - автоматизированное проектирование - инструменты разрабатываются для микропрограммных инженеров, которые используются в стадии проектирования для разработки моделей и моделирований, которые непосредственно превращены в код. Matlab и simulink являются хорошими примерами этого. Система в целом разработана.
На самом деле можно было бы задаться вопросом, почему разработчики программного обеспечения являются все еще написанием кода, в то время как инженеры делают диаграммы данных/процесса выполнения программы и схемы конечного автомата. Почему внедрение UML является настолько медленным в мире приложения? Это кажется, что разработчики приложений могут использовать некоторые инструменты, широко использующиеся инженерами встроенных систем...
Случается так, что управление в типичной встроенной промышленности позади кривой по сравнению с IT сфокусировало поля?
На самом деле это вероятно реверс. Когда проект запускается, инженеры должны выбрать процессор.
Производители процессоров получают меньше денег на более старых микросхемах, таким образом, они передают последнее и самое большое, и они являются обычно более дешевыми в целом, чем микросхемы, используемые в предыдущем дизайне (любой умирает уменьшения, больше интеграции, и т.д.).
Таким образом, дизайн на самом деле использует последние и самые большие микросхемы.
Оборотная сторона - то, что компилятор и инструменты являются часто незрелыми. Они могут только создать так много на более старых инструментах, и начиная с целевых перемещений с каждым новым процессором, они не могут сфокусироваться на большом количестве хороших прикладных программистов функций, мог бы любить. Тем более, что многие из тех функций не будут полезны для встроенного инженера.
Существует много других факторов, некоторые из которых перечисляются другими ответами, но это - действительно другое поле даже при том, что они оба включают программирование.
- Adam
Я также добавил бы несколько точек здесь:
- В общих встроенных проектах имеют тенденцию быть меньшим, чем настольные проекты. Это уменьшает потребность в очень разработанных программных процессах.
- Требования для встроенного проекта часто точны и лучше определенный. Поэтому ТОЛПА и гибкий не так крайне важна
- Наконец встроенные проекты обычно являются соединением программного и аппаратного обеспечения. Так как программное обеспечение является только частью встроенных разработчиков проекта, инвестируют меньше времени в программные процессы
Я сказал бы, что это - больше отсутствия хороших наборов инструментов. Действительно печально, когда Вы хотите использовать C++ для его функций времени компиляции, не существующих в C (шаблоны, пространства имен, объектно-ориентированность, и т.д.), а не ее функций во время выполнения (исключения, виртуальные функции) - но производители устройств, и третьи стороны просто дают Вам компилятор C, не C++. Это, вероятно, происходит больше от размера рынка (сотни миллионов ПК, запускающих Windows, с сотнями тысяч или даже миллионами разработчиков - по сравнению с сотнями тысяч Микросхемы X, с сотнями или низкими тысячами разработчиков), чем от функции устройств.
править: устойчивость w/r/t: там существуют различные рынки. Автомобильный/лифт/аэронавтика/медицинское устройство рынок оказывается перед необходимостью быть строгим об избавлении от ошибок. Другие рынки (игрушки, MP3-плееры, и другая бытовая электроника) могут быть менее строгими, особенно если возможно обновить код в поле. ("Ой! Мы сожалеем, что удалили Вашу музыкальную библиотеку! Мы просто исправили ту ошибку, можно захватить последний выпуск в нашем веб-сайте когда Вам будет удобно!")
Я сказал бы что различные виды проблемных сред.
Самой большой проблемой с методологией водопада является то изменение требований. В каждой среде я был в, была, по крайней мере, вероятность изменения требований, что означает, что успешные методологии - те, которые сохраняют гибкость максимально долго. Даже если клиент закончил в крови и выдерживает утратить левую руку, если он предлагает изменение, существуют изменения, прибывающие в будущее.
Во встроенном программировании возможно закрепить требования впереди. Они происходят из поведения системы в целом, и инженеры способны закреплять системные требования. Ничья попытка войти на полпути через и сказать, что пользователь теперь хочет, чтобы кардиостимулятор поставил синкопировавшие импульсы, в то время как получатель танцует.
После того как требования замораживаются вне размораживания, которого никогда не происходит в программном обеспечении, разработанном для человеческого использования, водопад является очень эффективной методологией. Команда продолжает двигаться от хорошо указанных требований до общего замысла, затем детальное проектирование, затем кодирование, проверяя полностью, что этапы сделаны правильно. Затем пора отладить код (так как это никогда не прекрасно при записи) и завершающие испытания, чтобы удостовериться, что код отвечает требованиям.