Digispark + ds18b20 + шим

Тема в разделе "Микроконтроллеры AVR", создана пользователем kirill_vector, 29 июн 2024.

  1. ИгорьК

    ИгорьК Гуру

    Мне нравится ход ваших мыслей. Но это не моя тема. Раз работает - значит все ок.

    Пы.Сы. Не, не нравится. в данной ситуации не сработает правило "от перемены мест слагаемых..."
    Если разбить операцию на три шага, из которых она и состоит, оно не получится.
    Слава компилятору!
     
    Последнее редактирование: 1 июл 2024
  2. parovoZZ

    parovoZZ Гуру

    C - очень низкоуровневый язык. Писать на нём с отрывом от архитектуры вычислительного ядра не получится.
     
    ИгорьК нравится это.
  3. DetSimen

    DetSimen Гуру

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

    Микрасофт пишет:
    целочисленные преобразования операндов выполняются следующим образом.

    • Если какой-либо из операндов имеет тип unsigned long, то другой операнд преобразуется в тип unsigned long.

    • Если вышеуказанное условие не выполняется, при этом один из операндов имеет тип long , а второй — тип unsigned int , то оба операнда преобразуются в тип unsigned long .

    • Если два вышеуказанных условия не выполняются, а один из операндов имеет тип long , то второй операнд преобразуется в тип long .

    • Если три вышеуказанных условия не выполняются и какой-либо из операндов имеет тип unsigned int, то другой операнд преобразуется в тип unsigned int.

    • Если ни одно из вышеуказанных условий не соблюдается, то оба операнда преобразуются в тип int.
     
    Последнее редактирование: 1 июл 2024
    KindMan и ИгорьК нравится это.
  4. ИгорьК

    ИгорьК Гуру

    ... вечер переставал быть томным :)
    Значит не компилятор? :)
     
  5. parovoZZ

    parovoZZ Гуру

    на восьмибитках?
     
  6. Asper Daffy

    Asper Daffy Иксперд

    Да, скорее всего.

    Писец, кстати, он вот такой:

    [​IMG]
     
    DetSimen нравится это.
  7. Asper Daffy

    Asper Daffy Иксперд

    Да, а что?

    Какая разница сколькибитки, если это требование языка?
     
    DetSimen нравится это.
  8. Asper Daffy

    Asper Daffy Иксперд

    Нет.
     
  9. Asper Daffy

    Asper Daffy Иксперд

    Языку.

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

    Код (C++):
    int a[10];

    // Вот это
    for (int i = 0; i < 10; i++)  a[i] = i+101;

    // 100% эквиваленто вот этому
    for (int i = 0; i < 10; i++)  i[a] = i+101;
    Ну, разве не прелестно? :):):):)
     
    DetSimen и ИгорьК нравится это.
  10. parovoZZ

    parovoZZ Гуру

    потому как размерность слова связана с размерностью шины процессора.
     
  11. parovoZZ

    parovoZZ Гуру

    это сахар. И я бы его точно нигде не использовал потому как во втором случае массив из цикла не вытащишь.
     
  12. DetSimen

    DetSimen Гуру

    со времен седой древности (помнишь i8031, i8080? А я помню) принято, что int по умолчанию имеет размер указателя, поэтому он, канеш, зависит от ширины шины, но не шины данных, а шины адреса.
     
    ИгорьК нравится это.
  13. ИгорьК

    ИгорьК Гуру

    Зззххххх, вырвались кони на свободу!

    Код (C++):
    int a[10]; // Массив а из десяти элементов

    // Вот это
    for (int i = 0; i < 10; i++)  a[i] = i+101; // Так дохтор прописывает

    // 100% эквиваленто вот этому
    for (int i = 0; i < 10; i++)  i[a] = i+101;  // В скобках(!) локальный i, что гуляет от 0 до 9
    // А (необъявленный массив???) "i[?]" после скобок - требует объяснения и уголовной ответственности по статье 117 за истязание кода и кодеров.
     
     
  14. Asper Daffy

    Asper Daffy Иксперд

    Вы меня не слышите. Приводить к "не короче, чем int" - требование ЯЗЫКА. Каким боком тут шины, процессоры и прочие мультиплексоры?

    В принципе, теоретически, разработчики компилятора для восьмибиток имели полное право сделать int восьмибитным. Но раз уж они его сделали 16-тибитным, то будьте любезны ... иначе это будет другой язык. В этом языке операнды сдвига должны приводиться к типу "не короче int".
     
    Последнее редактирование: 2 июл 2024
  15. Asper Daffy

    Asper Daffy Иксперд

    Ни разу. Это фундаментально свойство операции сложения - коммутативность.
    Сахар здесь - сама по себе операция взятия элемента по индексу.
    Я не понимаю, что означает фраза "массив из цикла не вытащишь", но опять же отмечу, что Вы меня не слышите. Как я уже сказал, эти два случая абсолютно эквивалентны. Если что-то вытащишь (не вытащишь) в одном, то тоже самое и в другом.

    Написать a[3] или 3[a] - абсолютно одинаково - никакой разницы!
     
  16. Asper Daffy

    Asper Daffy Иксперд

    Ещё хлеще написать 3[a] вместо a[3]. Видимо, массив 3 - не объявлен :)))
     
  17. ИгорьК

    ИгорьК Гуру

    Нельзя интригу заводить так далеко. Отбивает желание читать учебники: "сколько ни учись, все равно дураком помрешь"
     
  18. DetSimen

    DetSimen Гуру

    Наданапицца.
     
    Airbus и ИгорьК нравится это.
  19. Asper Daffy

    Asper Daffy Иксперд

    Блин, простите, я был уверен, что Вы всё знаете, просто подыгрываете мне.

    Ну, там всё просто, в С++ (и в С тоже) на самом деле нет как таковой операции «взятие элемента по индексу», вернее, она есть, но она производная - определена через операцию сложения (тот самый «синтаксический сахар»).

    Давайте посмотрим документ ISO/IEC 14882:2020.

    В §7.6.1.2(1) прямоговорится: «... The expression E1[E2] is identical (by definition) to *((E1)+(E2)) ...».

    Т.е. операция взятия элемента по индексу определяется («by definition»!!!) как сложение указателя с индексом с последующим разыменованием. Сложение же, как известно, коммутативно – ему не важен порядок следования операндов!

    Здесь, можно было бы и остановится. Если это, на самом деле, сложение, то не должно быть никакой разницы между a[3] и 3[a]. Первое эквивалентно *(a+3), а второе – *(3+a) – разницы никакой. Но, поскольку это необычно, авторы стандарта решили дать отдельное, особое пояснение на этот счёт. Его мы видим в §7.6.1.2(3): «Despite its asymmetric appearance, subscripting is a commutative operation».

    Всё! Операция взятия элемента по индексу коммутативна, это сказано прямым текстом. Вопрос закрыт!

    Дальнейшее можно не читать, если не хотите вдаваться в
    Когда я говорю, что между a[3] и 3[a] нет никакой разницы, я всё-таки немного лукавлю. Разница есть, но она очень тонкая. Дело в том, что для операции сложения порядок вычисления операндов не определён, а вот для взятия по индексу – определён: при подготовке операндов выражения E1(E2), E1 вычисляется раньше, чем E2. Иногда это важно.

    Например, если процедуры вычисления E1 и E2 содержат побочные эффекты, то эффекты E1 будут влиять на вычисление E2, а не наоборот. Пример нужен? Мне не трудно.

    Тот факт, что «E1 вычисляется раньше, чем E2» может также повлиять на эффективность кода в случае автоматического распараллеливания на многоядерных установках. Вот смотрите, если мы напишем через сложение: *((E1)+(E2)), компилятор может организовать параллельное вычисление E1 и E2 – например, раскидать их вычисление по разным ядрам (т.к. при сложении порядок вычисления операндов не определён). А вот если мы напишем E1[E2], то хренушки – он обязан гарантировать, что E1 будет вычислено раньше, чем E2.
     
    Последнее редактирование: 2 июл 2024
    DetSimen, KindMan и ИгорьК нравится это.
  20. ИгорьК

    ИгорьК Гуру

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

    В учебнике нет таких тонкостей. Постоянно в моей памяти лишь что название массива - указатель на его адрес. Доступ возможен сложением с указателем, еще немного таких же неглубоких знаний, но они позволяют писать код IFTTT.

    Программирование на языке ХХХ(любом) - не мое хобби.

    А за таблетницу - еще одно спасибо. Полгода на аккумуляторе 18650 - полет нормальный. Выручает :)
     
    KindMan нравится это.