Вопросы от начинающих по МК

[ARV]

1 час назад, my504 сказал:

Ну и не факт, что компилятор оптимизирует двойное отрицание до приведения типа.

А куда он денется? Вы же сами писали: тип bool появляется после действия логического оператора, отрицание - это логический оператор, на его выходе только 1 или 0, дальше - автоматика.

1 час назад, my504 сказал:

Больше - не значит хуже

Лучше тоже не значит.

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[my504]

1 час назад, ARV сказал:

А куда он денется?

По результату - никуда. А по генерации кода есть два варианта - одна операция или три.

И таки ЛУЧШЕ, когда не требуется дополнительных пояснений для разной квалификации читателей этого кода.

Меня не радуют головоломные синтаксические конструкции. Кроме роста вероятности ошибок и потери времени на разбор при поддержке сторонними людьми,  иных особенностей я не нахожу. Эстетика автора таких нетленок меня совершенно не занимает. Поскольку у меня такой цели нет.

Изменено 29 июня, 2020 пользователем my504

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[ARV]

15 минут назад, my504 сказал:

одна операция или три

Как бы это не тот вопрос, который должен беспокоить.

Но, с другой стороны, каким образом (bool) сделает 1 из 12 - разве не тремя или четырьмя операциями? Примерно так: если не ноль, то 1, а если ноль - обойти, выходит 3 ассемблерных команды. Ну две, возможно...

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Yurkin2015]

1 hour ago, ARV said:

отрицание - это логический оператор

Да, и он оперирует с логическими величинами. Ведь, нельзя же спросить, "число 35 это правда или ложь?" Но можно спросить, "число 35 не равно 0 , это правда или ложь?"

Поэтому перед применением логического отрицания, программа сначала сравнивает операнд с нулём, получает промежуточный результат со значением True или False, а потом уже выполняет отрицание результата.

Точно так же будет сравнение с нулём перед использованием логического &&, только в этом случае не будет потом двойного отрицания, а сразу выполнится логическое умножение результатов сравнения.

Хотя, оптимизатор компилятора просто проигнорирует это самое двойное отрицание, и на размер кода добавление лишних отрицаний не повлияет.

А при использовании == с двойным отрицанием могут буть интересные результаты.

int x = 3;
int y = 5;
int new_x = !!x;
int new_y = !!y;

x == y    (False)
new_x == new_y  (True)

Вот тут уже при сравнении нужно помнить, какие переменные были с двойным отрицанием, а какие без оного, чтобы правильно интерпретировать результат сравнения. Это явно не облегчит жизнь программиста.

[ARV]

10 минут назад, Yurkin2015 сказал:

Вот тут уже при сравнении нужно помнить, какие переменные были с двойным отрицанием, а какие без оного, чтобы правильно интерпретировать результат сравнения. Это явно не облегчит жизнь программиста.

Пример неудачный, при таком подходе программисту жить и в самом деле будет тяжко.

Надо помнить, что в Си любое ненулевое число эквивалентно TRUE. Поэтому спросить "35 это правда или ложь" не только можно, но нужно: это единственное, что понимает Си. Поэтому лично я не уверен, что && сделает из правого и левого операнда значение типа bool - тут, как сказал @my504 , только РЕЗУЛЬТАТ будет bool, а операнды останутся того типа, как были созданы. А все неявные (умалчиваемые) преобразования типов, имхо, усложняют жизнь программиста куда больше, чем !!, которые делают именно то, что делают - возвращают корректный bool-результат.

Изменено 29 июня, 2020 пользователем ARV

[my504]

2 часа назад, ARV сказал:

выходит 3 ассемблерных команды. Ну две, возможно...

В ассемблере есть ИНСТРУКЦИИ и директивы, команд там нет. Я ни разу ни о том, ни о другом не говорил. Я говорил об операциях Си. В одном случае это ОДНА операция - явное приведение типа, а в другом их три - неявное приведение типа и два отрицания. Без оптимизации Си обязан сделать все три.

1 час назад, ARV сказал:

А все неявные (умалчиваемые) преобразования типов, имхо, усложняют жизнь программиста куда больше, чем !!, которые делают именно то, что делают - возвращают корректный bool-результат.

Помилосердствуйте, отец родной!!! Вы предлагаете НЕЯВНОЕ преобразование типа. Прямо в самом рафинированном виде.

Строго говоря, Ваша запись должна выглядеть как  !!(bool)A ==  !!(bool)B  

 

[ARV]

1 час назад, my504 сказал:

Строго говоря, Ваша запись должна выглядеть как  !!(bool)A ==  !!(bool)B

С чего вдруг? Моя запись по смыслу полностью эквивалентна (bool).

1 час назад, my504 сказал:

Без оптимизации Си обязан сделать все три.

И какой из этого следует вывод?

1 час назад, my504 сказал:

Вы предлагаете НЕЯВНОЕ преобразование типа.

Дайте определение неявного преобразования типа, а то я что-то не очень вас понимаю. Вот результат операции + имеет тип int для всех данных "меньшей или равной" int размерности - это явное или неявное указание типа?

Изменено 29 июня, 2020 пользователем ARV

[my504]

1 час назад, ARV сказал:

Моя запись по смыслу полностью эквивалентна (bool).

А кто с этим спорит? Она эквивалентна в силу неявного преобразования типов.

1 час назад, ARV сказал:

И какой из этого следует вывод?

Вывод о том, что логическая операция с нелогическим  типом невозможна по определению. Поэтому в Си есть правила неявного или явного преобразования типа. Что мы и видим в дизасме подобных выражений. Понятно, что компилятор уберет бессмысленные отрицания, оставив только неявное приведение. Но без оптимизации, строго говоря, он делать это не имеет права.

1 час назад, ARV сказал:

Дайте определение неявного преобразования типа, а то я что-то не очень вас понимаю. 

Неявное приведение типа - это изменение типа копий операндов и/или промежуточного результата без прямого указания в выражении по правилам языка/компилятора с целью получения корректного (или определенного) результата операции.

Поскольку Вы сами (за язык никто не тянул) отнесли себя к адептам явного приведения типов в выражениях с разными и/или несогласованными типами, то выглядит странным Ваше стремление к "птичьей" форме записи на Си.

Изменено 29 июня, 2020 пользователем my504

[ARV]

7 минут назад, my504 сказал:

то выглядит странным Ваше стремление к "птичьей" форме записи на Си.

Вам придётся с этим смириться.

[Starichok]

5 часов назад, ARV сказал:

Поэтому спросить "35 это правда или ложь" не только можно, но нужно: это единственное, что понимает Си.

совершенно верно.

это видно на операторе if - любое число, отличное от нуля,, этот оператор понимает, как "истина", и даже для отрицательных чисел, а не только положительных. и только ноль понимает, как "фальшь".

[my504]

Только что, Starichok сказал:

это видно на операторе if 

Дадада... Особенно если учесть, что не существует способа реализовать  в инструкциях процессора этот самый if без промежуточного результата в виде однобитного флага, что и является приведением типа.

Старичок, прежде чем комментировать обсуждение, стоит разобраться в чем СУТЬ этого обсуждения. Тогда очень возможно, у Вас пропадет желание комментировать. Вы пытаетесь утверждать то, с чем никто тут не спорил.

12 минут назад, ARV сказал:

Вам придётся

Смириться со своим удивлением? 

Это как?

[ARV]

9 часов назад, my504 сказал:

Это как?

Уж как-нибудь. Я не знаю - тут для начинающих программистов МК тема, а не для психологов.

[my504]

56 минут назад, ARV сказал:

тут для начинающих

Разве начинающему стоит сразу становиться фриком? Я всегда полагал, что начинающий должен всеми средствами избегать вычурности и сокращений....

ЗЫ. Случайно вышло. Вчера вечером, когда я набирал текст предыдущего комментария, рядом оказался мой сын (в гости пришел). Полюбопытствовал о чем речь. Я дал ему прочитать тему. Он 10 лет программистом в КасперЛабе и  два года в Яндексе. За такие выкрутасы в профессиональной среде бьют больно. Не потому что ошибка, а потому что отвратительная поддержка. Из кода должны быть очевидны потаенные мысли автора. А подобная клоунада кроме недоумения, вопросов и потери времени на догадки о причинах ничего не вызывает. Это не мой вердикт, видит Бог.

Изменено 30 июня, 2020 пользователем my504

[ARV]

1 час назад, my504 сказал:

Разве начинающему стоит сразу становиться фриком?

А кому, как не начинающему, это решать?

1 час назад, my504 сказал:

За такие выкрутасы в профессиональной среде бьют больно.

Мир профессионального программирования построен из догм и мнений фриков. Причем сначала фрики придумывают какие-то вычурности, а потом, заматерев, вводят эти вычурности в стандарты, превращая их в догмы. И те, кто поначалу крутил пальцем у виска на этих фриков, начинают неистово рукоплескать нововведениям стандарта. Это закономерность.

Кстати, я могу ошибаться, но по-моему именно вы в одном из споров взывали к стандарту MISRA, а в нем, если опять-таки не ошибаюсь, явное приведение типов запрещено. Так что не все так однозначно...

Изменено 30 июня, 2020 пользователем ARV

[my504]

26 минут назад, ARV сказал:

Кстати, я могу ошибаться, но по-моему именно вы в одном из споров взывали к стандарту MISRA, а в нем, если опять-таки не ошибаюсь, явное приведение типов запрещено.

Я ничего про MISRA не могу взывать. По определению. Я не знаком с этим стандартом. Но запрет на явное приведение типов для эмбедда выглядит запретом на профессию. Поэтому у меня есть обоснованные сомнения.

32 минуты назад, ARV сказал:

Мир профессионального программирования построен из догм и мнений фриков.

Мир профессионального программирования никакого отношения к МНЕНИЯМ не имеет. Основное правило администрирования проектов - это гарантия поддержки и тестирования неопределенным кругом лиц. Поэтому все направлено на читабельность проектов. Маргинальные фокусы запрещены, даже если ошибкой не являются..

ЗЫ. Вы зря препираетесь со мной. Я высказал свое мнение, которое, как случайно оказалось, поддерживается  профессионалами. Никто Вам не запрещал высказать свое. Все всё прочитали и выводы свои сделали.

[my504]

Стало любопытно и я открыл MISRA.

Цитата

43. Неявные преобразования, способные приводить к потере информации не должны использоваться. (обязательное)

44. Избыточные явные приведения типов не должны использоваться. (рекомендуемое)

В каком месте тут ЗАПРЕЩЕНО явное приведение типов?

[ARV]

35 минут назад, my504 сказал:

В каком месте тут ЗАПРЕЩЕНО явное приведение типов?

Я и писал, что не уверен, так и вышло - не запрещено, но не рекомендуется. В контексте препирательства !! не использует ничего неявного или неопределенного, не приводит к потере информации и т.п., т.е. на 100% соответствует, как Си (в любом варианте стандарта), так и МИСРА. В то время как тип bool введен, кажется, начиная с C99, а в ANSI C отсутствует в принципе, и приведение к этому типу не рекомендуется в МИСРА.

Более того, в отличие от всевозможных брайнфаковских способов писать на Си, двойное отрицание абсолютно прозрачно и понятно, не хуже оператора ++. Кто там и кому бьет по рукам в среде профессионалов - я не в курсе, никогда профессионалом не был, и не вижу причин знакомиться с этим аспектом программирования. Мне хватает "стандартного типа" void, чтобы с пренебрежением относиться к логике разработчиков стандартов и прочих "профессионалов". Имею право.

А вы следуйте своим принципам - я тоже не посягаю на ваше право. Надеюсь, и у вас тоже нет желания посягать на мое право рекомендовать начинающим то, чем я пользуюсь успешно и беспроблемно много лет.

[Starichok]

14 часов назад, my504 сказал:

стоит разобраться в чем СУТЬ этого обсуждения

суть этого обсуждения была про логические операторы языка Си, а не про инструкции процессора, которые генерирует компилятор.

и если человек пишет на Си, то его интересуют только правила языка Си, а не количество инструкций, сгенерированных компилятором.

[my504]

1 час назад, Starichok сказал:

если человек пишет на Си, то его интересуют только

Человека, который пишет на Си, может интересовать все что угодно - от значков и марок до нетрадиционного секаса... )))

А на самом деле, эмбеддера дОлжно интересовать что в результате компиляции будет во флеше МК.

Так красивая запись на Си может оказаться многократным тяжеловесным расчетом одного и того же или тяжеловесным доступом к одной и той же неизменяемой переменной в цикле...

 

Изменено 30 июня, 2020 пользователем my504

[ARV]

1 час назад, my504 сказал:

А на самом деле, эмбеддера дОлжно интересовать что в результате компиляции будет во флеше МК.

В общем случае это не так: всех, в т.ч. эмбеддеров, интересует только соответствие результата ТЗ. Если результат работает в соответствии с ТЗ, то что там во флеше - не интересно никому вообще. То есть если поместилось во флешь и по времени исполнения укладывается (профессионалы добавляют - проходит все тесты) - баста.

В частном случае впихивания невпихуемого или поиска багов - да, интересоваться содержимым флеша приходится. Но никак не в качестве основной цели.

1 час назад, my504 сказал:

Так красивая запись на Си может оказаться

Может. А может и не. Достаточно посмотреть в листинг, чтобы выяснить это.

В частности, код с (bool) и !! компилируется avr-gcc в идентичный по размеру файл при любой степени оптимизации (в том числе -O0). И для меня это абсолютно не удивительно.

Изменено 30 июня, 2020 пользователем ARV

[my504]

1 час назад, ARV сказал:

В общем случае это не так: всех, в т.ч. эмбеддеров, интересует только соответствие результата ТЗ.

Вот я сейчас и переделываю практически полностью такое "соответствие ТЗ" на 32F407. Такой вот "эмбеддер" написал....

А чё? В обработчике прерываний закатал переписывание массива в 1600 слов. Работало же... 

Не смог запустить ДМА - сделал на прерываниях. То же работало.

Правда когда стали разбираться с плохим DSP приемом, то потребовалось увеличить частоту семплирования в 8 раз. И вся эта тупая затея с прерываниями на каждый отсчет тут же завяла. В МК с производительностью в 160 МИПС. 

А ума хватило подключить быстрый сигнал к инжектированному каналу, а практически постоянный сигнал к регулярному. А инжектированный с ДМА не работает.

Ну и нахера нам такие "эмбеддеры"?  Ну и нахера нам такое "работает"?

Я уже молчу про стиль программирования, когда априори полагается, что 160 МИПС все на свете переварят. А оно вононочо... 

2 часа назад, ARV сказал:

Достаточно посмотреть в листинг

По каждому случаю туда смотреть? Может просто стиль программирования изменить. Тогда и смотреть никуда не придется...

Ну а по поводу двойного отрицания я уже все сказал. Дело там не в размере кода. Дело в отвратительном птичьем языке, который создает проблемы всем, кроме автора этого языка. Но если автору на это наплевать, то прокатит любая нечисть.

[ARV]

2 часа назад, my504 сказал:

Ну и нахера нам такие "эмбеддеры"?  Ну и нахера нам такое "работает"?

А ведь вопрос надо ставить иначе: нахера вам такие постановщики задач, которые не в состоянии определиться заранее с частотой семплирования?

Какие претензии к эмбеддеру, если вы поменяли ТЗ?! Или в нем было оговорено, что частота семплов может варьироваться на порядок, да еще в большую сторону?! Кто сам себе злобный буратина?!

2 часа назад, my504 сказал:

Может просто стиль программирования изменить. Тогда и смотреть никуда не придется

Да ну?! Вы наизусть знаете, в какой код компилируется каждая конструкция Си при каждом варианте оптимизации?! Не, я согласен, бывают и гении... Но чаще повышенным самомнением страдают отнюдь не они.

2 часа назад, my504 сказал:

Дело в отвратительном птичьем языке,

Может быть, стоит прекратить рассуждать о ЛИЧНЫХ пристрастиях, и перейти на язык ТРЕБОВАНИЙ? Например, требований стандарта, или хотя бы каких-то общеизвестных книг и т.п.? На вкус и цвет, как говорится, не накинешь платок. Если двойное отрицание не соответствует чему-либо из стандарта, или противоречит рекомендациям из книг - прошу примеры. А критиковать, что прием программирования плох лишь тем, что вы привыкли к иному - это просто неприлично.

[my504]

2 часа назад, ARV сказал:

А ведь вопрос надо ставить иначе: нахера вам такие постановщики задач, которые не в состоянии определиться заранее с частотой семплирования?

Какие претензии к эмбеддеру, если вы поменяли ТЗ?! Или в нем было оговорено, что частота семплов может варьироваться на порядок, да еще в большую сторону?! Кто сам себе злобный буратина?!

Даладна, милейший, Вы так шутите? Вы вообще понимаете смысл слова "эмбеддер"? 

ТЗ, в данном случае, - это радиочастотная противокражная система. От начала до конца. И выбор ВСЕХ решений - от общего алгоритма до размещения последнего резистора на п/п - это задача инженера-эмбеддера.

В ТЗ не оговаривают частоту семплирования, как не оговаривают схемотехнику и алгоритмы. Он тупо просрал тему. В результате изделие к оговоренному сроку не вышло. Человека уволили и теперь я подтираю за ним финансовые потери компании.

Добрый Вы наш, буратина... 

2 часа назад, ARV сказал:

Да ну?! Вы наизусть знаете, в какой код компилируется каждая конструкция Си

Для этого не надо ничего знать наизусть. Просто нужно понять смысл инструкций процессора. Почему система команд такая, а не другая. И тогда с вероятностью практически 100% вы поймете как синтаксические конструкции Си превращаются в машинный код. Там нет ничего сакрального. И оптимизация тут совершенно не причем. Компилятор при оптимизации не изменяет последовательности исполнения в Си. Оптимизация устраняет лишние регистровые пересылки и ветвления, которые позволяют производит отладку кода в пошаговом режиме.

=========================

ЗЫ. Для ВАШЕЙ эрудиции. ТЗ никогда не пишет заказчик. Заказчик пишет ИСХОДНЫЕ ДАННЫЕ. А по этим исходным данным ПОДРЯДЧИК пишет ТЗ. Которое затем утверждает представитель Заказчика. И по завершении НИОКР на базе ТЗ подрядчик пишет ТУ. В состав которых входят методики испытаний по этому ТУ.

Заказчик вообще может ничего не понимать в технике. В исходных данных пишутся ВНЕШНИЕ требования к изделию. Дальность обнаружения, допустимые уровни помех,, типы целей, потребляемая мощность, габаритные размеры, условия эксплуатации. Заказчик строительства дома не знает ничего про типы гидроизоляции фундамента... 

Изменено 30 июня, 2020 пользователем my504

[ARV]

36 минут назад, my504 сказал:

это задача инженера-эмбеддера

Ну, если у вас нет нормального штата разработчиков... тады ой. Свалить все на единственного эмбеддера - это ваш путь.

36 минут назад, my504 сказал:

вы поймете как синтаксические конструкции Си превращаются в машинный код

Ох и буйная у вас фантазия... Синтаксические конструкции Си закладывались в те времена, когда даже конвейер в процессоре был фантастикой, что уж говорить о том, как сегодня изменились процессоры. И машинный код для разных платформ совершенно по-разному генерируется компилятором. Например, аккумулятор-ориентированные системы команд и системы с регистровым файлом - они что, одинаково ложатся на синтаксические конструкции Си?! Системы с аппаратным стеком вызовов и "обычные" - они тоже одинаково превращаются в машинный код?! Даже передача параметров в функции и то реализуется по-разному для разных платформ! Чего там и говорить про то, что строя конструкцию из операторов Си можно что-то там предположить на счет оптимальности полученного кода... Помнится, в 90-е годы среди программистов ходили байки о том, что быстрее - for или while или do для одинаковых алгоритмов... А сегодня все три варианта пратически в 99% случаев дают абсолютно идентичный код! Не так давно (лет 15 назад) читал статью о вреде оптимизации... Дескать, все сталкивались с ситуацией, когда отладочная версия работает, а релизная, т.е. для которой оптимизации все активируются, лажает - это потому, что оптимизация вредит... А что теперь?

А вы всё несете ахинею о прямой свзи между оператором Си и полученным кодом...

Изменено 30 июня, 2020 пользователем ARV

[my504]

29 минут назад, ARV сказал:

Ну, если у вас нет нормального штата разработчиков... тады ой. Свалить все на единственного эмбеддера - это ваш путь.

А что такое "нормальный штат разработчиков"?   

Я например, за то время, которое этот "эмбеддер" профукал тему, выпустил ЧЕТЫРЕ разных серийных изделия аналогичной сложности и одно из них успел модернизировать по опыту эксплуатации. Даже и не представляю себе зачем нужен второй или третий человек в теме?  Я знаю как организована работа у конкурентов, в том числе и за границей. Совершенно так же. Если конторе хочется содержать бездельников за копейки, то она может и десяток человек нанять.... 

ЗЫ Не надо мне петь песни про регистры и конвейер. Я в курсе. Патамушта пишу и на АСМе и на Си. И под разные платформы. Еще раз. Ничего сакрального. Если знаешь систему команд и архитектуру, то понять что генерит компилятор можно без труда. Взглянуть несколько раз на дизасм в разных типовых конструкциях и далее можно особенно не смотреть.

Изменено 30 июня, 2020 пользователем my504