Archiv verlassen und diese Seite im Standarddesign anzeigen : Gibt es Prozessoren, die bei 8 oder 16 bit Operationen langsamer sind, als bei 32 bit
pancho
2006-01-26, 17:58:04
Frage = Topic
Der Ursprung ist die Frage, ob man lieber "int" oder "short" und "long" verwenden sollte.
Mir wurde beigebracht, immer short und long zu verwenden, weil man dann weiß, was man hat.
Ein anderer behauptet, int wäre besser, da "man normalerweise davon ausgehen [kann], dass ein "int" für jeden Prozessor eine relativ gut handhabbare Größe ist."
zeckensack
2006-01-26, 18:12:18
Nimm int.
long ist ein Anachronismus aus längst vergangenen 16 Bit-Tagen (Windows-Header ahoi).
In Strukturen können kleinere Datentypen Sinn ergeben, um Speicher zu sparen. In Funktionsparametern sollte man aber short und char tunlichst vermeiden.
Man nehme zB diese Funktionen:void total_toll(int peter);
void nicht_so_gut(char peter);Beim Aufruf der ersten Funktion kann ein Register-Inhalt direkt übergeben werden (auf dem Stack, oder eben direkt als Register, ohne Kopie).
Bei der zweiten Funktion wird der Parameter, wenn er auf dem Stack übergeben wird, ohnehin wieder auf 32 Bit Breite aufgeblasen, also besteht hier keinerlei Gewinn. Zudem wird beim Aufruf (innerhalb des aufrufenden Codes) der Parameter auf 8 Bit beschnitten (mit bitweisem AND), um die Konvention zu erfüllen. Bei einer Funktion die ein char erwartet darf der Compiler nämlich nicht davon ausgehen dass sie zB mit dem Argument 256 noch sinnvoll funktioniert. Und diese Extra-Operation ist dann sogar ein (kleiner) Nachteil.
pancho
2006-01-26, 18:33:25
Vielleicht sollte ich noch anfügen, dass es mir nicht um PC-Programmierung geht, sondern eher Richtung Mikrocontroller, also irgendwas zwischen ARM7TDMI, CPU32 (aka 68k) oder 8-bittigen AVRs.
Ist beim gcc int immer 32 bit lang? (Also auch bei Versionen für andere Architekturen?)
Das mit dem Zurechtstutzen und aufblasen ist aber interessant, müsste direkt mal schauen, was der arm-elf-gcc und der ARM7TDMI daraus macht. Leider hab ich im Moment keinen Controller hier, um das zu testen.
Verursacht long auch derartige Verrenkungen?
Gibt es aus Hardwaresicht einen Grund, warum kleinere Datentypen auf einem 32 bit Prozessor langsamer sind?
Weißt Du zufällig, wie sich der ARM7TDMI diesbezüglich im Thumb-Modus verhält?
int ist (soweit ich weiß) immer der "native" Datentyp, also der den man am meisten verwenden sollte.
Warum fragen?
Lieber sizeof() verwenden und anpassungsfähigen Code schreiben.
zeckensack
2006-01-26, 19:35:33
Vielleicht sollte ich noch anfügen, dass es mir nicht um PC-Programmierung geht, sondern eher Richtung Mikrocontroller, also irgendwas zwischen ARM7TDMI, CPU32 (aka 68k) oder 8-bittigen AVRs.
Ist beim gcc int immer 32 bit lang? (Also auch bei Versionen für andere Architekturen?)Bei x86 und ARM: Ja. Beim 68k bin ich mir jetzt nicht sicher, und ich weiß auch nicht was ein AVR ist.
Wenn du auf dem Zielrechner Textausgabe und eine Standard-C-Runtime hast, probier's mal damit:printf("sizeof(int)=%d\n",sizeof(int));
printf("sizeof(short)=%d\n",sizeof(short));
printf("sizeof(long)=%d\n",sizeof(long));
...Für semi-portablen Code der auf Rechnern laufen soll die unterschiedliche Werte ausspucken empfehlen sich plattformabhängige typedefs. Auf diversen ARM-Rechner ist zB sowas verbreitet:typedef unsigned char u8;
typedef signed char s8;
typedef unsigned short u16;
typedef signed short s16;
typedef unsigned int u32;
typedef signed int s32;Das mit dem Zurechtstutzen und aufblasen ist aber interessant, müsste direkt mal schauen, was der arm-elf-gcc und der ARM7TDMI daraus macht. Leider hab ich im Moment keinen Controller hier, um das zu testen.
Verursacht long auch derartige Verrenkungen?long ist auf arm-thumb-elf-gcc und allen mir bekannten x86-Compilern (32 Bit und x86-64) identisch zu int, also 32 Bit breit. long long ist auf x86 64 Bit breit, wobei ich im Moment nicht weiß ob es auf dem ARM-Ziel diesen Typ überhaupt gibt.
Gibt es aus Hardwaresicht einen Grund, warum kleinere Datentypen auf einem 32 bit Prozessor langsamer sind?Gewisse Operationen auf breiten Typen können aus Operationen auf schmalen Typen zusammengestückelt werden. ZB lässt sich eine Addition zweier 32 Bit-Zahlen aus vier 8 Bit-Additionen zusammensetzen.
Der ARM7TDMI macht das zB bei der Integer-Multiplikation. Allerdings ist ihm der Datentyp egal (er unterstützt sowieso nur ALU-Operationen mit vollen 32 Bit-Registern als Quellen), es zählt nur der tatsächliche Inhalt zum Zeitpunkt der Operation.
Addition ist aber definitv unkritisch.Weißt Du zufällig, wie sich der ARM7TDMI diesbezüglich im Thumb-Modus verhält?Thumb ist voll 32bittig, genau wie ARM. Die Breite der Typen (und der Register) unterscheidet sich nicht.
pancho
2006-01-26, 19:41:29
Vielen Dank, das hilft mir schonmal weiter!
Benja
2006-01-30, 12:21:52
evtl stichwort Alignment im Hinterkopf behalten.
wenn du eine struktur aus mehreren kleinen variablen hast (z.b. short, byte o.ä.) und die auch wirklich in dieser größe (8 oder 16 Bit) im Speicher abgelegt werden - dann kann der Direktzugriff darauf u.U. teuer sein (wenn die Variablen im Speicher direkt aneinander gelegt werden). Weil du typischerweise nicht auf 8Bit direkt zugreifen kannst, sondern typischerweise nur 32Bit-genau.
Wenn dein Alignment so ist, dass alles immer auf Wortbreite im Speicher abgelegt wird (wobei du Speicherplatz "verschwendest" - dann hast du in der Hinsicht aber keine Probleme zu erwarten.
http://www-128.ibm.com/developerworks/library/pa-dalign/ (unterster Abschnitt)
Mad-Marty
2006-02-04, 23:53:44
Nimm int.
long ist ein Anachronismus aus längst vergangenen 16 Bit-Tagen (Windows-Header ahoi).
In Strukturen können kleinere Datentypen Sinn ergeben, um Speicher zu sparen. In Funktionsparametern sollte man aber short und char tunlichst vermeiden.
Man nehme zB diese Funktionen:void total_toll(int peter);
void nicht_so_gut(char peter);Beim Aufruf der ersten Funktion kann ein Register-Inhalt direkt übergeben werden (auf dem Stack, oder eben direkt als Register, ohne Kopie).
Bei der zweiten Funktion wird der Parameter, wenn er auf dem Stack übergeben wird, ohnehin wieder auf 32 Bit Breite aufgeblasen, also besteht hier keinerlei Gewinn. Zudem wird beim Aufruf (innerhalb des aufrufenden Codes) der Parameter auf 8 Bit beschnitten (mit bitweisem AND), um die Konvention zu erfüllen. Bei einer Funktion die ein char erwartet darf der Compiler nämlich nicht davon ausgehen dass sie zB mit dem Argument 256 noch sinnvoll funktioniert. Und diese Extra-Operation ist dann sogar ein (kleiner) Nachteil.
sollte man nicht eher pointer übergeben ... ??
sollte man nicht eher pointer übergeben ... ??
Nur dann wenn der zu übergebende Typ größer als ein Pointer ist. Und auch dann nimmt man lieber Referenzen, wenn man auf eine Spezialbedeutung von NULL verzichten kann.
In Strukturen können kleinere Datentypen Sinn ergeben, um Speicher zu sparen. In Funktionsparametern sollte man aber short und char tunlichst vermeiden.
"Tunlichst vermeiden" ist wohl etwas übertrieben. Wenn explizit nur 8 Bit an Daten erwünscht sind, dann sollte man das auch kenntlich machen.
zeckensack
2006-02-05, 01:15:05
"Tunlichst vermeiden" ist wohl etwas übertrieben. Wenn explizit nur 8 Bit an Daten erwünscht sind, dann sollte man das auch kenntlich machen.Überkompensation ;)
Viele aufstrebende Programmierer halten es für eine wirksame Mikro-Optimierung, für alles möglichst kleine Datentypen zu verwenden. Das ist bei Funktionsparametern kontraproduktiv.
(bei Strukturen wie gesagt nicht, wenn man nicht gerade MSVC <=6 einsetzt)
pippo
2006-02-05, 10:42:58
Vielleicht sollte ich noch anfügen, dass es mir nicht um PC-Programmierung geht, sondern eher Richtung Mikrocontroller, also irgendwas zwischen ARM7TDMI, CPU32 (aka 68k) oder 8-bittigen AVRs.
also wir lernen im Studium, für Microcontroller short und long zu verwenden. Da sind sich auch alle Prof an der FH einig. ausserdem weiß dann jeder, welche Werte zu erwarten sind, wenn er den Code liest
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.