Кому должна? Ведь тело функции может находиться и в другой единице компиляции. Откуда в таком случае компилятор узнает, что вы в ней обращаетесь к volatille-объектам? Я полагаю, что для получения правильного поведения функция должна быть описана как int NegPort() voltile {}. "И сразу польется вода" © Тот самый Мюнхгаузен.

Хорошо, есть функция rand() которая определена в другой единице компиляции,
в стандартной библиотеке.
Определена она так int rand(void) , т.е. без всяких volatile.

Вопрос:
Могу ли я написать у себя в программе
А = rand() + rand(); ?
или компилятор может вызвать rand только один раз ?

Проконсультировался с ReAl - в С функция не может иметь атрибута volatile, это я с плюсами попутал: Так что тут вы правы - компилятор не может заменить два i2c_read() или NegPort() на один. Признаю, вводил в заблуждение.

Это заставило вновь внимательно посмотреть листинг из поста №7 - и что мы видим? Мы не видим там одного вызова i2c_read() - мы видим, что вызов(ы) i2c_read() происходят в подпрограмме ?Subroutine0, содержимое которой нам не показали. Видимо подобная конструкция используется в файле не один раз и компилятор посчитал оптимальным вынести ее в отдельную подпрограмму. Ставлю себе большую двойку за невнимательность.
Так что вопрос - ошибся тут компилятор или нет остается открытым до обнародования листинга ?Subroutine0

Возможно Вы правы насчет объединения двух вызовов в отдельную подпраграмму,
только тогда очень странно выглядит LDI R25,0 после подпрограммы...

Автор, выложите более полный листинг.

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


Добавлено

Прошу прощения, но теперь в данном lst функция i2c_read(ACK) вызывается дважды. Хотя готов поклясться, что в посте №7 функция вызывалась один раз. Попытаюсь воспроизвести ту ситуацию еще раз. Листинги я не сохранил, к сожалению.

Еще раз добавлено

Вот , восстановил (asdx-2). Возможно я был не внимательный, когда говорил, что функция вызывается один раз. Кстати, вопросик по ходу: как лучше писать


В последний раз добавлено

Прокоментируйте, пожалуйста следующее:

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

К сожалению Вы востановили не до конца,
перед обсуждаемыми строками у Вас еще стоят:
44 HiTemp=i2c_read(ACK);
45 LowTemp=i2c_read(NACK);
которые и мешают отработать оптимизатору так же как и было в самом первом листинге...
ИМХО, в данном случае пофиг, но в общем и в целом лучше в таких случаях
пользоваться |, так и вероятность ошибок меньше и скорость работы может быть выше,
все зависит от конкретного компилятора.
Порядок то здесь наверняка нарушен(наверное мы чуть запутали Вас нашим обсуждением),
в Вашем случае все равно нужно делить эти вызовы на два разных оператора, те первый ответ
данный Сергей Борщ был абсолютно правильный.
Тока вот все равно какая то фигня творится, LDI R25,0 здесь просто не должно быть...

Этот листинг формируется, если перед этим убрать вызовы функций:

Как узнать, в какой регистр возвращает первый и второй CALL i2c_readAck ? Мне кажется, что в результате младший и старший байты перепутаны местами.
MOV R24, R16
LDI R25, 0
это есть:
((unsigned int)i2c_read(ACK)<<8) ?

Никак. Сергей Борщ с самого начала дал правильный ответ.
Порядок вычисления подвыражений неопределён для всего, кроме . Точка. Это не имеет никакого отношения к порядку группирования операций слева направо или наоборот.
Сразу, чтобы не было иллюзий по поводу function call () ( "скобок вызова функции", круглые скобки выполняют роль cast operator, parentheses punctuator и function-call operator, в данном случае об этом)

Ну так вот, независимо от порядка группирования операторов op (за исключением перечисленных выше операторов) в следующем выражении
порядок вызова функций неопределён. Могут вычисляться в порядке группирования, могут быть вызваны все три в противоположном порядке, а потом будут произведены вычисления. Отдано на откуп реализации. "вероятнее всего" будут вызываться в порядке группирования, но я бы не стал закладываться.
Поэтому правильный вариант либо как указал Сергей, либо

А вот в этих местах что лучше писать - как правило, лучше ИЛИ.

В один и тот же. В регистр, принятый в компиляторе для возврата байтовых значений из функций.
Просто результат первого вызова по какой-то причине игнорируется вообще (но вызов сделан, ибо компилятор лишён информации о том, имеет ли данная функция побочные эффекты и поэтому обязан сделать вызов). А результат второго вызова из R16 приводится к беззнаковому целому в паре R25:R24
Почему так - совершенно непонятно.
Покажите (без ассемблера, С-шный исходник) - объявления функций i2c_* и тело этой функции, в коде которой бардак выходит.
У IAR-а случайно нет какого-то ключика/галочки - сделать int 8-битовым? Очень похоже, что ((unsigned int)i2c_read(ACK) << 8) считается равным 0

На счет галочек... Не нашел такого, чтоб "сделать int 8-битовым". Единственное, что нашел,- в закладке C/C++ Compiler->Language->Language conformance выбрано Allow IAR extantion; Plain char is -> unsigned; Enable multybyte support -> оставлено по-умолчанию (пустым).


Вот пример вызова. Все ли здесь правильно? i2c_stop(); - правильно или вынести в общий цикл. Напоролся на такую проблему. Хоть и написано что данный сенсор "The ASDX family uses I2C compatible protocol" , но он не читает последовательность байтов. Т.е. перед каждой парой байт необходимо делать RESTART. Обязательно ли после приема пары байтов делать STOP? Или оставить как есть. - это скорее для красоты. Ведь ИЛИ с нулем ничего не изменяет.

Я немного цитаты перетасую

И не надо. Просто если бы она была и стояла, то это могло привести к некоторым глупостям, отдалённо напоминающим то, что было.

Так для этого случая, с промежуточными переменными - вроде бы, всё было нормально?
И ещё - в предыдущих примерах было ACK в обеих строках.


О-о-о-о!!!
Давно не видел грабелек со столь любовно отполированной ручкой
Получил массу удовльствия
Значит так:

Т.е. вся первая тернарная операция входит в условие второй.
Дальше выполняется следующее
Константа ACK приводится к unsigned int и проверяется на 0.
Она не 0, поэтому вызывается i2c_readAck(), но ничего не сдвигается - сдвиг "прилип" к вызову в ветви "ЛОЖЬ" тернарной операции.
Результат первой тернарной операции "заиливается" с ACK и проверяется на 0.
Поскольку ACK не равно 0, эту битовую операцию "ИЛИ" можно и не производить, и так ясно, что будет не 0.
Итого от строки /* 1 */ остаётся только вызов i2c_readAck() (нельзя убрать, несмотря на то, что результат не используется) и к началу строки /* 2 */ мы получаем условие "ИСТИНА", в результате чего вызывается ещё раз i2c_readAck() и уже её результат приводится к unsigned, что и было в итоговом коде.

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

Но всё равно в данном случае как минимум одна временная переменная нужна, см. мой предыдущий пост. Иначе рано или поздно будет радостная встреча с каким-то компилятором, который сделает "неожиданный", но допустимый стандартом порядок вызова функций.

это я сделал специально для чистоты эксперимента
ReAl - ну Вы просто гигант мысли . Вам огромный

Я тоже получил массу удовольствия от этого объяснения.

Позвольте реабилитироваться и внести свой вклад:
Кажется так может быть эффективнее. А может и нет. Надо смотреть листинг.

Ну у меня вообще не так, у меня read сразу с указателем и длиной, а внутри цикла что-то в духе

Всё равно по одному байтику практически никогда не читается, а если вдруг надо - то не так и страшно вызвать с указателем и длиной 1.