Vraag:
Waarom is int slechts 2 bytes?
Peter Bloomfield
2014-02-20 17:37:03 UTC
view on stackexchange narkive permalink

Bij gebruik van C / C ++ op andere platforms, is het type int doorgaans 4 bytes (of mogelijk meer). Op Arduino is het echter slechts 2 bytes.

Waarom is het anders? Heeft het invloed op de prestaties als ik in plaats daarvan altijd de 4 byte lang gebruik?

merk op dat ʻint` 4 bytes is op de Arduino Due. Een `short` is 2 byte op alle bestaande Ardunios, maar ik benadruk het advies van de anderen om ʻint16_t` of ʻuint16_t` te gebruiken.
Twee antwoorden:
#1
+10
Cybergibbons
2014-02-20 19:55:45 UTC
view on stackexchange narkive permalink

De ATmega328 die in veel Arduino's wordt gebruikt, is een 8-bits microcontroller. Dit betekent dat registers 8 bits zijn, de databus 8 bits, de poorten 8 bits. Er zijn enkele minimale 16-bits aspecten aan het systeem (bijv. Een van de timers), maar bijna alles is 8-bits.

Daarom verwerken de meeste bewerkingen 8-bits tegelijk. Werken aan alles behalve 8-bits (dwz 16-bits of 32-bits gehele getallen en getallen met drijvende komma) vereist wat in wezen kan worden omschreven als software-emulatie, waarbij de compiler meerdere instructies gebruikt om aan deze grotere variabelen te werken.

8-bits is duidelijk voldoende om een ​​8-bits poort aan te spreken. Het is ook voldoende om met veel lustellers, retourwaarden en ASCII-tekens om te gaan. Het is echter niet echt genoeg als het om cijfers gaat. Een ondertekende 8-bit int (int8_t) kan alleen -128 -> +127 vertegenwoordigen. Unsigned (uint8_t) kan alleen staan ​​voor 0 -> 255.

8-bits gehele getallen zijn behoorlijk beperkend. C / C ++ int moet minstens -32.678 -> +32.767 vertegenwoordigen, dus wordt toegewezen aan int16_t - de kleinste grootte die dit zal doen. Dit geeft een goede balans tussen bereik en efficiëntie. Dit is vooral belangrijk wanneer beginners aan het leren zijn - overflow is niet echt iets dat niet-programmeurs begrijpen.

Dit heeft echter een impact op de prestaties, omdat de meeste 16-bits bewerkingen minstens twee keer zo lang duren als een 8-bits bewerking en gebruik twee keer zoveel registers. Dit kan voor jou wel of niet een verschil maken.

Velen van ons schakelen over naar de native types zoals int8_t en uint8_t, omdat het je veel meer controle geeft.

Even een opmerking: het is niet het Arduino-team dat int heeft toegewezen aan int16_t, "int" is een gereserveerd trefwoord voor C / C ++ en de type-mapping maakt deel uit van de ABI (http://gcc.gnu.org/wiki/avr- gcc) die de ontwikkelaars van de avr-gcc compiler besloten te volgen. Een ander opmerkelijk verschil zit in het "dubbele" type dat gewoonlijk 64-bits breed is, terwijl in de avr-gcc 32-bits is zoals "float"
Bedankt. Ik weet niet zeker waarom ik dat schreef. Ik weet dat int 32.678 -> +32.767 moet vertegenwoordigen (hoewel ik denk dat er eigenlijk een eigen compiler was voor een van de NEC-processors die dit niet volgde). Ik denk dat het komt omdat ik het niet leuk vind om breedtes op embedded systemen te verbergen - het gebruik van int16_t is veel duidelijker.
+1 voor het gebruik van duidelijke native types! Op de Arduino Due is een `int` 32-bit! http://arduino.cc/en/Reference/int
#2
+3
jfpoilpret
2014-02-21 00:37:00 UTC
view on stackexchange narkive permalink

Een belangrijk feit over C- en C ++ -talen is dat hun respectieve standaarden niet de grootte (in bytes) van integrale en drijvende-kommatypen definiëren.

Ze definiëren slechts minimale bereiken en relatie tussen deze bereiken , bijv.

  bereik (kort) < = bereik (int) < bereik (lang)  

Dus de grootte van bijv. een int is doorgaans afhankelijk van:

  • het doelplatform (processor)
  • de compiler zelf
zegt u dat `sizeof (short) == sizeof (int) == sizeof (long)` mogelijk is?
@ron-e Theoretisch zou dat mogelijk zijn. In de praktijk heb ik dat echter nog nooit gezien. Bij de meeste compiler / platforms zou je kunnen verwachten (hoewel het niet is opgelegd) dat `sizeof (short)


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...