Codebeispiel 1 zeigt die Generierung einer Checksumme über 2 Pointer.Cosmic Software
Der Controller S12Z von Freescale sprengt die Effizienz- und Adressbereichsgrenzen der ursprünglichen 16-Bit-Architektur, ohne dabei den Ressourcen-Overhead einer bis heute als nächsten Migrationsschritt üblicherweise verwendeten 32-Bit-Architektur zu benötigen. Der Controller verfügt über einen 24 Bit breit nutzbaren Adressbus und vollwertige 8-, 16- und 32-Bit-Register. Davon einige mehr als bei CISC-Controllern sonst üblich. Macht Sinn, denn sein Instruktion-Set bricht mit ein paar eingestaubten Regeln und besteht aus einer gelungenen Mischung aus CISC- und RISC-Instruktionen.
Mehrere Adressmodi für den Speicherzugriff über 24, 18, 16 und 14 Bit Adressanteil ermöglichen einem optimierenden Codegenerator eine optimal skalierte Verwendung der Instruktionsgröße. Bis hinunter zu 3 Byte Instruktionen, die für einen 14 Bit Adressraum möglich sind. Damit sind bereits die wesentlichen Dinge für einen rein softwareseitigen Vergleich genannt, um die Effizienz des neuen Instruktion-Sets einschätzen zu können.
Generierung einer Checksumme über 2 Pointer
Davon ausgehend, dass zunächst als Basis eine für den S12X bestehende, zumindest bezüglich der Datenzugriffe, reine 16 Bit Applikation verwendet wird, haben Auswertungen bei Cosmic ergeben, dass trotz der nun auf 24 Bit angestiegenen Adressbreite, sich eine durchschnittliche Verkleinerung der Codegröße um 5 % ergibt. Dies geht natürlich nur, wenn komplexer Code wesentlich kleiner wird und damit den durch die breiteren Adressen zwangsläufig entstehenden Verlust mehr als kompensiert. Ein gutes Beispiel ist das erste hier angeführte Beispiel, in welchem die Generierung einer Checksumme über 2 Pointer verwendet wird. Eine vereinfachte, aber in ihrer Art recht gebräuchliche Funktion. Die Gegenüberstellung des jeweils generierten Codes zeigt, dass hier die RISC-Seite des S12Z voll zur Geltung kommt. Speicherzugriffe sind auf ein Minimum reduziert, gearbeitet wird ausschließlich in den Registern und quasi als Bonbon entfällt dabei auch noch der Stack-Bedarf für lokale Variablen komplett.
Codebeispiel 2 zeigt den Vergleich im Daten-Paging-Betrieb.Cosmic Software
Man sieht also, dass dieser Controller bereits ohne Berücksichtigung aller weiteren hardwaremäßigen Vorzüge bezüglich komplexer Peripherie oder höherer Taktung, einen beliebigen derzeit verwendeten S12 vorteilhaft ersetzen kann. Dasselbe gilt natürlich auch bereits für jede S12X-Applikation die derzeit noch ohne Daten-Paging auskommt. Richtig interessant wird es aber dann, wenn man sich mit seinem S12X-Projekt irgendwo in der Lücke zwischen 16 und 32 Bit befindet:
- Technisch gesehen also womöglich am oberen Ende dessen, was ein voll ausgereizter S12XE unter Verwendung seiner 4 Paging-Mechanismen für die Adressierung von Code und Daten hergibt und am oberen Ende dessen, was ein sehr guter Programmierer gerade noch sicher im Griff behalten kann.
- Ökonomisch gesehen aber möglicherweise in einer Situation, in der man bereits erahnt, dass vorab gemachte Kostenrechnungen für einen Umstieg auf 32 Bit ein nicht wirklich erreichbares und vor allem haltbares Bild zeigen.
In diese Lücke passt der Controller S12Z perfekt.
Paging-Betrieb
Die im Paging-Betrieb oft für automatisch generierten Code hinderlichen Größenbeschränkungen für Funktionen und Datenobjekte entfallen. Der Programmierer wird vom Paging befreit und hierbei vom neuen Compiler unterstützt, der so angelegt ist, dass er bestehenden S12X-Paging-Code selbstständig bereinigt.
Hierzu ein 2. Beispiel, welches gleichzeitig den nun noch krasseren Unterschied zwischen dem Code für den S12X im Daten-Paging-Betrieb und dem für den neuen Controller generierten verdeutlicht. Gut, dies ist lediglich ein extremes Beispiel zu Demons-trationszwecken. Ein versierter Assemblerprogrammierer sieht hier für die S12X-Seite durchaus auch noch Möglichkeiten zur Optimierung, die aber das Ergebnis nicht wesentlich verändern.
Für die Ermittlung von Vergleichszahlen werden solche Beispiele natürlich nicht herangezogen. Hierfür ermitteln Cosmic-Ergebnisse über „normalen“, heute bei den Anwendern im Einsatz befindlichem Applikationscode. Der S12Z erreicht hier eine Codeeinsparung gegenüber dem S12X Paging-Code die zwischen 15 % und 25 % liegt. Dies sieht im ersten Moment recht harmlos aus. Berücksichtigt man aber aus den inzwischen gemachten Erfahrungen beim Umstieg von voll ausgereizten S12X-Applikationen auf verschiedene 32-Bit-Controller, wird der S12Z richtig interessant!
Compiler, Simulator und Hardware-BDM-Debugger sind verfügbar. Komplett wird die Toolkette mit dem integrierten Environment, MISRA-Checker und C Test It für einen nicht instrumentierten Source Unit Test auf Objektebene.
Andreas Wertenauer
(jj)
