Kérdés:
Miért int csak 2 bájt?
Peter Bloomfield
2014-02-20 17:37:03 UTC
view on stackexchange narkive permalink

Ha a C / C ++ szoftvert más platformokon használja, akkor az int típus általában 4 bájt (vagy potenciálisan több). Az Arduino-n azonban csak 2 bájt.

Miért más? Befolyásolja-e a teljesítményt, ha mindig a 4 bájtos long -ot használom?

vegye figyelembe, hogy az `int '4 bájt az Arduino Due-n. A `rövid« 2 bájt lesz az összes meglévő Ardunioson, de hangsúlyozom a többiek tanácsát, hogy az `int16_t` vagy az` uint16_t` parancsot használja.
Kettő válaszokat:
Cybergibbons
2014-02-20 19:55:45 UTC
view on stackexchange narkive permalink

Az ATmega328, amelyet sok Arduinos használ, egy 8 bites mikrovezérlő. Ez azt jelenti, hogy a regiszterek 8 bitesek, az adatbusz 8 bites, a portok 8 bitesek. Van néhány minimális 16 bites aspektus a rendszerben (pl. Az egyik időzítő), de szinte minden 8 bites.

Ezért a legtöbb művelet egyszerre 8 biteset kezel. A 8 bites kivételével (pl. 16 bites vagy 32 bites egész számok és lebegőpontos számok) bármi mással való munka megköveteli azt, amit alapvetően szoftveremulációnak lehetne nevezni, ahol a fordító több utasítással dolgozik ezen nagyobb változókon. A p> 8 bites nyilvánvalóan megfelelő egy 8 bites port megcímzéséhez. Elég sok hurokszámlálóval, visszatérési értékekkel és ASCII karakterekkel is foglalkozni. A számokkal való foglalkozás azonban nem igazán elég. Az aláírt 8 bites int (int8_t) csak -128 -> +127-et jelenthet. Az aláíratlan (uint8_t) csak 0 -> 255 értéket képviselhet.

A 8 bites egész számok meglehetősen korlátozóak. A C / C ++ int-nek legalább -32 678 -> + 32 767 értéket kell képviselnie, így az int16_t-hez társul - a legkisebb mérethez. Ez jó egyensúlyt biztosít a hatótávolság és a hatékonyság között. Ez különösen akkor fontos, ha a kezdők tanulnak - a túlcsordulást nem igazán értik a nem programozók.

Ennek azonban teljesítményre van hatása, mert a legtöbb 16 bites művelet legalább kétszer annyi időt vesz igénybe, mint egy 8 bites műveletet, és kétszer annyi regisztert használjon. Lehet, hogy ez nem tesz számotokra változást.

Sokan áttérünk a natív típusokra, például az int8_t és az uint8_t, mivel ez sokkal nagyobb irányítást biztosít Önnek.

Csak egy megjegyzés: nem az Arduino Team hozzárendelte az int-et az int16_t-hez, az "int" egy C / C ++ fenntartott kulcsszó, a típus-hozzárendelés pedig az ABI része (http://gcc.gnu.org/wiki/avr- gcc), amelyet az avr-gcc fordító fejlesztői úgy döntöttek, hogy követik. Egy másik jelentős különbség a "kettős" típusban van, amely általában 64 bites, míg az avr-gcc 32 bites, mint az "úszó"
Köszönöm. Nem tudom, miért írtam ezt. Tudom, hogy az int-nek 32 678 -> + 32 767-et kell képviselnie (bár valójában azt hiszem, hogy volt egy saját fordító az egyik NEC processzor számára, amely ezt nem követte). Szerintem azért, mert nem szeretem a szélességek elrejtését a beágyazott rendszereken - az int16_t használata sokkal egyértelműbb.
+1 a tiszta natív típusok használatáért! Az Arduino Due esetében egy ʻint` 32 bites! http://arduino.cc/en/Reference/int
jfpoilpret
2014-02-21 00:37:00 UTC
view on stackexchange narkive permalink

A C és a C ++ nyelvekkel kapcsolatban fontos tény, hogy a megfelelő szabványok nem határozzák meg az integrált és a lebegőpontos számok típusának méretét (bájtban).

Csak minimális tartományokat és összefüggést határoznak meg ezek között , pl

  range (short) < = range (int) < range (long)  

Tehát pl. egy int általában a következőktől függ:

  • a célplatform (processzor)
  • maga a fordító
azt mondod, hogy `sizeof (short) == sizeof (int) == sizeof (long)` lehetséges?
@ron-e Elméletileg igen, ez lehetséges lenne. A gyakorlatban azonban még soha nem láttam ilyet. A legtöbb fordítóban / platformban arra számíthatunk (bár nincs előírva), hogy "sizeof (short)


Ezt a kérdést és választ automatikusan lefordították angol nyelvről.Az eredeti tartalom elérhető a stackexchange oldalon, amelyet köszönünk az cc by-sa 3.0 licencért, amely alatt terjesztik.
Loading...