Термостат с развитием

Nord_Air
Offline
Зарегистрирован: 15.06.2020

 под 33кгц, пишут только отцы... :)  Это бесспорно  .  БЕЗ САРКАЗМА,  :) серьезно

mykaida
mykaida аватар
Offline
Зарегистрирован: 12.07.2018

Nord_Air пишет:

 под 33кгц, пишут только отцы... :)  Это бесспорно  .  БЕЗ САРКАЗМА,  :) серьезно

Закроем эту тему. Я писал под pic16 на этой частоте потому что

- было легко посчитать на пальцах :)

- не надо кварца

- IDE под ассемблер pic16 много лучше, чем его си.

Nord_Air
Offline
Зарегистрирован: 15.06.2020

mykaida пишет:

Закроем эту тему.

 Закроем эту тему на доброй ноте ;)

Будет еще масса злых поводов для обсуждений ;)

mykaida
mykaida аватар
Offline
Зарегистрирован: 12.07.2018

Nord_Air пишет:

Будет еще масса злых поводов для обсуждений ;)

Вот тут не сомневаюсь!

Сойдёмся еще :)

Приятно было поспорить!

Rumata
Rumata аватар
Онлайн
Зарегистрирован: 29.03.2019

Так я пока не нужен? Вот блин, а я уже дуэльный смокинг от нафталина отряхнул ))

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

Nord_Air пишет:

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

  Если реально посчитать то всё сойдется...  в 8 случаях из 10 ;)

Но если немного поразмыслить...  Как сумма четырех байт может вмещаться в один байт???? :))) 

  Да ни как! И ни как она не вмещается :)

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

Nord_Air пишет:

На ассемблере сумма байтов надеюсь от Си сильно не отличается ;)

Вообще-то отличается. И иногда сильно - как раз в том случае, если "не вмещается": в Ассемблере при байтовом сложении все промежуточные (и окончательный) результаты - всегда байты, а в Си - не менее чем двухбайтовые слова.

Nord_Air
Offline
Зарегистрирован: 15.06.2020

andriano пишет:

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

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

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

 Минус там приходит в 4-й или 3-й байт в виде цифры 128. Ну.. вот каг бы такая реализация.... Это факт. А не в виде  первого байта.

 Ну и собсно вопрос? А что ты хотел сказать и на что указать?  Ну допустим реализовно сложение по модулю и чё??? Оно всё равно неправильное.... В конкретной задаче.

 Я могу развернуть тему. Некий автор библиотеки, читал даташит, и на его основе писал библиотеку. Он считал, что при минусе, будут приходить отрицательные значения. Видимо, где первый бит будет зарезервирован под знак.  Его чаянья ясны и понятны, но с действительностью они не имеют ничего общего.

Точно так же он считал и сумму... Но какая разница.??? С модулем или без. Как можно впихнуть в один байт сумму четырех.  Нет я вижу ошибку, и понимаю как оно реализовано... И как нужно считать сумму... Но код библиотек от этого правильнее не становится ;)

andriano пишет:

при байтовом сложении все промежуточные (и окончательный) результаты - всегда байты

 Я не очень пониимаю, что такое промежуточные результаты при сложении...  Оставлю это без комментариев.

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

Nord_Air пишет:

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

В данном случае результат не зависит от того, есть знак или нет.

Цитата:

 Ну и собсно вопрос? А что ты хотел сказать и на что указать?  Ну допустим реализовно сложение по модулю и чё??? Оно всё равно неправильное.... В конкретной задаче.

Почему неправильное то?

Цитата:

Точно так же он считал и сумму... Но какая разница.??? С модулем или без. Как можно впихнуть в один байт сумму четырех.  Нет я вижу ошибку, и понимаю как оно реализовано... И как нужно считать сумму... Но код библиотек от этого правильнее не становится ;)

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

Цитата:

andriano пишет:

при байтовом сложении все промежуточные (и окончательный) результаты - всегда байты

 Я не очень пониимаю, что такое промежуточные результаты при сложении...  Оставлю это без комментариев.

Если мы складываем между собой 4 байта, то первые две суммы у нас промежуточные, а последняя - окончательная (в случае с Ассемблером). А в случае Си все три суммы - промежуточные, а последняя операция уже не суммирование, а присваивание - происходит с усечением старших разрядов. Чего здесь непонятного? Все операции при вычислении любой формулы - промежуточные, кроме одной - самой последней.

progrik
Offline
Зарегистрирован: 30.12.2018

Nord_Air пишет:
Как можно впихнуть в один байт сумму четырех
может просто к checksumm нужно относиться не как к математической сумме, а как к хешу, вроде md5... буков может быть миллиард, а хеш всего 32 символа... тебе же не надо восстанавливать из чексума температуру, только проверить...
чисто для контроля помех в невоенной аппаратуре вполне пригодно. я так думаю)

progrik
Offline
Зарегистрирован: 30.12.2018

andriano пишет:
Если мы складываем между собой 4 байта, то первые две суммы у нас промежуточные, а последняя - окончательная (в случае с Ассемблером). А в случае Си все три суммы - промежуточные, а последняя операция уже не суммирование, а присваивание - происходит с усечением старших разрядов.
и что, есть какой-то шанс, что компилятор/оптимизатор видя byte = byte + byte; откомпилит кам-то иначе, чем просто сложить свои любимые 8bit регистры? не верю)) (это не претензия или недоверие, это неуверенность))
...пойду читану, как исходники кода на ассемблере увидеть, потом их посмотрю, и уже буду увереннее)))

sadman41
Онлайн
Зарегистрирован: 19.10.2016

CRC - не арифметическая сумма, любая википедия в одном абзаце объяснит, что это код вычисляемый по определенному алгоритму. Что за тупняк опять начался...

DetSimen
DetSimen аватар
Offline
Зарегистрирован: 25.01.2017

в далласе также 

    \code
    uint8_t
    _crc_ibutton_update(uint8_t crc, uint8_t data)
    {
	uint8_t i;

	crc = crc ^ data;
	for (i = 0; i < 8; i++)
	{
	    if (crc & 0x01)
	        crc = (crc >> 1) ^ 0x8C;
	    else
	        crc >>= 1;
	}

	return crc;
    }
    \endcode 

 

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

progrik пишет:

и что, есть какой-то шанс, что компилятор/оптимизатор видя byte = byte + byte; откомпилит кам-то иначе, чем просто сложить свои любимые 8bit регистры? не верю))

Читайте стандарт языка.

Впрочем, если "не верю", то даже и не знаю, чем можно Вам помочь.

progrik
Offline
Зарегистрирован: 30.12.2018

andriano пишет:
Впрочем, если "не верю", то даже и не знаю, чем можно Вам помочь.
UPD: (смягчено) результат известен. я говорил о компиляторе/оптимизаторе, а ты тупорылил вместо того, чтобы взять и проверить.

помоги, не пиши херни о которой я не писал! и не вменяй мне того, о чем я не говорил. не тупи, короче. понятно?

 

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

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

Nord_Air
Offline
Зарегистрирован: 15.06.2020

 

Мда...  Я разобрался пока 128 не записал... понятно не стало.

библиотека iarduino неправильно работала из-за неправильного приведения типов. Байт высоких разрядов температуры знаковый и в нем 128 это -1, в стальных байтах 128 это 128. А массив инициилизируется  как какой-то один тип. Читать из датчика нужно как обычные байты , а уже после, правильно складывать.  

 Библиотека амперки рабочая, но решение там довольно топорное. Если 128, то умножаем на -1. Но когда я сам до этого дошел, я сделал точно так же :) Типа ну датчик так работает... :) 

Датчик, теоретически может работать и при температуре ниже -25.5 а это уже не будет обрабатываться этой библиотекой.

 На этом всё, походу мне надо немного отдохнуть от всех этих микроконтроллеров :)

progrik  Изи мен ;)  Здесь все в основном учатся.

progrik
Offline
Зарегистрирован: 30.12.2018

проверил... сверх умным сверх разумам посвящается:

volatile uint8_t x1 = 123;
volatile uint8_t x2 = 231;
volatile uint8_t x3 = 214;
volatile uint8_t x4 = 134;
volatile uint8_t z = x1 + x2 + x3 + x4;

 

ldd	r19, Y+5 // загружаем переменные в регистры
ldd	r24, Y+4 //...
ldd	r18, Y+3 //...
ldd	r25, Y+2 //загрузили переменные в регистры
add	r24, r19 //и погнали складывать
add	r24, r18 //и снова
add	r24, r25 //и снова
std	Y+1, r24 //это результат

как и положено, используются только 8bit...

слава Богу, программисты писавшие компилятор оказались не настолько тупыми, как некоторые, что бревна в своем мозгу не чувствуют)))

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

откуда вы такие вылазите, блин...

progrik
Offline
Зарегистрирован: 30.12.2018

Nord_Air пишет:
На этом всё, походу мне надо немного отдохнуть от всех этих микроконтроллеров :)

progrik  Изи мен ;)  Здесь все в основном учатся.

да, что-то.. нервы обнажены, работаю на износ))
а я устаю не от мк, а от сопутствующего морального ущерба, наносимого всякими сверх разумами - любителями итальянского бренда "Po Diagonalli"))

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

progrik пишет:

проверил... сверх умным сверх разумам посвящается:

volatile uint8_t x1 = 123;
volatile uint8_t x2 = 231;
volatile uint8_t x3 = 214;
volatile uint8_t x4 = 134;
volatile uint8_t z = x1 + x2 + x3 + x4;

 

ldd	r19, Y+5 // загружаем переменные в регистры
ldd	r24, Y+4 //...
ldd	r18, Y+3 //...
ldd	r25, Y+2 //загрузили переменные в регистры
add	r24, r19 //и погнали складывать
add	r24, r18 //и снова
add	r24, r25 //и снова
std	Y+1, r24 //это результат

как и положено, используются только 8bit...

Мы о чем говорим? О Си или об Ассемблере?

Вопрос №1: Зачем здесь volatile?

Когда ответите, вопрос №2: а что будет, если в последней строке заменить uint8_t на uint16_t.

Ну и сразу приведу вопрос №3: а если не на uint16_t, а на float?

Но последний вопрос задан заранее. ) 

Цитата:

слава Богу, программисты писавшие компилятор оказались не настолько тупыми, как некоторые, что бревна в своем мозгу не чувствуют)))

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

откуда вы такие вылазите, блин...

Ds: воинствующее невежество.

 

PS. Для тех, кто умеет читать: конец 46 - начало 47 страницы https://nsu.ru/xmlui/bitstream/handle/nsu/9058/kr.pdf

mykaida
mykaida аватар
Offline
Зарегистрирован: 12.07.2018

progrik пишет:

проверил... сверх умным сверх разумам посвящается:

volatile uint8_t x1 = 123;
volatile uint8_t x2 = 231;
volatile uint8_t x3 = 214;
volatile uint8_t x4 = 134;
volatile uint8_t z = x1 + x2 + x3 + x4;

 

ldd	r19, Y+5 // загружаем переменные в регистры
ldd	r24, Y+4 //...
ldd	r18, Y+3 //...
ldd	r25, Y+2 //загрузили переменные в регистры
add	r24, r19 //и погнали складывать
add	r24, r18 //и снова
add	r24, r25 //и снова
std	Y+1, r24 //это результат

как и положено, используются только 8bit...

Ну я не большой знаток ассемблера AVR, но мне кажется, что тут стоит использовать ADC, а не ADD

progrik
Offline
Зарегистрирован: 30.12.2018

mykaida пишет:
Ну я не большой знаток ассемблера AVR, но мне кажется, что тут стоит использовать ADC, а не ADD
блин, я думал по моим постам понятно, что я сгенерил ассемблерный код из Си-шного, как и собирался... это листинг из микрочип студии, все претензии к разработчикам компилятора))

b707
Offline
Зарегистрирован: 26.05.2017

Норд айр и Прогрик, что за тупняк вы тут устроили...
Один не может понять, как сумма кучи байт может уложиться в 8 бит, другой даже приводит правильный код 8битного сложения и при этом пишет " не аерю".
Кто рассуждал про гайку не в ту сторону крутите? Да вы ребята не то что не туда крутите - вы гайки молотком насаживаете походу
НОРДАЙР, что непонятного а 8битном сложении? Сколько байтов не складывай - сумма всегда меньше 256. Если вы этого не понимаете, то после этого асе авши рассуждения о дырявых даташитах гроша не стоят

progrik
Offline
Зарегистрирован: 30.12.2018

b707 пишет:
Норд айр и Прогрик, что за тупняк вы тут устроили... Один не может понять, как сумма кучи байт может уложиться в 8 бит, другой даже приводит правильный код 8битного сложения и при этом пишет " не аерю".
только меня с "не верю" вычеркни из Тупняка этого. а то тоже резко попадешь в "Po Diagonalli")))
я не верил, что компилятор будет использовать что-то кроме 8 бит для сложения 8 бит данных. проверил -   оказался прав. и _потом_ привел код. где мой тупняк? ты не только порядок перепутал, но и смысл. отделяй мух от котлет. особенный тупняк устроил мой неразумный оппонент andriano, которого ты и не упомянул почему-то... а теперь и ты туда-же...
ВНИМАТЕЛЬНО цитата:
"и что, есть какой-то шанс, что компилятор/оптимизатор видя byte = byte + byte; откомпилит кам-то иначе, чем просто сложить свои любимые 8bit регистры? не верю))"
точно я туплю?
я на 100 процентов подтвердил свои мысли эмпирическим путем. в том числе, что нехер пялиться в учебник, который был написан задолго до появления 8-битных атмег всяких... но чел доколупался до volatile и прочей чуши, не имеющей отношения к делу... double ему за воротник.

задолбали своими тупняками обвинять меня в тупняках. что за бред? сами тупите и тупите, тупите и тупите... пздц)))) я у шоке... точно надо валить с этого замечательного форума...

b707
Offline
Зарегистрирован: 26.05.2017

progrik пишет:

олько меня с "не верю" вычеркни из Тупняка этого. а то тоже резко попадешь в "Po Diagonalli")))

ну в основном мое Фе касалось в основном господина с ником "СеверныйВетер" - это ж надо, 50 с лишком сообщений с вальяжным видом рассуждать о "дырявых даташитах", чтобы в конце вдруг выяснилось, что человек не знает как устроены байты и как работает 8-битное сложение...

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

DetSimen
DetSimen аватар
Offline
Зарегистрирован: 25.01.2017

progrik, ты дэбил, имбецил или просто алигафрэн?

progrik
Offline
Зарегистрирован: 30.12.2018

DetSimen пишет:
progrik, ты дэбил, имбецил или просто алигафрэн?
обоснуй.
но тебе нечем.
тогда просто потри все мои мессаги и забань, долго-ли умеючи...
только не забудь потереть все мои мессаги со всего форума, ладно?

DetSimen
DetSimen аватар
Offline
Зарегистрирован: 25.01.2017

progrik пишет:

тогда просто потри все мои мессаги и забань, долго-ли умеючи...
только не забудь потереть все мои мессаги со всего форума, ладно?

нет. сегодня просто напейся. Один. Надо.

DetSimen
DetSimen аватар
Offline
Зарегистрирован: 25.01.2017

Напиши потом, кактамчо. Отпустит, проверено. 

progrik
Offline
Зарегистрирован: 30.12.2018

DetSimen пишет:
нет. сегодня просто напейся. Один. Надо.
есть проблема. я не пью...
еще идеи? бан решает.

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

progrik пишет:

ВНИМАТЕЛЬНО цитата:
"и что, есть какой-то шанс, что компилятор/оптимизатор видя byte = byte + byte; откомпилит кам-то иначе, чем просто сложить свои любимые 8bit регистры? не верю))"
точно я туплю?

Точно!

Я же Вам задал конкретный вопрос (№2), который мог бы помочь Вам разобраться в вопросе. Но т.к. ответ на этот вопрос явно опровергал Ваши предыдущие утверждения, Вы предпочли его проигнорировать.

Ну, раз не хотите Вы, выложу я (результат "родного" дизассемблера Arduino IDE).

volatile uint8_t x1 = 123;
volatile uint8_t x2 = 231;
volatile uint8_t x3 = 214;
volatile uint8_t x4 = 134;
volatile uint16_t z = x1 + x2 + x3 + x4;
 49e:	40 91 03 01 	lds	r20, 0x0103	; 0x800103 <x1>
 4a2:	80 91 02 01 	lds	r24, 0x0102	; 0x800102 <x2>
 4a6:	30 91 01 01 	lds	r19, 0x0101	; 0x800101 <x3>
 4aa:	20 91 00 01 	lds	r18, 0x0100	; 0x800100 <__data_start>
 4ae:	90 e0       	ldi	r25, 0x00	; 0
 4b0:	84 0f       	add	r24, r20
 4b2:	91 1d       	adc	r25, r1
 4b4:	83 0f       	add	r24, r19
 4b6:	91 1d       	adc	r25, r1
 4b8:	82 0f       	add	r24, r18
 4ba:	91 1d       	adc	r25, r1
 4bc:	90 93 d1 01 	sts	0x01D1, r25	; 0x8001d1 <z+0x1>
 4c0:	80 93 d0 01 	sts	0x01D0, r24	; 0x8001d0 <z>
 4c4:	08 95       	ret

 

progrik
Offline
Зарегистрирован: 30.12.2018

andriano пишет:
Точно!

volatile uint16_t z = x1 + x2 + x3 + x4;

заочно!
да сколько же можно?!!
сфига там появился uint16_t, если 3 раза на этой странице написано, даже там написано, что сам цитируешь ---- Ч_И_Т_А_Й В_Н_И_М_А_Т_Е_Л_Ь_Н_О   П_О   Б_У_К_В_А_М::: "..видя byte = byte + byte; ..."
речь шла о контрольной сумме 4-х байт в ОДИН ДОЛБАННЫЙ БАЙТ!!!!!!!!!!! НАХРЕНА ТАМ uint16?
ты сам читаешь, что квотишь? "Po Diagonalli" однозначно, ничего не изменилось....
я даже специально пример кода переписал, чтоб именно 4-ре аргумента было. и результат байт...
я все знаю про преобразования типов, не надо меня учить, учитель нашелся. 30 лет назад эта книга у меня в туалете жила. детей своих учи или студентов. и выпей чаю.

ну бред полнейший. я не верю, что можно ТАК тупить... сам себе придумал херни, 16 бит, преобразования типов.. несет чушь полную, охренеть...
больной на голову...
я нашел того, кому пора напиться... ээээ, лечиться...

b707
Offline
Зарегистрирован: 26.05.2017

Андриано и Прогрик - если бы вы, кроме результата компиляции - асма, приводили Сишный исходник - повода спорить бы не было, как мне кажется

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

progrik пишет:

сфига там появился uint16_t, если 3 раза на этой странице написано, даже там написано, что сам цитируешь ---- Ч_И_Т_А_Й В_Н_И_М_А_Т_Е_Л_Ь_Н_О   П_О   Б_У_К_В_А_М::: "..видя byte = byte + byte; ..."

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

Тогда Вы вообще ничего не знаете ни о Си, ни о программировании.

sadman41
Онлайн
Зарегистрирован: 19.10.2016

Я бы не доверял знаниям, полученным в туалете.

progrik
Offline
Зарегистрирован: 30.12.2018

andriano пишет:
Тогда Вы вообще ничего не знаете ни о Си, ни о программировании.
в твоей-же ссылке на той-же 47-й странице написано

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

ТЫ ТУПЕЙШЕЕ И УПРЯМЕЙШЕЕ СУЩЕСТВО ИЗ ВСЕХ ДЕГЕНЕРАТИВНЫХ СУЩЕСТВ НА ПЛАНЕТЕ!!!

ПРОСТО СУКА ПОСТВАЬ UINT8_T И ПРОВЕРЬ, УРОДИНА ТЫ МОРАЛЬНАЯ

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

sadman41 пишет:
Я бы не доверял знаниям, полученным в туалете.
ты по делу или попердеть?

progrik
Offline
Зарегистрирован: 30.12.2018

...

b707
Offline
Зарегистрирован: 26.05.2017

progrik пишет:

в твоей-же ссылке на той-же 47-й странице написано

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

интересно, причем тут это вообще? тупняк продолжается?

progrik
Offline
Зарегистрирован: 30.12.2018

b707 пишет:
интересно, причем тут это вообще? тупняк продолжается?
что значит при чем?
чувак пишет, что в правой части ничего не происходит и не зависит от типа даннох в левой части. это херня. о чем написано в книге, цитату из которой я привел. и мало того, если говорить о практической части, то за 5 сек я меняю инт8 на инт16 - и все меняется, как и должно. считаются уже как инт16. этот чувак не шарит в Си вообще, в неявных преобразованиях типов особенно.

и читает как придурок по диагонали. как мануалы так и посты....

что было не понятного?........

пипец.......

b707
Offline
Зарегистрирован: 26.05.2017

а вообще, по-моему оба дебилы :)

 Результат обоих выражений

uint8_t Summ = (uint8_t)a + (uint8_t)b + (uint8_t)c +(uint8_t)d;

и

uint8_t Summ = (uint16_t)a + (uint16_t)b + (uint16_t)c +(uint16_t)d;

будет одинаковым при a b c d менее 256

Из чего следует. что замечание андриано на тему "промежуточных результатов" в uint16 смысла не имеет.

Ну а прогрик вообще не въехал. о чем спич :))

progrik
Offline
Зарегистрирован: 30.12.2018

мы не про результат, мы про то, как это происходит на машинном уровне. ты-то куда полез?...

b707
Offline
Зарегистрирован: 26.05.2017

progrik пишет:

мы не про результат, мы про то, как это происходит на машинном уровне. ты-то куда полез?...

вот именно. А если "не про результат" - к чему вообще ты стал говорить о преобразовании правой части к левой? Это вообще к вопросу отношения не имеет

b707
Offline
Зарегистрирован: 26.05.2017

как бы, если кто не понял..

CRC8, вычисленная по этому коду

volatile uint8_t x1 = 123;
volatile uint8_t x2 = 231;
volatile uint8_t x3 = 214;
volatile uint8_t x4 = 134;
volatile uint8_t z = x1 + x2 + x3 + x4;

и по этому

volatile uint8_t x1 = 123;
volatile uint8_t x2 = 231;
volatile uint8_t x3 = 214;
volatile uint8_t x4 = 134;
volatile uint16_t z = x1 + x2 + x3 + x4;

будет ОДИНАКОВОЙ.

И о чем вы тут сретесь.. совершенно непонятно....

progrik
Offline
Зарегистрирован: 30.12.2018

не лезь в тему не разобравшись.

цитата героя: "в Ассемблере при байтовом сложении все промежуточные (и окончательный) результаты - всегда байты, а в Си - не менее чем двухбайтовые слова"

понимаешь? ДВА БАЙТА ИЛИ ОДИН используется в вычислениях.

я доказал, что только ОДИН. и это зависит от типа переменной в левой половине.... вот о чем речь...

пойду, посмотрю, что с луной. у всех вас какой-то запредельный тупняк...

b707
Offline
Зарегистрирован: 26.05.2017

progrik пишет:

цитата героя: "в Ассемблере при байтовом сложении все промежуточные (и окончательный) результаты - всегда байты, а в Си - не менее чем двухбайтовые слова"

И че? Книжку-то читал. что тебе посоветовали? Там черным по белому сказано, что в любом выражении типы шорт и чар сначала преобразуются в инт, и только потом вычисляются. ДАЖЕ ЕСЛИ В ВЫРАЖЕНИИ ТОЛЬКО БАЙТЫ - они складываются как инт. Что непонятно? не тупи.

Другой вопрос, что в данном случае это НИКАК НЕ ВЛИЯЕТ НА РЕЗУЛЬТАТ, поэтому спор ни о чем.

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

progrik пишет:

andriano пишет:
Тогда Вы вообще ничего не знаете ни о Си, ни о программировании.
в твоей-же ссылке на той-же 47-й странице написано

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

Правильно.

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

Цитата:

ТЫ ТУПЕЙШЕЕ И УПРЯМЕЙШЕЕ СУЩЕСТВО ИЗ ВСЕХ ДЕГЕНЕРАТИВНЫХ СУЩЕСТВ НА ПЛАНЕТЕ!!!

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

sadman41
Онлайн
Зарегистрирован: 19.10.2016

Этот прожирик не первый раз кидается на всех, как тузик из будки. Гипертрофированное ЧСВ, похоже.

И уходит не впервой, по-моему.

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

progrik пишет:

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

Продолжаете упорствовать.

Ну ладно, если не умеете читать и логически мыслить, могу привести и конкретный код:

volatile uint16_t x5 = 40000;
volatile uint16_t x6 = 50000;
volatile uint32_t z1 = x5 + x6;
 4c4:	80 91 02 01 	lds	r24, 0x0102	; 0x800102 <x5>
 4c8:	90 91 03 01 	lds	r25, 0x0103	; 0x800103 <x5+0x1>
 4cc:	20 91 00 01 	lds	r18, 0x0100	; 0x800100 <__data_start>
 4d0:	30 91 01 01 	lds	r19, 0x0101	; 0x800101 <__data_start+0x1>
 4d4:	82 0f       	add	r24, r18
 4d6:	93 1f       	adc	r25, r19
 4d8:	a0 e0       	ldi	r26, 0x00	; 0
 4da:	b0 e0       	ldi	r27, 0x00	; 0
 4dc:	80 93 d4 01 	sts	0x01D4, r24	; 0x8001d4 <z1>
 4e0:	90 93 d5 01 	sts	0x01D5, r25	; 0x8001d5 <z1+0x1>
 4e4:	a0 93 d6 01 	sts	0x01D6, r26	; 0x8001d6 <z1+0x2>
 4e8:	b0 93 d7 01 	sts	0x01D7, r27	; 0x8001d7 <z1+0x3>
 4ec:	08 95       	ret

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

andriano
andriano аватар
Offline
Зарегистрирован: 20.06.2015

progrik пишет:

не лезь в тему не разобравшись.

цитата героя: "в Ассемблере при байтовом сложении все промежуточные (и окончательный) результаты - всегда байты, а в Си - не менее чем двухбайтовые слова"

понимаешь? ДВА БАЙТА ИЛИ ОДИН используется в вычислениях.

Ну, слава Богу, хоть меня не переврали. И на том спасибо.

Цитата:

я доказал, что только ОДИН. и это зависит от типа переменной в левой половине.... вот о чем речь...

"Нет" для обоих утверждений.

Не доказали потому, что не умеете отличать частного случая от общего правила.

А "не зависит" - ну об этом уже было постом выше.

progrik
Offline
Зарегистрирован: 30.12.2018

andriano пишет:
пока не выложишь листинг с uint8_t в левой части - разговаривать не о чем. сам все увидишь. это не 16-битный 286-й какой нибудь, где удобнее, чем юзать весь 16-битный регистр не придумать...

последний раз: я сказал, что byte = byte + byte + byte + byte; не будет использовать 2 байта. только один. не будет приведения типов.

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

и был разговор как-раз о ЧАСТНОМ СЛУЧАЕ - в один байт сумму 4-рех

_не_ _морозься_, _не_ _включай_ _дурака_, ты делаешь больно только себе.

дай листинг с уинт8 - остальное болтовня

и удивишься, тебе не поможет отключение оптимизации

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

progrik
Offline
Зарегистрирован: 30.12.2018

...