7.3 Compiler für eingebettete Systeme
401
namische Speicherverwaltung vor, welche die charakteristischen Eigenschaften von
SPMs berücksichtigt. Bai et al. [32] schlagen vor, dass Programmierer alle Zugriffe
über globale Zeiger mittels zweier Funktionen p2s und s2p kapseln. Diese beiden
Funktionen konvertieren globale in lokale SPM-Adressen bzw. lokale Adressen in
globale Adressen.
Für Stack-Variablen haben Udayakumararan et al. [548] vorgeschlagen, zwei
Stacks zu benutzen: einen für kurze Funktionen, deren Stack im Speicher verbleibt
und einen für zeitaufwändige Funktionen, deren Stack dem SPM zugeordnet wird.
Kannan et al. [282] haben vorgeschlagen, die obersten Stack-Frames in zyklischer
Weise im SPM zu halten. Bei Funktionsaufrufen wird geprüft, ob genug Platz für
den Frame der gerufenen Funktion im SPM vorhanden ist. Wenn der Platz nicht
vorhanden ist, dann werden alte Stack-Frames in einen reservierten Bereich des
Speichers geschrieben. Bei der Rückkehr von Funktionsaufrufen werden diese StackFrames zurückkopiert. Verschiedene Optimierungen zielen auf die Minimierung der
notwendigen Überprüfungen.
Mehrere Threads/Prozesse
Die bisher vorgestellten Ansätze sind noch darauf beschränkt, einen einzelnen Prozess oder Thread3 zu unterstützen. Im Falle mehrerer Prozesse oder Threads muss
berücksichtigt werden, dass Objekte bei Kontextwechseln in den SPM kopiert und
aus diesem verdrängt werden müssen. Verma schlug die drei folgenden Ansätze vor
[555] (dabei gelten Aussagen für Prozesse sinngemäß auch für Threads):
1. Im ersten Ansatz darf nur ein einzelner Prozess gleichzeitig Speicher im SPM belegen. Bei jedem Kontextwechsel wird die Information des verdrängten Prozesses
im SPM gesichert und die Information für den auszuführenden Prozess wird wiederhergestellt. Dieser Ansatz wird als speichernder/wiederherstellender (engl.
saving/restoring) Ansatz bezeichnet. Dieser Ansatz funktioniert nicht gut für
große SPMs, da der Kopiervorgang selbst eine erhebliche Menge an Zeit und
Energie benötigen würde.
2. Beim zweiten Ansatz wird der Speicherplatz des SPMs in Bereiche für die einzelnen Prozesse unterteilt. Die Größe der Partitionen wird durch eine spezielle Optimierung bestimmt. Der SPM wird während der Initialisierung befüllt.
Es sind keine weiteren compilergesteuerten Kopiervorgänge erforderlich. Daher wird dieser Ansatz als nicht-speichernder/wiederherstellender (engl. nonsaving/restoring) Ansatz bezeichnet. Dieser Ansatz ist nur sinnvoll für SPMs,
die groß genug sind, um Speicherbereiche für mehrere Prozesse bereitzuhalten.
3. Der dritte Ansatz ist ein hybrider Ansatz: Der SPM wird in einen gemeinsam von
allen Prozessen genutzten Bereich und einen zweiten Bereich, in dem Prozesse
exklusiven Speicherplatz erhalten können, unterteilt. Die Größe beider Bereiche
wird durch eine Optimierung bestimmt.
3 Siehe Definitionen 4.1 und 4.2.
401
namische Speicherverwaltung vor, welche die charakteristischen Eigenschaften von
SPMs berücksichtigt. Bai et al. [32] schlagen vor, dass Programmierer alle Zugriffe
über globale Zeiger mittels zweier Funktionen p2s und s2p kapseln. Diese beiden
Funktionen konvertieren globale in lokale SPM-Adressen bzw. lokale Adressen in
globale Adressen.
Für Stack-Variablen haben Udayakumararan et al. [548] vorgeschlagen, zwei
Stacks zu benutzen: einen für kurze Funktionen, deren Stack im Speicher verbleibt
und einen für zeitaufwändige Funktionen, deren Stack dem SPM zugeordnet wird.
Kannan et al. [282] haben vorgeschlagen, die obersten Stack-Frames in zyklischer
Weise im SPM zu halten. Bei Funktionsaufrufen wird geprüft, ob genug Platz für
den Frame der gerufenen Funktion im SPM vorhanden ist. Wenn der Platz nicht
vorhanden ist, dann werden alte Stack-Frames in einen reservierten Bereich des
Speichers geschrieben. Bei der Rückkehr von Funktionsaufrufen werden diese StackFrames zurückkopiert. Verschiedene Optimierungen zielen auf die Minimierung der
notwendigen Überprüfungen.
Mehrere Threads/Prozesse
Die bisher vorgestellten Ansätze sind noch darauf beschränkt, einen einzelnen Prozess oder Thread3 zu unterstützen. Im Falle mehrerer Prozesse oder Threads muss
berücksichtigt werden, dass Objekte bei Kontextwechseln in den SPM kopiert und
aus diesem verdrängt werden müssen. Verma schlug die drei folgenden Ansätze vor
[555] (dabei gelten Aussagen für Prozesse sinngemäß auch für Threads):
1. Im ersten Ansatz darf nur ein einzelner Prozess gleichzeitig Speicher im SPM belegen. Bei jedem Kontextwechsel wird die Information des verdrängten Prozesses
im SPM gesichert und die Information für den auszuführenden Prozess wird wiederhergestellt. Dieser Ansatz wird als speichernder/wiederherstellender (engl.
saving/restoring) Ansatz bezeichnet. Dieser Ansatz funktioniert nicht gut für
große SPMs, da der Kopiervorgang selbst eine erhebliche Menge an Zeit und
Energie benötigen würde.
2. Beim zweiten Ansatz wird der Speicherplatz des SPMs in Bereiche für die einzelnen Prozesse unterteilt. Die Größe der Partitionen wird durch eine spezielle Optimierung bestimmt. Der SPM wird während der Initialisierung befüllt.
Es sind keine weiteren compilergesteuerten Kopiervorgänge erforderlich. Daher wird dieser Ansatz als nicht-speichernder/wiederherstellender (engl. nonsaving/restoring) Ansatz bezeichnet. Dieser Ansatz ist nur sinnvoll für SPMs,
die groß genug sind, um Speicherbereiche für mehrere Prozesse bereitzuhalten.
3. Der dritte Ansatz ist ein hybrider Ansatz: Der SPM wird in einen gemeinsam von
allen Prozessen genutzten Bereich und einen zweiten Bereich, in dem Prozesse
exklusiven Speicherplatz erhalten können, unterteilt. Die Größe beider Bereiche
wird durch eine Optimierung bestimmt.
3 Siehe Definitionen 4.1 und 4.2.