Während Programmlaufzeit Name einer Variable ändern?

SeppJ

Das Problem ist, dass ich gar nicht ausdrücken kann, was im Maschinencode eine Variable ist. Daher das nebulöse Wort "Konzept". Das hast du wohl zu konkret verstanden, als dass es da noch Variablen gäbe. Aber da ist nicht mehr wirklich etwas, was man als Variable bezeichnen kann. Auch das mit den nicht-Basisdatentypen muss ich noch einschränken, da es eigentlich eher eine Frage ist, inwiefern der Compiler noch seine Optimierungsmagie anwenden kann oder nicht, was ihm bei nicht-Basisdatentypen erheblich schwerer fallen sollte. Daher gibt es in dem Fall noch am ehesten so eine Beziehung Variable <-> Speicheradresse. Aber auch nicht immer. Ebenso, wenn der Quellcode explizit anfängt, diese Beziehung explizit zu nutzen, etwa wenn der Adressoperator benutzt wird. Aber im Allgemeinen gibt es solch eine Beziehung nicht.

Nexus

mgaeckler schrieb:

Das habe ich ja auch nicht behauptet. Ich meine nur, es gibt immer noch Variablen, da es aber keine 1:1 Beziehung gibt, sind es natürlich andere Variablen.

Du verstrickst dich in Widersprüche.

Variablen sind ein Konzept einer Programmiersprache. Sie haben keine physikalische Existenz -- anders als Speicherbereiche und Bits. Da bei C++ nach der Übersetzung nicht mehr viel von C++ übrig bleibt, gibt es zur Laufzeit auch keine Variablen mehr.

Im Maschinencode gibt es andere Konzepte (wie z.B. Register), auf dieser Ebene würde ich nicht mehr von Variablen sprechen.

hustbaer

Nexus schrieb:

...

+1
Kurz und verständlich auf den Punkt gebracht

mgaeckler

Nexus schrieb:

mgaeckler schrieb:

Das habe ich ja auch nicht behauptet. Ich meine nur, es gibt immer noch Variablen, da es aber keine 1:1 Beziehung gibt, sind es natürlich andere Variablen.

Du verstrickst dich in Widersprüche.

Wo findest Du 'nen Widerspruch?

Nexus schrieb:

Im Maschinencode gibt es andere Konzepte (wie z.B. Register), auf dieser Ebene würde ich nicht mehr von Variablen sprechen.

Ich schon. Nur weil die Variablen keine Namen sondern nur noch wie auch immer geartete Adressen haben sind es in meinen Augen immer noch Variablen.

mfg Martin

TNA

mgaeckler schrieb:

Nur weil die Variablen keine Namen sondern nur noch wie auch immer geartete Adressen haben sind es in meinen Augen immer noch Variablen.

Variablen haben zur Laufzeit nicht zwingend eine "wie auch immer geartete" Adresse. Die können in bestimmten Fällen z.B. als Direktoperand direkt in Maschienenbefehle eincompiliert oder komplett wegoptimiert werden. Es gibt zur Laufzeit keine 1:1 Entsprechung mehr von einer Variablen zu einem bestimmten Ort.

mgaeckler

TNA schrieb:

mgaeckler schrieb:

Nur weil die Variablen keine Namen sondern nur noch wie auch immer geartete Adressen haben sind es in meinen Augen immer noch Variablen.

Variablen haben zur Laufzeit nicht zwingend eine "wie auch immer geartete" Adresse. Die können in bestimmten Fällen z.B. als Direktoperand direkt in Maschienenbefehle eincompiliert oder komplett wegoptimiert werden. Es gibt zur Laufzeit keine 1:1 Entsprechung mehr von einer Variablen zu einem bestimmten Ort.

Dann sind sie ja auch keine Variable. Also z.B. (ist jetzt zwar Assembler und nicht Maschinencode, weil ich den nicht mehr auswendig habe):

move.w #10, d0

Da ist #10 keine Variable, aber d0, was ein Register der MC68000er CPU ist.

mfg Martin
P.S.: Denkt beim Begriff Variable nicht zu sehr in Hochsprachen

TNA

mgaeckler schrieb:

P.S.: Denkt beim Begriff Variable nicht zu sehr in Hochsprachen

Wenn du hier ein Konzept von Variablen diskutieren möchtest, dass nicht dem von Hochsprachen entspricht bist du wahrscheinlich im falschen Forum. Unter Assembler spricht man aber auch meines Erachtens nicht von Variablen und namen haben die auch dort nicht.

hustbaer

Ausserdem ist Assembler != Maschinencode.
In Assembler gibt's noch Labels und was nicht noch alles. In Maschinencode gibt's im Prinzip gar nix mehr ausser Maschinenbefehle.

Und wenn man sich ein Binary anguckt, dann verschwimmt auch noch die Grenze zwischen Maschinencode und einer Bytewurst.
Im Endeffekt kann man nur sagen wo welche Maschinenbefehle stehen, wenn man ein Programm ausführt. Man denke nur an Sprünge mit berechneten Zieladressen, self-modifying Code etc.

@mgaeckler
Dein Verständnis des Begriffs "Variable" entspricht nicht dem was die allermeisten anderen Programmierer darunter verstehen.
Vermutlich wäre es also intelligent dein Verständnis des Begriffs anzupassen. Du kannst aber natürlich auch gerne damit weitermachen gegen den Wind zu laufen. Bringt nur niemandem was.

Oder Kurzfassung: der Rest der Welt hat Recht, nicht du.

mgaeckler

hustbaer schrieb:

Ausserdem ist Assembler != Maschinencode.
In Assembler gibt's noch Labels und was nicht noch alles. In Maschinencode gibt's im Prinzip gar nix mehr ausser Maschinenbefehle.

Und wenn man sich ein Binary anguckt, dann verschwimmt auch noch die Grenze zwischen Maschinencode und einer Bytewurst.
Im Endeffekt kann man nur sagen wo welche Maschinenbefehle stehen, wenn man ein Programm ausführt. Man denke nur an Sprünge mit berechneten Zieladressen, self-modifying Code etc.

@mgaeckler
Dein Verständnis des Begriffs "Variable" entspricht nicht dem was die allermeisten anderen Programmierer da5runter verstehen.
Vermutlich wäre es also intelligent dein Verständnis des Begriffs anzupassen. Du kannst aber natürlich auch gerne damit weitermachen gegen den Wind zu laufen. Bringt nur niemandem was.

Oder Kurzfassung: der Rest der Welt hat Recht, nicht du.

Mir kann es ja wurscht sein aber lies das mal

http://de.wiktionary.org/wiki/Variable

hustbaer schrieb:

Ausserdem ist Assembler != Maschinencode.
In Assembler gibt's noch Labels und was nicht noch alles. In Maschinencode gibt's im Prinzip gar nix mehr ausser Maschinenbefehle.

Und wenn man sich ein Binary anguckt, dann verschwimmt auch noch die Grenze zwischen Maschinencode und einer Bytewurst.
Im Endeffekt kann man nur sagen wo welche Maschinenbefehle stehen, wenn man ein Programm ausführt. Man denke nur an Sprünge mit berechneten Zieladressen, self-modifying Code etc.

@mgaeckler
Dein Verständnis des Begriffs "Variable" entspricht nicht dem was die allermeisten anderen Programmierer darunter verstehen.
Vermutlich wäre es also intelligent dein Verständnis des Begriffs anzupassen. Du kannst aber natürlich auch gerne damit weitermachen gegen den Wind zu laufen. Bringt nur niemandem was.

Oder Kurzfassung: der Rest der Welt hat Recht, nicht du.

Du bist nicht der Rest der Welt, also sprich am besten erstmal nur für dich selbst. Der Begriff "Variable" ist ein sehr allgemeiner. Und was eine Variable ist oder nicht ist auch Kontextabhängig. Mal abstrakt und einfach: bei f(x,y)=xy sind x und y Variablen, bei f(x)=xy ist nur x eine Variable (genauer gesagt: die Bezeichnung einer Variable). Nun wird es wahrscheinlich so sein, dass das was man im Kontext des Programmierens als Variable verstanden wird in den meisten Fällen auch im Programmablauf normalerweise so verstanden wird. Ausnahme z.B. const int i = 5. Hier gilt i als Variable, obwohl es sich im Programmablauf (im Normalfall) nicht mehr ändert - und evtl auch gar nicht mehr im Maschinencode direkt vorhanden ist. Es gibt übrigens (mindestens) einen guten Grund das im Kontext des Programmierens trotzdem als Variable zu bezeichnen. Denn man kann auch die "5" durch eine "6" austauschen, dann steht "const int i = 6" da.
Bleibt noch die Preisfrage:
Ist "5" bzw "6" - ohne jetzt speziell einen Programmkontext anzunehmen - eine Variable ? (Hinweis: sowohl "ja" als auch "nein" würde ich als falsche Antwort verstehen )
Auch wenn derjenige der etwas schreibt in der Verantwortung steht sich klar auszudrücken, sind an einer Kommunikation immer noch zwei beteiligt, und der Leser sollte sich durchaus auch bemühen zu verstehen was sein Gegenüber ausdrücken will. Mal so meiner Meinung nach.
Lies dir vielleicht nochmal durch was mgaeckler geschrieben hat.

volkard

kleiner Troll schrieb:

Du bist nicht der Rest der Welt, also sprich am besten erstmal nur für dich selbst. Der Begriff "Variable" ist ein sehr allgemeiner. Und was eine Variable ist oder nicht ist auch Kontextabhängig. Mal abstrakt und einfach: bei f(x,y)=xy sind x und y Variablen, bei f(x)=xy ist nur x eine Variable (genauer gesagt: die Bezeichnung einer Variable).

Hier darfste ruhig sagen, daß y die Variable ist und 'y' deren Bezeichnung.

Kannst auch schlecht
http://de.wikipedia.org/wiki/Variable_(Programmierung)
erklären mit
http://de.wikipedia.org/wiki/Variable_(Mathematik)

http://de.wikipedia.org/wiki/Abhängige_und_unabhängige_Variable
http://de.wikipedia.org/wiki/Nichtterminalsymbol
http://de.wikipedia.org/wiki/Variable_(Logik)
http://de.wikipedia.org/wiki/Statistische_Variable
http://de.wikipedia.org/wiki/Zufallsvariable
http://de.wikipedia.org/wiki/Veränderlicher_Stern

hustbaer

@mgaeckler
Wenn du die Register, und evtl. auch die Adressierbaren Speicherstellen als Variablen bezeichnen willst, OK. Soll sein. Finde ich zwar komisch, aber gut.
Nur... wo "sind" die im Maschinenprogramm?
Eine bestimmte Maschine hat immer die selben "Variablen", das Programm ändert daran nichts. Es kann sie bloss verwenden. Und wenn es auf ner anderen Maschine läuft, die vielleicht ein paar Register mehr hat, oder mehr oder weniger Speicher, dann gibt's da andere "Variablen" - trotz dem das selbe Maschinenprogramm darauf läuft.

Macht es dann Sinn zu sagen dass "im Maschinenprogramm Variablen sind"? MMn. nein.

@kleiner Troll
Du schreibst dass Kontext wichtig ist. Richtig. Kontext haben wir hier aber genug. Wenn dir also 'was nicht passt, dann bringt bitte ein Konkretes Beispiel. Wo sollen "in" dem Maschinenprogramm von dem die Rede war (das das der Compiler aus nem C++ Programm generiert, auch wenn es fälschlicherweise immer wieder als Assemblerprogramm bezeichnet wurde) die Variablen sein?

sC++k

asfdlol schrieb:

suchst du vielleicht referenzen?
int a = 123;
int& b = a;
b += 42;

Nein.

Hinweis: Ja ich weiß, mit STL Containern geht es u. es ist glaub ich auch die einzigste Möglichkeit es zu tun.

OK, ich glaub ich hab ungefähr verstanden warum es nicht gehen sollte.
Habt Dank!
Von "meiner" Seite aus

CLOSED

mgaeckler

hustbaer schrieb:

@mgaeckler
Wenn du die Register, und evtl. auch die Adressierbaren Speicherstellen als Variablen bezeichnen willst, OK. Soll sein. Finde ich zwar komisch, aber gut.

Komisch ist es schon. Da gebe ich Dir recht. Da ein Assembler- oder Maschinencodeprogramierer (das macht aber wohl keiner mehr, ich hab das zuletzt vor 30 Jahren gemacht) sich darum kümmern muß, wo GENAU die Variablen stehen, spricht man natürlich einfach eher von Adresse (bei Assember auch von Symbolen) und Register als von Variable.

hustbaer schrieb:

Nur... wo "sind" die im Maschinenprogramm?

Da hängt von der CPU ab. Wie das bei Intelprozessoren ausschaut, weiß ich nicht. Bei Motorola war es so, daß einige Bits des Opcodes immer die Nummer des Registers enthalten. Wie genau das funktionierte, weiß ich nicht mehr. Ich habe schon seit 20 Jahren keinen Motorolacode mehr gesehen.

hustbaer schrieb:

Eine bestimmte Maschine hat immer die selben "Variablen", das Programm ändert daran nichts. Es kann sie bloss verwenden. Und wenn es auf ner anderen Maschine läuft, die vielleicht ein paar Register mehr hat, oder mehr oder weniger Speicher, dann gibt's da andere "Variablen" - trotz dem das selbe Maschinenprogramm darauf läuft.

Macht es dann Sinn zu sagen dass "im Maschinenprogramm Variablen sind"? MMn. nein.

Wenn man den Begriff Variable so auslegt, wie in dem von mir verlinkten Artikel, dann ja, da es eine veränderbare (=variabel) Speicherstelle ist. Ob es allerdings geschickt ist, das ist wieder eine andere Frage.

mfg Martin

hustbaer

mgaeckler schrieb:

hustbaer schrieb:

Nur... wo "sind" die im Maschinenprogramm?

Da hängt von der CPU ab. Wie das bei Intelprozessoren ausschaut, weiß ich nicht. Bei Motorola war es so, daß einige Bits des Opcodes immer die Nummer des Registers enthalten. Wie genau das funktionierte, weiß ich nicht mehr. Ich habe schon seit 20 Jahren keinen Motorolacode mehr gesehen.

Das meine ich nicht. Wie Befehle kodiert sind ist mir selbst klar.

Vielleicht hilft ein Beispiel:
(Da wir beide nicht auswendig wissen wie das in Maschinencode aussieht schreib' ich es in Assembler auf. Es geht mir allerdings um die Maschinencode Representation.)

xor eax, eax
mov DWORD PTR[1234h], eax

Was tut dieser Code nun und mit welchen Variablen?
Mögliche Antworten:

Er setzt eine DWORD Variable auf 0
Er setzt zwei WORD Variablen auf 0
Er setzt view BYTE Variablen auf 0
Er macht v &= 0xFFFFFFFF mit einer QWORD Variable
Er macht v &= 0xFFFFFFFF00000000 mit einer QWORD Variable
Er setzt 32 Bit Variablen auf 0
Er setzt 4 Einträge in einer BYTE-Array Variable auf 0
...

Wenn man behauptet die Variablen sind "in" dem Programm (im Gegensatz zu: man kann sie hineininterpretieren), dann darf es nur eine klare Antwort geben. Die kann es aber erst geben, wenn 100% eindeutige, klare Regeln existieren.

Natürlich kann man sich jetzt, anhand irgendeiner Argumentation was die "natürlichste" Interpretation sei und warum, solche Regeln zurechtlegen. z.B. dass der Arbeitsspeicher immer als eine einzige grosse Byte-Array Variable angesehen wird, und die CPU Register als Variablen mit Registerbreite (also DWORD bei i386, 68K etc.). Dann könnte man behaupte dass diese Variablen "in" dem Programm sind.

Nur das ist meiner Meinung nach Unsinn.

1. weil es mMn. keinen Sinn macht davon zu sprechen dass ein Programm 4 Einträge in einem Byte-Array modifiziert, wenn es "in Wirklichkeit" einen Pointer auf NULL setzt.

2. weil wir schon bevor wir das Programm betrachten wissen welche Variablen es gibt, nämlich das eine BYTE Array und je eine für jedes Register. Und wie kann etwas "in" dem Programm sein, wenn seine Existenz und Beschaffenheit in keiner Weise vom Programm abhängig ist?

3. weil wir für diese "speziellen Variablen" bereits gute Fachbegriffe haben. Nämlich Arbeitsspeicher und Register. Wieso sollten wir sie dann sinnloserweise als "Variablen" bezeichnen? Nur um Verwirrung zu stiften?

mgaeckler

hustbaer schrieb:

mgaeckler schrieb:

hustbaer schrieb:

Nur... wo "sind" die im Maschinenprogramm?

Da hängt von der CPU ab. Wie das bei Intelprozessoren ausschaut, weiß ich nicht. Bei Motorola war es so, daß einige Bits des Opcodes immer die Nummer des Registers enthalten. Wie genau das funktionierte, weiß ich nicht mehr. Ich habe schon seit 20 Jahren keinen Motorolacode mehr gesehen.

Das meine ich nicht. Wie Befehle kodiert sind ist mir selbst klar.

Vielleicht hilft ein Beispiel:
(Da wir beide nicht auswendig wissen wie das in Maschinencode aussieht schreib' ich es in Assembler auf. Es geht mir allerdings um die Maschinencode Representation.)
xor eax, eax
mov DWORD PTR[1234h], eax
Was tut dieser Code nun und mit welchen Variablen?
Mögliche Antworten:

Er setzt eine DWORD Variable auf 0

Er setzt zwei WORD Variablen auf 0

Er setzt view BYTE Variablen auf 0

Er macht v &= 0xFFFFFFFF mit einer QWORD Variable

Er macht v &= 0xFFFFFFFF00000000 mit einer QWORD Variable

Er setzt 32 Bit Variablen auf 0

Er setzt 4 Einträge in einer BYTE-Array Variable auf 0
...

Es gibt nur eine Antwort:
Der erste Befehl setzt eine 32-Bit-Variable EAX auf den Wert 0.
Der zweite Befehl setzt eine 32-Bit Variable an der Adresse 1234 auf den Wert der Variable EAX.
Hinweis: ich bin kein Intelassemblerprogrammierer und weiß davon nur, was notwendig ist, um gelegentlich mal mit dem Debugger da rein zu schauen. Im Gegensatz zum 6502 oder MC68000 habe ich Intelprozessoren nie in Assembler oder gar Maschinencode programmiert. Sollten meine Antwortvorschläge daher etwaiige Ungenauigkeiten enthalten, bitte ich darüber hinweg zu sehen.

Die semantische Bedeutung der Variablen lässt sich daraus natürlich nicht entnehmen. Das kann man in Hochsprachen aber auch nur, wenn der Programmierer sich ordentliche Namen für die Variablen ausgedacht hat.

hustbaer schrieb:

3. weil wir für diese "speziellen Variablen" bereits gute Fachbegriffe haben. Nämlich Arbeitsspeicher und Register. Wieso sollten wir sie dann sinnloserweise als "Variablen" bezeichnen? Nur um Verwirrung zu stiften?

Darüber sind wir uns glaube ich auch schon einig, daß die Begriffe Speicheradresse und Register besser geeignet sind.

mfg Martin