In der msgpcc (GCC für MSP430 Mikrocontroller) Handbuch Autoren geschrieben:
Verwenden Sie int anstelle von char oder unsigned char, wenn Sie eine kleine ganze Zahl innerhalb einer Funktion möchten. Der erzeugte Code wird effizienter sein, und in den meisten Fällen wird der Speicher nicht wirklich verschwendet.
Warum int ist effizienter?
UPD. Und warum (u)int_fast8_t in der mspgcc als (unsigned) char , nicht (unsigned) int definiert wurde. Wie ich es verstehe, sollte (u)int_fast*_t auf den effizientesten Typ mit einer ausreichenden Größe definiert werden.
Im Allgemeinen, nicht unbedingt spezifisch für diesen Prozessor, hat es mit Zeichenerweiterung und Maskierung zu tun, was zusätzliche Anweisungen erfordert, um den C-Quellcode gewissenhaft zu implementieren. Ein vorzeichenbehafteter 8-Bit-Wert in einem 16- oder 32- oder 64-Bit-Prozessor kann zusätzliche Anweisungen zum Signieren von Extend beinhalten. Eine 8-Bit-Addition auf einem 32-Bit-Prozessor könnte zusätzliche Anweisungen für und mit 0xFF usw. enthalten.
Sie sollten ein paar einfache Experimente machen, es dauerte ein paar Iterationen, aber ich traf schnell etwas, das einen Unterschied zeigte.
%Vor%erzeugt
%Vor%Der msp430 hat Wort- und Byteversionen der Anweisungen, so dass ein einfaches Addieren oder Subtrahieren nicht die Clipping- oder Zeichenerweiterung erfordert, die Sie erwarten würden, wenn Sie Variablen verwenden, die kleiner als Register sind. Als Programmierer wissen wir vielleicht, dass wir sbfun nur mit sehr kleinen Zahlen füttern würden, aber der Compiler tut das nicht und muss unseren Code wie geschrieben treu umsetzen und mehr Code zwischen sfun und sbfun generieren. Es ist nicht schwer, diese Experimente mit verschiedenen Compilern und Prozessoren zu machen, um dies in Aktion zu sehen. Der einzige Trick besteht darin, Code zu erstellen, den der Prozessor nicht einfach zu lösen hat.
ein anderes Beispiel
%Vor%erzeugt
%Vor%Eine allgemeine Faustregel ist, dass CPUs am schnellsten sind, wenn sie mit ganzen Zahlen ihrer nativen Wortgröße arbeiten .
Dies ist natürlich völlig architekturabhängig, siehe die Antworten auf diese ähnliche Frage , um weitere Erläuterungen zu diesem Punkt zu erhalten.
TI hat eine Application Note zum Thema für ihre Tiva-C (formal Stellaris) MCUs veröffentlicht.
Im Abschnitt "Einführung" enthält eine Tabelle eine Liste von Faktoren, die Leistung und Größe beeinflussen. Ein faktor label Variable size gibt an, dass " unter Verwendung von Variablen, die kleiner als optimal sind, zusätzliche Anweisungen zum Signieren oder unsignieren von extend ... " .
Auch unter dem Abschnitt "Größe der Variablen" steht:
"Wenn die lokalen Variablen kleiner als die Registergröße sind, wird normalerweise zusätzlicher Code benötigt. Auf einem Stellaris-Teil bedeutet dies, dass lokale Variablen der Größe Byte und Halbwort (char bzw. short int) zusätzlichen Code benötigen B. von einem 8-Bit- oder 16-Bit-Mikrocontroller portiert wurden, wurden Locals möglicherweise in kleinere Größen konvertiert (um ein zu großes Problem zu vermeiden). Dies bedeutet, dass dieser Code langsamer läuft und mehr Code benötigt als benötigt wird. "
Siehe: Ссылка
Das Folgende wird vom Compiler behandelt, ist aber immer noch relevant für das vorliegende Problem:
Der MSP430 ist ein 16-Bit-Mikroprozessor. Ein Zeichen besteht nur aus 8 Bits und würde ein Packen erfordern, um sicherzustellen, dass alle Wörter ausgerichtet sind. Zum Beispiel würden 3 Zeichen nicht korrekt im Speicher ausgerichtet. Verwenden Sie stattdessen eine Ganzzahl mit 16 Bits, die immer ausgerichtet wird.
Wenn Sie variable Größen verwenden, die ein Vielfaches von 16 sind (z. B. 16 und 32), können Sie den Speicher auch effizienter nutzen. Sie werden nicht mit Auffüllung enden, um den Speicher auszurichten.
int entspricht der nativen Größe des betreffenden Prozessors (16 Bits). Wenn Sie also nach einer unsigned char -Variable fragen, muss der Compiler möglicherweise zusätzlichen Code ausgeben, um sicherzustellen, dass der Wert zwischen 0 und 0 liegt und 255.
Tags und Links c assembly microcontroller msp430 mspgcc