esaulenka 7 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 4 hours ago, khlenar said: if(~(ind | 0xFE)) Вот у одного меня возникает вопрос "что хотел сказать автор" ? Как мне кажется, if (! (ind & 0x01)) куда более читаемо (и компилируется сразу без ошибок). О том, что, например, ind & 0x04 понятнее, чем ind | 0xFB, вообще молчу... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 3 часа назад, Палыч сказал: При вычислении ~((uint8_t)(ind|0xFE)) перед выполнением оператора ~ значение (uint8_t)(ind|0xFE) снова будет преобразовано к типу int. Неправда. Будет приведено к unsigned int. Хотя это и несущественно. И char - это необязательно знаковый 8-битный. Он может быть и беззнаковым. В зависимости от опций компилятора. 3 часа назад, khlenar сказал: в операторе if(uint8_t) ~(ind | 0xFE)) привел, заработало. Сами то поняли что сделали? Подсказываю: сделали аналог if (~(ind | 0xFE) & 255). В подобных выражениях лучше приводить входящие переменные. Меньше кода на выходе будет... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Палыч 10 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 2 часа назад, jcxz сказал: Неправда. Будет приведено к unsigned int. Цитата из стандарта ISO/IEC 9899:2011 (E) пункт 6.3.1.1 абзац 2 Цитата If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. Все-таки будет приведено к int. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 49 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 2 часа назад, Палыч сказал: Цитата из стандарта ISO/IEC 9899:2011 (E) пункт 6.3.1.1 абзац 2 Все-таки будет приведено к int. Чет сам затупился, если переменные ind типа uint8_t, выражение в скобках приводится к виду (uint8_t) , 0xFE - тоже укладывается в разрядную сетку типа uint8_t, какого рожна там должно быть int ?? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 2 часа назад, Палыч сказал: Цитата из стандарта ISO/IEC 9899:2011 (E) пункт 6.3.1.1 абзац 2 Все-таки будет приведено к int. Почему тогда IAR компилит так?: ; LogChar0((u8)(ind | 0xF0) >> 1); 0x.... LDR.N R0,??DataTable11_27 0x7800 LDRB R0,[R0, #+0] 0xF050 0x00F0 ORRS R0,R0,#0xF0 0xB2C0 UXTB R0,R0 ;; ZeroExt R0,R0,#+24,#+24 0x0840 LSRS R0,R0,#+1 Ведь если после (u8)(ind | 0xF0) должно получаться int, то компилятор должен использовать ASRS, а не LSRS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Палыч 10 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 47 минут назад, mantech сказал: Чет сам затупился, ... какого рожна там должно быть int ?? По порядку: 1. Тип переменой ind - uint8_t или, что то же самое - unsigned char; тип константы 0xFE - int (см. п.6.4.4.1 абзац 5 стандарта). 2. При вычислении (ind|0xFE), поскольку типы разные, то приводятся к "большему" - к int. Результат - типа int. 3. Далее (uint8_t)(ind|0xFE) - тип явно приводится к uint8_t (unsigned char). 4. И наконец ~((uint8_t)(ind|0xFE)). Перед операцией ~ над операндом с типом unsigned char производится неявное преобразование - "integer promotions". Правило преобразования я цитировал выше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khlenar 5 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба А , что лучше, (uint8_t)temp или temp & 0xFF ? Или компилятор преобразует (uint8_t)temp в temp & 0xFF ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 3 минуты назад, khlenar сказал: А , что лучше, (uint8_t)temp или temp & 0xFF ? Без разницы. Откройте уже наконец-то окно дизассемблера! Вам уже много сообщений назад это советовали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
khlenar 5 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 1 минуту назад, jcxz сказал: Без разницы. Откройте уже наконец-то окно дизассемблера! Вам уже много сообщений назад это советовали. Я как то не вникал в ARMовский ассемблер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 49 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 1 час назад, Палыч сказал: тип константы 0xFE - int (см. п.6.4.4.1 абзац 5 стандарта). Остальное понятно, но вот это странно для меня, уж коли компилятор оптимизирующий, то почему б не оптимизировать числа в соотв. с разрядной сеткой... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 36 минут назад, mantech сказал: уж коли компилятор оптимизирующий, то почему б не оптимизировать числа в соотв. с разрядной сеткой... Он и оптимизирует, если результат не будет отличаться от того, который получился бы с применением всех этих правил. Поэтому когда вы напишете (uint8_t)~(ind|0xFE) - старший байт результата усекается, на результат выражения не влияет и вычисляться скорее всего не будет. а когда пишете ~((uint8_t)(ind|0xFE)) - влияет и вычисляется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 22 апреля, 2019 Опубликовано 22 апреля, 2019 · Жалоба 2 hours ago, jcxz said: Почему тогда IAR компилит так?: Потому что он знает, что этот int никогда не может быть отрицательным, и нет никакой разницы, применять ASRS или LSRS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться