Последовательность действий - побитовая инверсия и сдвиг, (~PIND) >> 4 == ~(PIND >> 4) ??? Опции

[Dx!]

Компилятор WinAVR-20090313

Неужели ((~PIND) >> 4) и (~(PIND >> 4)) должны давать одинаковый результат?

PIND у меня равен 0b1110????

~(PIND >> 4) получается 0b11110001 как и должно быть.

(~PIND) >> 4 получается тоже 0b11110001, хотя мне кажется должно быть 0b00000001

Я ошибаюсь?

[Dx!]

Как заключение - остановился на варианте
somevar = (uint8_t)(~PIND) >> 4;
ибо

Код

----------------------------------------------------
    PORTB = (~PIND) >> 4;
  80:    89 b1           in    r24, 0x09; 9
  82:    90 e0           ldi    r25, 0x00; 0
  84:    80 95           com    r24
  86:    90 95           com    r25
  88:    95 95           asr    r25
  8a:    87 95           ror    r24
  8c:    95 95           asr    r25
  8e:    87 95           ror    r24
  90:    95 95           asr    r25
  92:    87 95           ror    r24
  94:    95 95           asr    r25
  96:    87 95           ror    r24
  98:    85 b9           out    0x05, r24; 5
----------------------------------------------------
    PORTB = ((~PIND) >> 4)&0xf;
  80:    89 b1           in    r24, 0x09; 9
  82:    90 e0           ldi    r25, 0x00; 0
  84:    80 95           com    r24
  86:    90 95           com    r25
  88:    95 95           asr    r25
  8a:    87 95           ror    r24
  8c:    95 95           asr    r25
  8e:    87 95           ror    r24
  90:    95 95           asr    r25
  92:    87 95           ror    r24
  94:    95 95           asr    r25
  96:    87 95           ror    r24
  98:    8f 70           andi    r24, 0x0F; 15
  9a:    85 b9           out    0x05, r24; 5
----------------------------------------------------
    PORTB = ((~PIND)&0xff) >> 4;
  80:    89 b1           in    r24, 0x09; 9
  82:    80 95           com    r24
  84:    90 e0           ldi    r25, 0x00; 0
  86:    95 95           asr    r25
  88:    87 95           ror    r24
  8a:    95 95           asr    r25
  8c:    87 95           ror    r24
  8e:    95 95           asr    r25
  90:    87 95           ror    r24
  92:    95 95           asr    r25
  94:    87 95           ror    r24
  96:    85 b9           out    0x05, r24; 5
----------------------------------------------------
    PORTB = ((uint8_t)(~PIND)) >> 4;
  80:    89 b1           in    r24, 0x09; 9
  82:    80 95           com    r24
  84:    82 95           swap    r24
  86:    8f 70           andi    r24, 0x0F; 15
  88:    85 b9           out    0x05, r24; 5
----------------------------------------------------
    PORTB = (uint8_t)(~PIND) >> 4;
  80:    89 b1           in    r24, 0x09; 9
  82:    80 95           com    r24
  84:    82 95           swap    r24
  86:    8f 70           andi    r24, 0x0F; 15
  88:    85 b9           out    0x05, r24; 5
----------------------------------------------------
    uint8_t tmpD;
    tmpD = PIND;
  80:    89 b1           in    r24, 0x09; 9
    tmpD = ~tmpD;

    PORTB = tmpD >> 4;
  82:    80 95           com    r24
  84:    82 95           swap    r24
  86:    8f 70           andi    r24, 0x0F; 15
  88:    85 b9           out    0x05, r24; 5
----------------------------------------------------

Даже swap а не тупо сдвиг. Компиленно с -O2.

Сообщение отредактировал Dx! - Sep 30 2010, 09:12

[rezident]

Как заключение - остановился на варианте
somevar = (uint8_t)(~PIND) >> 4;

Вы еще один вариант не проверили

Код

somevar = (PIND^0xFF) >> 4;

[777777]

Вы еще один вариант не проверили

Код

somevar = (PIND^0xFF) >> 4;

Какая разница? Все равно он приводит операнды к типу int

[rezident]

Какая разница? Все равно он приводит операнды к типу int

Не обязательно. Зависит от платформы, компилятора и оптимизации. На MSP430, например, преобразуется в команды работы с байтами, а не словами.

[777777]

Не обязательно. Зависит от платформы, компилятора и оптимизации. На MSP430, например, преобразуется в команды работы с байтами, а не словами.

Да, кейл тоже творчески подходит к стандарту и знает где можно от него отойти ради более эффективного кода. А гцц слишком тупо ему следует.

[Petka]

Да, кейл тоже творчески подходит к стандарту и знает где можно от него отойти ради более эффективного кода. А гцц слишком тупо ему следует.

Не бывает тупого следования стандарту.

Бывает либо соответствие стандарту, либо несоответствие стандарту.
Если компилятор не соответствует стандарту, то одинаковый код на разных платформах будет давать разный результат.

[777777]

Не бывает тупого следования стандарту.

Бывает либо соответствие стандарту, либо несоответствие стандарту.
Если компилятор не соответствует стандарту, то одинаковый код на разных платформах будет давать разный результат.

Все верно. Но бывают случаи, когда несоответствие стандарту дает лучшие результаты, чем соответствие. В частности, стандарт требует при выполнении операций приводить операнды к типу int. Может это и хорошо когда размер int соответствует естественному размеру переменной на данной платформе. Но в 8-разрядных процессорах это не так - int не может быть 8-битным, а выполнение операций в 16-разрядных переменных приводит к неэффективности кода.
Другой пример - различные адресные пространства. Стандарт предназначен для машин фон-неймановской архитертуры и ничего не хочет знать о том, что указатель может указывать как на пространство кода, так и на пространство данных. А в кейле можно объявить указатель на нужное нам пространство и просто разыменовывать его *p безо всяких уродских pgm_read_byte и компилятор генерирует нужный код в зависимости от типа указателя.

[Сергей Борщ]

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

Стандарт не запрещает компилятору выкинуть в процессе оптимизации действия, не влияющие на результат. Что мы и видели на примере выражения PORTB = (PIND^0xFF) >> 4; То, что он не пришел к такому же коду на других выражениях - говорит лишь о несовершенстве оптимизатора, но никак не о кривости стандарта. Если компиляторы соответствуют стандарту - результат работы скомпилированного на любом из них кода будет одинаков (оптимальность кода стандарт не оговаривает). А вот если компиляторы нарушают стандарт - счастливой отладки и забудьте о переносимости.

[777777]

(оптимальность кода стандарт не оговаривает).

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

А вот если компиляторы нарушают стандарт - счастливой отладки

Я некоторое время программировал на кейле для 51-го - очень приятный компилятор несмотря на несоответствие стандарту. Просто к нарушению стандарта нужно подходить с умом.

и забудьте о переносимости.

Какая переносимость, о чем вы?! Все носятся с этим флагом, хотя прекрасно понимают, что никакой переносимости сейчас нет и она никому не нужна. Даже перенести с WinAVR на IAR вы не сможете - библиотеки, специфичные для контроллера, никто не стандартизировать не собирается. Да и куча мелких фич типа обращения к программной памяти или к отдельным битам порта у всех делается по-разному. Или может вы собираетесь в некотором устройстве поменять AVR на ARM и перенести туда свою программу? Это еще смешнее. Тут вообще о переносимости нет смысла говорить, это будет совершенно другая программа.
Давайте уж честно скажем себе: единственное, для чего нужен язык высокого уровня - для облегчения программирования. Чтобы при программировании думать об алгоритме, а не о регистрах, методах адресации и их ограничениях. А раз так, то он должет быть максимально приспособлен под платформу, а не под абстрактный стандарт.

[xelax]

Какая переносимость, о чем вы?! Все носятся с этим флагом, хотя прекрасно понимают, что никакой переносимости сейчас нет и она никому не нужна. Даже перенести с WinAVR на IAR вы не сможете - библиотеки, специфичные для контроллера, никто не стандартизировать не собирается. Да и куча мелких фич типа обращения к программной памяти или к отдельным битам порта у всех делается по-разному. Или может вы собираетесь в некотором устройстве поменять AVR на ARM и перенести туда свою программу? Это еще смешнее. Тут вообще о переносимости нет смысла говорить, это будет совершенно другая программа.
Давайте уж честно скажем себе: единственное, для чего нужен язык высокого уровня - для облегчения программирования. Чтобы при программировании думать об алгоритме, а не о регистрах, методах адресации и их ограничениях. А раз так, то он должет быть максимально приспособлен под платформу, а не под абстрактный стандарт.

Полнейшая чушь.

Переносимость не то что ВАЖНА, а без неё в принципе никак нельзя. Слишком узко мыслите, в рамках своих локальных задач. Посмотрите на успешные проекты различных кроссплатформенных операционок, различных сетевых стеков, всевозможных библиотек и т.д.. Без стандарта реализация подобных проектов была бы немыслима. Если следовать стандарту С и писать код на чистом как слеза С, то 99% вероятностью, код скомпилируется и заработает на любой платформе (1% на hardware features). Например мы сейчас имеем код который работает на 5 различных архитектурах (AVR, AVR32, ARM7, Cortex, x086) и собирается без проблем двумя компиляторами IAR и GCC.
А ещё забыл, на писишке ещё в Visual Stidio всё собирается, но это так баловство было, для теорет. исследований.