|
Anzeige
|
char und short in der 32bit Welt
Gast
#5146412
Hallo, ergibt die Verwendung von 8bit und 6bit Datentypen in der Welt von STM32 etc. überhaupt noch Sinn? Es wird doch intern eh alles mit 32 Bit Registern verarbeitet - warum sollte es man der CPU so schwer machen? Wenn bei einem STM32 von x kByte Ram die Rede ist, wie ist dieser denn organisiert? Schreibe ich da wirklich Bytes? Oder wird ein 32bit Wert auf 4 Bytes verteilt? Z.B. uint32_t x; uint8_t y; - verbrauche ich hier 5 Byte Ram? @Jens (Gast) >ergibt die Verwendung von 8bit und 6bit Datentypen in der Welt von STM32 >etc. überhaupt noch Sinn? Ja, wenn gleich nicht für jeden Zweck. > Es wird doch intern eh alles mit 32 Bit >Registern verarbeitet - warum sollte es man der CPU so schwer machen? Weil man z.B. bei größeren Arrays mit 32 stat 8 Bit massiv Speicher verschwendet? >Wenn bei einem STM32 von x kByte Ram die Rede ist, wie ist dieser denn >organisiert? Schreibe ich da wirklich Bytes? Natürlich nicht. >Oder wird ein 32bit Wert >auf 4 Bytes verteilt? Z.B. uint32_t x; uint8_t y; - verbrauche ich hier >5 Byte Ram? Je nach CPU und Compilereinstellung können das 5, 6 oder gar 8 Byte sein, Stichwort Memory Alignment.
Gast
#5146427
Jens schrieb: > Verwendung von 8bit und 16bit Datentypen in der Welt von STM32 Bei den ARM Cortex-A hat die Unterscheidung zwischen 32-bit und 8-bit schon immer Sinn gemacht, weil es dafür zwei verschiedene Assembler-Befehle gibt. So ist z.B. ein I2C Puffer als char* schneller als long* Für Arithmetik / Logik ist hingegen long schneller, es macht also Sinn, einen Zähler long zu machen Bei den Cortex-M ist die Sache komplizierter, denn es gibt auch 16-bit Befehle. Die können aber beim Bus-Zugriff zu Latenzen führen - Cache / Waitstates - und beim Alignment auf dem M0 sogar zum Absturz. Daher macht es aus meiner Sicht Sinn, auch dort nur 32-bit und 8-bit zu verwenden. Auch bei M0 mit bit-adressierbarem Speicher ist char* schneller als long* Jens schrieb: > ergibt die Verwendung von 8bit und 6bit Datentypen in der Welt von STM32 > etc. überhaupt noch Sinn? Im RAM ja, im Register nein. Bei skalaren Variablen innerhalb von Funktionen ergibt es also meist nur Sinn, wenn die Rechnerei mit mehr Bits zu einem falschen Ergebnis führt. Lothar schrieb: > Bei den Cortex-M ist die Sache komplizierter, denn es gibt auch 16-bit > Befehle. Load/Store für 16 Bits gibt es bei allen ARMs jenseits der allerersten. > und beim Alignment auf dem M0 sogar zum Absturz. Demgemäss sollte man nur 8-Bit Variablen verwenden, denn für 32 Bits gilt das genauso wie für 16 Bits. ;-) Nope. Die 16er müssen eben passend aligned sein, grad wie die 32er. Macht der Compiler auch, wenn man ihn nicht verarscht.
Gast
#5146486
Oder man nutzt uint_fast8_t & Co, wenn man zwar nur die Zahlen 0-255 benötigt, aber das Überlauf-Verhalten nicht gebraucht ist (d.h. das Ergebnis von 255+1 egal ist). Das ist auf 8-Bit-Architekturen dann 8bit, und auf 32bit-Architekturen ggf. 32bit, was schneller zu berechnen ist, aber eben nicht so überläuft wie ein "echter" uint8_t. Für große Arrays ist das dann natürlich nicht so geschickt. Da bedeutet die Nutzung von uint8_t auch keinen Nachteil, denn wenn temporäre 32bit-Werte (in Registern) per LDRB/STRB in einen uint8_t im Array geschrieben werden, werden die automatisch abgeschnitten und es ist kein explizites "& 0xFF" nötig. Das ist so etwas das mich an den STM32 HAL Libraries stört - da werden teilweise für 1-Bit werte ("booleans") 32bit-Typen genutzt... Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
