Re: funkce v C - pro€ to nechod

Petr Zapadlo zapik na email.cz
Středa Prosinec 30 09:08:14 CET 2015


Zdravím,

díky za vysvětlení, to vypadá hodně pravděpodobně. ano, návrat z eeprom 
je typ byte.
Výsledek má být long, jak to napsat aby už ten součin proběhl jako long?

A v tom druhém případě:
unsigned int alarm2 =  EEPROM.read (alarmclock + 2);
   unsigned int alarm1 = EEPROM.read (alarmclock + 1);
   unsigned int alarm0 = EEPROM.read (alarmclock);
   alarm=alarm2*65536+alarm1*256+alarm0;

proč to probíhá dobře?  je to dáno tím, že jsem označil int jako 
neznaménkový a proto nepřetéká? a nebo že v tom řádku už se ty součiny 
řeší jako long? (alarm je long)

Díky

Petr




PS Disasemblat už asi nedodám - omylem jsem si smazal zdrojový kod co 
jsem včera celý den psal. Lze to nějak zpětně zrekonstruovat z arduina?


Dne 30.12.2015 v 00:26 Jan Waclawek napsal(a):
> Zacnem s tym, ze to je C++ a nie C.
>
> C++ presne nepoznam, ale je mozne, ze to spravanie v tomto konkretnom pripade je rovnake ako v C. Zakladom "problemu" je vsak urcite fakt, ze int je v avr-gcc aj avr-g++ 16-bitovy. Neviem sice, aky je navratovy typ funkcie (pardon, ++ metody) co cita z EEPROM, ale tipujem, ze to bude jeden z troch 8-bitovych typov, co sa pred nasobenim vdaka usual arithmetic conversions konvertuje na int. Rovnako konstanta 256 zo stredneho sucinu je implicitne int, ergo aj ten sucin je typu int. Konstantny vysledok pri inkriminovanej hodnote "stredneho parametra" nad 250 (a pravdepodobne nad 128) je asi dana optimalizaciou vychadzajucou z faktu, ze 128 a viac  * 256 do [znamienkoveho 16-bitoveho] int pretecie, a teda vysledok sucinu je nedefinovany, ergo moze byt aj nahodne cislo alebo aj konstanta.
>
> Bolo by poucne vidiet relevantny disasemblat.
>
> wek
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list



Další informace o konferenci Hw-list