Arduino - 32 bitu promenna ze 4 byte
Pavel Hudeček
edizon na seznam.cz
Čtvrtek Prosinec 19 10:11:11 CET 2024
Ono je to celý vytažený z místa, kde okolnosti vedly k tomuhle
uspořádání. Jednak základní myšlenka byla, že všechny řádky v týhle
části budou stejný, aby se v případě potřeby dalo snadno obrátit pořadí.
Druhá věc je, že to je uvnitř switche a tam z nějakého záhadného důvodu
kompilátor pro AVR odmítá zakládat proměnné, takže jsou před switchem
založený různý univerzální, který se pak používaj uvnitř. Jako chápu že
asi byli lýný dělat třeba try, nebo templaty s ... (což je jinak často
mnohem lepší než klasika va_arg), ale proč tohle? wtf??
PH
Dne 19.12.2024 v 1:55 Miroslav Šinko napsal(a):
> pri optimalizaciach asi nema zmysel riesit redundantne zapisy.
>
> mna to zaujalo hned, aj cele tie shifty. ale nema to cenu moc riesit,
> ked to funguje a nie je to vyslovene zle zapisane.
>
> toto by som ja takto nepisal:
> >> uint64_t u64;
> >> while (1) {
> >>
> >> //u64=0ULL;
> >> //u64 <<= 8; u64 |= SIGROW.SERNUM5;
>
> ked uz uint64_t u64
> a chcem ju nastavit na 0, tak rovno tu a nie v kode, t.j.takto:
> uint64_t u64 = 0; //a tu su postfixy nepodstatne, 0 je 0
> a pozor! inicializovanie premennej pri deklaracii predchadza
> problemom. vy ste ju inicializovali v kode, ok. ale v kolkych
> pripadoch sa na to zabudne? kolkokrat sme sa na tom popalili?
> (recnicka orazka)
>
> no a prvy posun nuly je zbytocny.. t.j. co som napisal je ok, ale v
> tomto pripade by som zacal takto inicializaciou na prvu potrebnu hodnotu:
> uint64_t u64 = SIGROW.SERNUM5; //mozno plus nejake pretypovanie
> ..atd
>
> miro
>
> On 18.12.2024 21:28, Pavel Hudeček wrote:
>> Pardon, chybička se vloudila:-)
>>
>> Nemělo bejt +1, ale +n.
>> A to má dost velkej vliv na skóre:
>>
>> původní: 470, bez 1. shiftu taky 470
>> upravená: 790, bez toho shiftu ovšem 450.
>>
>> Všechno ale s -Og. Po zapnutí -Os všechny 4 možnosti 378 :-)
>>
>> PH
>>
>> Dne 18.12.2024 v 21:05 Pavel Hudeček napsal(a):
>>> Je to trochu složitější:-)
>>>
>>> int main(void) {
>>>
>>> uint64_t u64;
>>> while (1) {
>>>
>>> //u64=0ULL;
>>> //u64 <<= 8; u64 |= SIGROW.SERNUM5;
>>> u64 <<= 8; u64 = SIGROW.SERNUM5;
>>>
>>> u64 <<= 8; u64 |= SIGROW.SERNUM4;
>>> u64 <<= 8; u64 |= SIGROW.SERNUM3;
>>> u64 <<= 8; u64 |= SIGROW.SERNUM2;
>>> u64 <<= 8; u64 |= SIGROW.SERNUM1;
>>> u64 <<= 8; u64 |= SIGROW.SERNUM0;
>>>
>>> // aby byla jistota, že to celý neodoptimalizuje
>>> u64++;
>>> for (uint8_t n=0; n<8; n++) {
>>> PORTA.OUT = *(((uint8_t *)&u64)+1);
>>> }
>>> }
>>> }
>>>
>>> Zakomentovaná varianta 444 B, vylepšená 478.
>>>
>>> Až po odmazání prvního u64 <<= 8; se to zlepší na 442 a původní
>>> zůstane na 444.
>>>
>>> Takže nakonec je to o 2 B lepší. Ale zas ta původní varianta má
>>> snadno modifikovatelné pořadí, což byla základní myšlenka proč jsem
>>> to tak napsal.
>>>
>>> PH
>>>
>>>
>>> Dne 18.12.2024 v 16:53 Petr Labaj napsal(a):
>>>> Je zajímavé, že jste oba použili podobnou konstrukci, která je
>>>> podle mě suboptimální.
>>>> Když už jste teda zvolili ty shifty místo nějakých rychlejších
>>>> možností.
>>>>
>>>> První řádek by měl být podle mě dosazovací.
>>>>
>>>> Tedy nějak takto:
>>>> adc_value = (long)d[0] << 24;
>>>> adc_value += (long)d[1] << 16; ...
>>>>
>>>> A u pana Hudečka ještě bez toho úvodního nulování:
>>>> u64 <<= 8; u64 = SIGROW.SERNUM5;
>>>> u64 <<= 8; u64 |= SIGROW.SERNUM4;
>>>> ...
>>>>
>>>> PL
>>>>
>>>> ******************
>>>>
>>>> Dne 18.12.2024 v 9:56 Jirka Mww napsal(a):
>>>>>
>>>>> adc_value += (long)d[0] << 24;
>>>>> adc_value += (long)d[1] << 16; adc_value += (long)d[2] << 8;
>>>>> adc_value += (long)d[3];
>>>>>
>>>>
>>>> Dne 18.12.2024 v 13:26 Pavel Hudeček napsal(a):
>>>>> u64=0ULL;
>>>>> u64 <<= 8; u64 |= SIGROW.SERNUM5;
>>>>> u64 <<= 8; u64 |= SIGROW.SERNUM4;
>>>>> u64 <<= 8; u64 |= SIGROW.SERNUM3;
>>>>> u64 <<= 8; u64 |= SIGROW.SERNUM2;
>>>>> u64 <<= 8; u64 |= SIGROW.SERNUM1;
>>>>> u64 <<= 8; u64 |= SIGROW.SERNUM0;
Další informace o konferenci Hw-list