-
Stand der Technik
-
Die
vorliegende Erfindung betrifft ein Verfahren zur Code-Komprimierung nach
Anspruch 1, ein Verfahren zur Code-Dekomprimierung nach Anspruch 10, eine
Komprimierungseinrichtung nach Anspruch 13 und eine Dekomprimierungseinrichtung nach
Anspruch 15.
-
Insgesamt
ist gerade der Bereich der Code-Komprimierung und Code-Dekomprimierung
ein sehr aktuelles Thema. Besonders im Automobil-Steuerprogramm-Sektor
bietet dieser Bereich den Vorteil, dass sich nicht nur die Code-Komprimierung auf
den Steuergeräten
effizienter auswirken würde, sondern
ein großes
Optimierungspotential auch bei der Komprimierung benötigter Kennlinien
und anderer Daten liegt. Ein Beispiel hierzu sind die Kennfeld/Kurvenverläufe aus
der Motorsteuerung. Diese Daten treten immer in der gleichen Konstellation
auf und belegen damit „unnötig” viel Speicher.
Die Datenkompression wird hier derzeit meist noch nicht betrachtet,
da das Potential in gewisser Weise eine Besonderheit des Automobil-Steuerprogramm-Sektors darstellt.
-
Die
im Automobil-Steuerprogramm-Sektor verwendete Programmiermethodik
basiert auf der unabhängigen
Programmierung einzelner Funktionen. Dies hat zur Folge, dass gleiche
oder ähnliche Codeabschnitte
in verschiedenen Funktionsimplementierungen vorkommen. Eine Untersuchung
der Häufigkeit
von Code-Kopien hat aufgezeigt, dass sich der Code durch diese wiederholte
Implementierung der gleichen Abschnitte vergrößert, und dass mehr Speicher
für den
Programmcode benötigt
wird.
-
Um
dies zu umgehen, zeigt der Stand der Technik einige Ansätze auf.
-
Ein
erster Ansatz betrifft die Verwendung von Funktionsbibliotheken.
Hierbei erhöht
sich jedoch die Laufzeit durch CALL-Aufrufe und allgemeinere Ansätze. Ein
Nachteil hierbei ist, dass sich die Berechnungszeit erhöht. Außerdem ist
ein Eingriff in die Programmiermethodik notwendig, welches zu Beeinträchtigungen
einer Software-Lösung und
in ungünstigen
Fällen
zu fehlerhaften Routinen führen
kann.
-
Ein
zweiter Ansatz betrifft die Hardware-Code-Komprimierung. Dieser
Ansatz kann auf Bit-Ebene vorgenommen werden (beispielsweise PowerPC CodePack).
Ein vorteilhafter Aspekt liegt darin, dass Code/Daten auch vor einem
nicht autorisierten Zugriff anderer geschützt sind. Es hat sich jedoch
als nachteilig erwiesen, dass eine relativ komplexe Hardware notwendig
ist, um Laufzeiteinbußen
zu vermeiden.
-
Dieser
Ansatz kann ebenfalls vorgenommen werden, indem auf andere, kleinere
Anweisungs-Sätze,
wie beispielsweise Thumb, MIPS, usw, ausgewichen wird. Hierbei handelt
es sich um Prozessoren, welche unterschiedliche Anweisungssätze haben. Vorteilhafterweise
liegt ein direkt kleinerer Code ohne Komprimierung vor. Dies hat
sich jedoch als schwierig erwiesen, da eine Interoperabilität zwischen
verschiedenen Betriebsmodi beschränkt umsetzbar ist. Hierbei
erweist sich die vielfache Umschaltung als aufwendig, da ein mehrfaches
Umschalten zwischen unterschiedlichen Modi aufwendig ist.
-
Dieser
Ansatz kann ebenfalls vorgenommen werden, indem ganze Abschnitte
durch neue eigene Befehle ersetzt werden. Vorteilhafterweise liegt
ein direkt kleinerer Code ohne Komprimierung und ohne Anwendung
verschiedener Betriebsmodi vor. Es hat sich jedoch als nachteilig
erwiesen, dass die Anzahl der Operationen pro Befehl und die Anzahl
neuer Befehle begrenzt sind.
-
Es
hat sich als Nachteilig erwiesen, dass die im Stand der Technik
verwendeten Ansätze
zur Code-Komprimierung und -Dekomprimierung unzulänglich sind.
-
Offenbarung der Erfindung
-
Der
Vorteil der vorliegenden Erfindung besteht in der Bereitstellung
einer Code-Komprimierung und -Dekomprimierung unter Vermeidung einer
aufwendigen Dekodierungs-Hardware. Ferner wird die benötigte Speichergröße drastisch
gesenkt.
-
Dieser
Vorteil wird durch ein Verfahren zur Code-Komprimierung erzielt, welches die Schritte enthält: Übersetzen
eines Codes durch einen Compiler; Untersuchen des Codes auf sich
wiederholende Fragmente; Sortieren der Fragmente nach einem Bewertungsschema;
Bewerten der sortierten Fragmente in Ansprechen auf einen Schwellwert,
welcher anzeigt, ob eine Zusammenfassung sinnvoll ist oder nicht;
und Komprimieren des Codes, wenn die Bewertung anzeigt, dass eine
Zusammenfassung sinnvoll ist.
-
Die
Erfindung geht dabei von der Überlegung aus,
dass, im Gegensatz zu den bekannten spekulativen Komprimierungsverfahren,
eine vollständige Analyse
der zu komprimierenden Daten durchgeführt wird, um somit eine „optimale” Komprimierung
zu erreichen. Dieses Verfahren komprimiert mit „hohem” Aufwand den Code bzw die
Daten derart, sodass für die
Dekomprimierung lediglich eine einfache Schaltungserweiterung notwendig
ist, welche die Instruktionen bzw Daten der CPU transparent in Echtzeit
zur Verfügung
stellt. Auf diese Weise muss die Programmiermethodik nicht angepasst
werden. Ferner behält der Prozessor
seine normale Schnittstelle bei. Trotzdem werden der Code bzw die
Daten komprimiert im Speicher gehalten. Durch diese Überlegung
sinkt der Speicherbedarf.
-
Für die Komprimierung
scheint gerade der Automobil-Sektor besonders geeignet, da der Speicher
in dieser Sparte teuer ist und die Programmiermethodik einen hohen
Komprimierungsfaktor verspricht. Es ist denkbar, dass eine solche
Hardware-Einheit mit herkömmlichen
Speichern und Prozessoren kombiniert wird, wodurch ebenfalls Kosten eingespart
werden können.
Somit kommen die Vorteile sehr einfach zum tragen. Gerade bei einer
Verwendung von System-Lösungen,
wie beispielsweise ”System
in Package”, ”System
an Chip”,
usw scheint eine solche Anwendung besonders einfach.
-
Bevorzugte
Weiterbildungen des Verfahrens zur Code-Komprimierung sind in den Unteransprüchen 2 bis
12 angegeben.
-
Danach
ist in einer vorteilhaften Ausführungsform
vorgesehen, dass der Untersuchungsschritt jene Fragmente mit mehr
als einer Instruktion untersucht. Bevorzugt wird der Code dann komprimiert,
wenn die Anzahl der Instruktionen in Fragmenten mit mindestens zwei
Instruktionen einen zuvor eingestellten Schwellwert übersteigt.
Dieser Schwellwert kann zuvor anwenderspezifisch bestimmt werden.
Alternativ bevorzugt wird der Code nicht komprimiert, wenn die Anzahl
der Instruktionen in den Fragmenten einen zuvor eingestellten Schwellwert
unterschreitet. In einem solchen Fall wäre eine Zusammenfassung ineffizient.
-
Bevorzugt
wird eine Priorisierung der Fragmente vorgenommen, um möglichst
viel Speicherplatz einzusparen. Bevorzugt wird eine Code-Bibliothek
mit den Code-Fragmenten an einer beliebigen Stelle im Speicher abgelegt.
Weiter bevorzugt wird jedes Fragment an der Stelle des ersten Auftretens abgelegt.
-
Bei
einer Software-Realisierung werden die Fragmente an der Stelle mit
dem häufigsten
Auftreten abgelegt. Weiter bevorzugt wird die Untersuchung des Codes
durch eine dem Compiler nachgeschaltete Einrichtung vorgenommen.
Somit werden auch Parameter berücksichtigt.
-
Ein
Vorteil dieser Aspekte liegt darin, dass eine bereits bestehende
Hardware weiterverwendet werden kann. Dieser Aspekt der Vermeidung
der erhöhten
Laufzeit kann durch zumindest einen Compiler gelöst werden.
-
Die
vorstehenden Vorteile der Erfindung werden auch durch ein Verfahren
zur Code-Dekomprimierung eines gemäß den obigen Aspekten komprimierten
Codes erzielt, bei welchem der sich in einem Speicher befindliche
komprimierte Code in Ansprechen auf eine Nachschlage-Tabelle derart
dekomprimiert wird, sodass er für
einen mit dem Speicher verbundenen Prozessor linear erscheint.
-
Bevorzugt
wird eine Schaltungserweiterung zur Dekomprimierung einen Anweisungs-Satz
interpretieren und auswerten. Somit ähneln die Kompressionen den
#define-Anweisungen aus der Programmiersprache C. Daher würde eine
solche Anweisung beispielsweise einfach nur jene Adresse enthalten, an
der sich der nächste
Codeblock befindet. Dies ähnelt
einem CALL, bei dem keine Register (außer der internen „Rücksprungadresse”) gesichert
werden müssen
und/oder Parameter bzw Rückgabewerte übergeben
werden müssen.
Gleichzeitig geschieht dies für
die eigentliche CPU in Nullzeit, da beispielsweise durch eine kleine
Pipeline der Speicherzugriff wieder auf das gewohnte Maß beschleunigt
werden kann.
-
Weiter
bevorzugt wird eine Code-Bibliothek mit den Code-Fragmenten an einer beliebigen Stelle im
Speicher abgelegt.
-
Die
vorstehenden Vorteile der Erfindung werden auch durch eine Komprimierungseinrichtung
zur Code-Komprimierung erzielt, welche enthält: einen Compiler zum Übersetzen
eines Codes; eine Untersuchungseinrichtung zum Untersuchen des Codes auf
sich wiederholende Fragmente; eine Sortierungseinrichtung zum Sortieren
der Fragmente nach einem Bewertungsschema; eine Bewertungseinrichtung
zum Bewerten der sortierten Fragmente in Ansprechen auf einen Schwellwert,
welcher anzeigt, ob eine Zusammenfassung sinnvoll ist oder nicht;
und eine Komprimierungseinrichtung zum Komprimieren des Codes, wenn
die Bewertung anzeigt, dass eine Zusammenfassung sinnvoll ist.
-
Ein
wesentlicher Punkt der erfindungsgemäßen Komprimierungseinrichtung
besteht darin, dass eine vollständige
Analyse der zu komprimierenden Daten durchgeführt wird, um somit eine effiziente Komprimierung
zu erreichen. Dadurch werden der Code bzw die Daten derart komprimiert,
sodass für die
Dekomprimierung lediglich eine einfache Schaltungserweiterung notwendig
ist, die die Instruktionen bzw Daten der CPU transparent in Echtzeit
zur Verfügung
stellt. Auf diese Weise braucht die Programmiermethodik nicht angepasst
zu werden und behält der
Prozessor seine normale Schnittstelle. Zusätzlich werden der Code bzw
die Daten komprimiert im Speicher gehalten, wodurch sich der Speicherbedarf
reduziert.
-
Bevorzugte
Weiterbildungen der Komprimierungseinrichtung sind in dem Unteranspruch
14 angegeben.
-
Danach
ist in einer bevorzugten Ausprägung der
Komprimierungseinrichtung vorgesehen, dass sie eine dem Compiler
nachgeschaltete Einrichtung enthält,
welche die Untersuchung des Codes vornimmt.
-
Die
vorstehenden Vorteile der Erfindung werden auch durch eine De komprimierungseinrichtung zur
Code-Dekomprimierung eines gemäß der Komprimierungseinrichtung
zur Code-Komprimierung nach
einem der obigen Aspekten komprimierten Codes erzielt, welche einen
Speicher enthält,
welcher einen Code gespeichert hält,
welcher in Ansprechen auf eine Nachschlage-Tabelle derart gestaltet
ist, sodass er für
einen mit dem Speicher verbundenen Prozessor linear erscheint.
-
Bevorzugte
Weiterbildungen der Dekomprimierungseinrichtung sind in dem Unteranspruch
16 angegeben.
-
Danach
ist in einer bevorzugten Ausprägung der
Dekomprimierungseinrichtung vorgesehen, dass sie eine Schaltungserweiterung
enthält,
welche einen vorweg geschalteten Anweisungs-Satz interpretiert und
auswertet.
-
Die
vorliegende Erfindung wird im Folgenden anhand eines Ausführungsbeispiels
des erfindungsgemäßen Verfahrens
unter Bezugnahme auf die beiliegenden Figuren näher erläutert. Gleiche oder gleichwirkende
Teile sind mit gleichen Bezugsziffern versehen. Es zeigen:
-
1 ein
schematisches Schaubild von einer Nachschlage-Tabelle;
-
2 ein
schematisches Schaubild von einer Nachschlage-Tabelle mit einem Versatz;
-
3 ein
schematisches Schaubild von einem Voranweisungs-Satz; und
-
4 ein
schematisches Schaubild von einer Code-Komprimierung.
-
Die 1 zeigt
ein schematisches Schaubild von einer Nachschlage-Tabelle LUT (LookUp-Tabelle).
Hierbei wird eine original angeforderte Speicheradresse OS, wie
beispielsweise eine Originaladresse bei der Stelle 0x<org_adr>, an den Eingang einer Adress-Übersetzungs-Tabelle
AT überführt. Der
Ausgang der Adress-Übersetzungs-Tabelle
AT stellt eine reale „übersetzte” Speicheradresse
RS bereit, wie beispielsweise eine Fragmentadresse bei der Stelle 0x<map_adr>, die einem Speicher
S übergeben wird.
-
2 zeigt
ein schematisches Schaubild von einer Nachschlage-Tabelle mit einem
Versatz LUT-Off (LookUp-Tabelle mit Offset). Hierbei wird die original
angeforderte Speicheradresse OS, wie beispielsweise die Originaladresse
bei der Stelle 0x<org_adr>, an den Eingang einer
Verknüpfungs-Einrichtung
VE eingegeben. Die Adress-Übersetzungs-Tabelle
AT stellt an ihrem Ausgang eine Versatz-Speicheradresse VS bereit, wie beispielsweise
eine Versatzadresse bei der Stelle 0x<offset>. Diese Versatz-Speicheradresse VS wird ebenfalls der
Verknüpfungs-Einrichtung VE bereitgestellt.
Die Verknüpfungs-Einrichtung
VE verknüpft
die beiden Speicheradressen und stellt an ihrem Ausgang die reale „übersetzte” Speicheradresse
RS, wie beispielsweise die Fragmentadresse bei der Stelle 0x<map_adr>, bereit, die dem Speicher
S übergeben wird.
-
3 zeigt
ein schematisches Schaubild von einem Voranweisungs-Satz PIS (PreInstruction Set).
Hierbei wird eine Adresse aus einem Programm-Zähler PC (Program Counter),
wie beispielsweise die Originaladresse bei der Stelle 0x<org_adr>, an einen Rücksprung-Stapel
RSS (Rücksprung-Stack) überführt. Bei
diesem Schritt wird der Programm-Zähler PC gesichert. Ferner werden
Adressen aus einem Befehlsspeicher BS an den Programm-Zähler PC überführt. Der
Befehlsspeicher BS kann neben den Adressen ferner eine Mehrzahl von
Spezialanweisungs-Kennzeichen SF (Spezialanweisungs-Flag) enthalten.
Bei diesem Schritt wird der Programm-Zähler PC durch eine Adresse
ersetzt. Ferner werden weiterhin Befehle aus dem Befehlsspeicher
BS an den Programm-Zähler
PC überführt, wobei
bei diesem Schritt eine Adresse aus einem Stapel entnommen wird
und der Programm-Zähler PC
ersetzt wird.
-
Die
Anweisungen an den Voranweisungs-Satz PIS haben aus Sicht des Systems
einen „virtuellen” Befehlsspeicher
VBS zu folge, wie auf der rechten Seite in der Figur angezeigt.
-
Die
Anweisungen haben den Vorteil, dass die Routinen für das System
transparent erscheinen. Ferner können
die Routinen durch eine entsprechende Hardware auch innerhalb eines
Taktes realisiert werden. Dies hat den Vorteil, dass dem Programmfluss
keine Verzögerungen
auferlegt werden. Außerdem
können
Bereiche innerhalb der Routine verschachtelt sein, welches ebenfalls
einer Verzögerung des
Programmflusses entgegenwirkt.
-
Die 4 zeigt
ein schematisches Schaubild von einer Code-Komprimierung. Hierbei wird ein Voranweisungs-Satz
durch eine Schaltungserweiterung interpretiert und ausgewertet.
Bevor ein Programm oder Daten in einen Speicher geschrieben werden, müssen sie
komprimiert werden, da die Hardware lediglich eine Dekodierung unterstützt. Gleichzeitig wird
das Programm voraussichtlich nicht-linear im Speicher liegen. Allerdings
präsentiert
sich der Speicher nach außen
hin als linear, sodass die interne Speicherstruktur nur schwer nachgewiesen
werden kann.
-
Bei
dem Verfahren werden Codes, beispielsweise Code A, Code B und Code
C, unterschiedlicher Framente, beispielsweise der Funktionen FktX,
FktY (Funktion X und Funktion Y), durch einen Compiler C in Funktionswerte
umgesetzt. Hierbei sind die Funktionen FktX, FktY hintereinander
geschrieben. In einem weiteren Schritt werden die Befehle durch
einen Compiler zu einer Funktionseinheit FktX + FktY zusammengefasst.
Ferner zeigen Zeiger auf jeweilige Stellen in einer Funktions-”Bibliothek” B. Anschließend komprimiert
der Encoder den Code nach gleichen Fragmenten.
-
Zur
Umsetzung kann ein Voranweisungs-Satz durch eine Schaltungserweiterung
interpretiert und ausgewertet werden. Somit ähneln die Kompressionen den
#define-Anweisungen, wie aus der Programmiersprache C bekannt. Somit
würde eine
solche Anweisung beispielsweise einfach nur jene Adresse enthalten,
an der sich der nächste
Codeblock befindet. Dies ähnelt
einem CALL, bei dem keine Register (außer der internen „Rücksprungadresse”) gesichert
werden müssen
und/oder Parameter bzw Rückgabewerte übergeben
werden müssen.
Gleichzeitig geschieht dies für
die eigentliche CPU in Nullzeit, da der Speicherzugriff beispielsweise
durch eine kleine Pipeline wieder auf das gewohnte Maß beschleunigt
werden kann.
-
Auf
Grund des aufwendigeren Komprimierens ist dieser Zwischenschritt
notwendig, sodass Hardware-Hersteller auf dieses Feature eingehen müssen. Wenn
die Schaltungserweiterung außerhalb des
Speichers stattfindet, ist eine solche Hardware-Einheit direkt oder
indirekt zwischen dem Speicher und einer Berechnungseinheit zu finden.
-
Beispielsweise
kann eine solche Hardware-Einheit mit herkömmlichen Speichern und Prozessoren
kombiniert werden, wobei die Vorteile somit sehr einfach zum Tragen
kommen.
-
Gerade
bei der Verwendung von System-Lösungen,
beispielsweise ”System
in Package”, ”System
an Chip”,
usw scheint eine solche Anwendung besonders einfach. Die Lösung kann
auch bei anderen Anwendungsbereichen umgesetzt werden, bei denen
der Speicher begrenzt bzw teuer ist. Eine Umsetzung ist ebenfalls
bei Anwendungen möglich,
bei denen Kennlinien oder ein ähnlicher
Programmcode auftreten, wie beispielsweise im Mobilfunk-Bereich.