Registerinhalt in den Speicher zurückschreiben

Hallo zusammen,

ich habe für die Uni die kleine Aufgabe herauszufinden, welchen Einfluss ich in C und C++ darauf habe, wann eine Variable von einem Variablenregister in den Speicher zurückgeschrieben wird.

Bisher bin ich leider nur auf die Compileranweisung "register" gestoßen, die den Compiler darum bittet die Variable möglichst im Register zu behalten.

Eine andere Möglichkeit, die ich mir vorstellen kann wäre es "ganz viele" Variablen zu deklarieren und die erste davon nur am Anfang zu nutzen, die anderen hingegen recht häufig. Dadurch würde diese Variable wohl automatisch aus den Registern rausgenommen, um die Arbeit mit den anderen Variablen zu optimieren.

Gibt es sonst Möglichkeiten, die erwähnenswert sind? Kann ich z.B. direkt den Inhalt eines Registers auslesen und dann in den Speicher schreiben?

Ich bin dankbar für jede Antwort, Gruß
visum

Mario Sandler

Visum schrieb:

ich habe für die Uni die kleine Aufgabe herauszufinden, welchen Einfluss ich in C und C++ darauf habe, wann eine Variable von einem Variablenregister in den Speicher zurückgeschrieben wird.

Überleg vll. mal ob es sich um eine Fangfrage handeln könnte.
AFAIK hast du darauf keinen Einfluss weder C noch in C++
(man könnte jetzt über inline Assembler nachdenken, aber das hat eben nichts
mehr mit C++ zu tun)

Die Fragestellung ist recht offen, es ist also auch möglich, dass es eigentlich nicht geht.

Inline Assembler zählt denke ich nicht mehr zu der Aufgabe.

hustbaer

"register" ist ein Tip an den Compiler, mehr nicht. Der Compiler kann den Tip beherzigen und versuchen die Variable so lange wie möglich in einem Register zu halten, oder aber beschliessen den Tip zu ignorieren und sich auf seinen eigenen Optimizer zu verlassen.

Was die Frage angeht: "register" ist hier nicht ganz auszuschliessen (da einige, speziell ältere Compiler sich zumindest versuchen daran zu halten), aber es gibt noch ein Keyword welches da relevant ist (und zwar wesentlich mehr als "register"), und das fängt mit "v" an (und ist weder 4 noch 7 Buchstaben lang, nur so als Tip)...

The-Kenny

hustbaer schrieb:

[...]aber es gibt noch ein Keyword welches da relevant ist (und zwar wesentlich mehr als "register"), und das fängt mit "v" an (und ist weder 4 noch 7 Buchstaben lang, nur so als Tip)...

... nicht void
... nicht virtual
volatile?

HRHR, zuufällig habe ich zur gleichen zeit die gleiche aufgabe auch im rahmen einer universitätsveranstaltung bekommen
bekannter hat auch woanders gefragt, wo auch die begriffe register und volatile gefallen sind
aber compileroptimierung is womöglich auch ein stichwort, denn dann tut er das ganze ja selber.
naja, lass ich mal alles in meine antwort mit einfließen (obwohl die frage fies ist, denn das is wieder so, dass man das als richtig oder falsch ansehen kann, je wie der korrekteur das will.. aber wird schon schief gehen)

hustbaer

aber compileroptimierung is womöglich auch ein stichwort, denn dann tut er das ganze ja selber.

Was volatile angeht so *verhindert* das einige Optimierungen. Der Compiler *darf* Zugriffe auf Variablen die volatile sind nicht "wegoptimieren" (und auch nicht gegeneinander "reorder", also die Reihenfolge ändern in der diese Zugriffe ausgeführt werden).

Er darf sie nichtmal mit Zugriffe auf andere Variablen die ebenfalls volatile sind "reordern".

Und zwar deswegen weil

der Compiler/Optimizer nur Dinge ändern darf die das beobachtbare Verhalten eines Programmes nicht ändern und
alle "volatile" Variablen als "beobachtbar" gelten (auch wenn sie der User nie "sieht"!)

Anders gesagt: der Compiler kann was volatile angeht garnix "selber tun", im Gegenteil, man zwingt ihn mit volatile dazu gewisse Dinge auf bestimmte Art und Weise zu tun. Dinge die er sonst anders machen könnte.

p.S.: falls das Statement nur auf das Keyword "register" bezogen war könnte man das wahrscheinlich so sagen - ich beziehe mich hier nur auf "volatile".

BorisDieKlinge

wenn die variabel mit register deklariert ist, ist diese ja definitiv im CPU Register oder???

ohne das schlüsselwort "register" wird die variable kann der compiler entscheiden ob der wert im register bzw. auf speicehr abgelgt wird oder?

register int data=5;

int mem* = new int();

*men= data;

wenn ich nun den wert auf dem heap schreibe, dann ist der wert auch garantiert auf m speicher.

war nur so ne überlegeung.. wenn diese denkweise krottenfalsch ist, bitte nich aufregen *fg*

Simon2

BorisDieKlinge schrieb:

wenn die variabel mit register deklariert ist, ist diese ja definitiv im CPU Register oder???...

ist schon beantwortet:

hustbaer schrieb:

"register" ist ein Tip an den Compiler, mehr nicht. Der Compiler kann den Tip beherzigen und versuchen die Variable so lange wie möglich in einem Register zu halten, oder aber beschliessen den Tip zu ignorieren und sich auf seinen eigenen Optimizer zu verlassen....

Gruß,

Simon2.

hustbaer

BorisDieKlinge schrieb:

wenn die variabel mit register deklariert ist, ist diese ja definitiv im CPU Register oder???

(...)

wenn ich nun den wert auf dem heap schreibe, dann ist der wert auch garantiert auf m speicher.

war nur so ne überlegeung.. wenn diese denkweise krottenfalsch ist, bitte nich aufregen *fg*

rofl
ganz falsch.
der compiler muss lediglich ein programm ausspucken dessen beobachtbares verhalten dem entspricht was das programm laut C++ standard tun müsste.
register und der speicher gelten dabei nicht als "beobachtbar".

ausgenommen eben variablen die man als "volatile" deklariert.

camper

hustbaer schrieb:

BorisDieKlinge schrieb:

wenn die variabel mit register deklariert ist, ist diese ja definitiv im CPU Register oder???

(...)

wenn ich nun den wert auf dem heap schreibe, dann ist der wert auch garantiert auf m speicher.

war nur so ne überlegeung.. wenn diese denkweise krottenfalsch ist, bitte nich aufregen *fg*

rofl
ganz falsch.
der compiler muss lediglich ein programm ausspucken dessen beobachtbares verhalten dem entspricht was das programm laut C++ standard tun müsste.
register und der speicher gelten dabei nicht als "beobachtbar".

ausgenommen eben variablen die man als "volatile" deklariert.

Nicht einmal diese Ausnahme gilt derart uneingeschränkt. Zunächst einmal beschreibt der Standard nur das Verhalten eines abstrakten Automaten, eine tatsächliche Implementation muss lediglich das (als beobachtbar definierte) Verhalten dieses Automaten emulieren. Wie diese Emulation aussehen muss, wird dabei aber nicht festgelegt. Zwar ist die Abfolge von Lese- und Schreibvorgängen auf volatile-Daten beobachtbar im abstrakten Automaten, dessen Emulation muss dagegen nicht unbedingt direkt an der realen Maschine beobachtbar sein.
z.B.:

int main()
{
    srand(time(0));
    int a = rand();
    int b = rand();
    volatile int va;
    volatile int vb;
    for ( int i = 0; i < a; ++i ) va = 0;
    for ( int i = 0; i < b; ++i ) vb = 0;
}

Wenn wir dieses einfache Programm auf einer realen Maschine ausführen, werden wir wahrscheinlich (aber nicht einmal das ist zwingend der Fall) lediglich feststellen, dass die Zeit,die zwischen Beginn und Ende der Ausführung des Programms vergeht, unterschiedlich ist - das ist im Übrigen in der abstrakten Maschine gerade nicht beobachtbar, folglich trifft der Standard auch keine Aussage darüber. Was wir nicht zu "sehen" bekommen, sind die Schreibvorgänge auf va und vb. Nun könnten wir natürlich versucht sein, einen Debugger darauf anzuwenden, um diese Schreibvorgänge sichtbar zu machen - das setzt aber voraus, dass die betreffende Implementation zusätzliche Aussagen darüber macht, wo diese Variablen während des Programmablaufs zu finden sind. In Abwesenheit solcher zusätzlicher Garantien hindert die reale Maschine nichts daran, den Programmablauf sofort zu beenden (also die Variablen "wegzuoptimieren").
Der Standard schreibt keine bestimmte Relation zwischen realem Speicher oder CPU-Registern o.ä. und dem Speicher der abstrakten Maschine vor, nicht einmal, dass dieses Verhältnis während der Programmausführung unverändert bleibt. Das reale Objekt mag während der Ausführung an unterschiedlichen Stellen im Speicher oder auch in CPU-Registern zu finden sein oder überhaupt nicht existieren - wenn und solange das den Teil des beobachtbaren Verhaltens der realen Maschine, der mit dem beobachtbaren Verhalten der abstrakten Maschine korrespondiert, nicht beeinflusst.

Bezogen auf das ursprüngliche Thema bedeutet das, dass diese Fragestellung ohne Bezug auf eine konkrete Implementation (und ein konkretes Programm) sinnlos ist.