Diskussion:Maschinensprache/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Maschinensprache/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Maschinensprache/Archiv/1#Thema_1

Erste Sektion überarbeitet

Wie schon früher festgestellt wurde, hatte der erste Teil eine starke Überscheidung mit Befehlssatz, das ist damit korrigiert, ich werde versuchen, die entsprechenden Teile in den Artikel Befehlssatz einzuarbeiten.

Was bleibt ist die schon früher und auch hier ganz oben festgestellte thematische Überscheidung mit Assembersprache, die in der zweiten Sektion noch vorhanden ist und sich noch korrigieren lassen sollte.--84.148.56.122 14:51, 12. Feb 2006 (CET)

?

Ein Programm muss einem Befehlssatz vorliegen, der vom Prozessor unterstützt wird, damit es von ihm direkt komplett ausgeführt werden kann.

Diesen Satz verstehe ich nicht, hab' ihn deshalb entfernt--Staro1 04:15, 28. Mär 2006 (CEST)

Ach ja?

"Wird von der Programmierung in Maschinensprache gesprochen, wird heute üblicherweise die Maschinenprogrammierung in Assemblersprache unter Verwendung eines Assemblers gemeint, der das als Textdatei vorliegende Assemblerprogramm in binäre Maschinenbefehle übersetzt."

Bitte mit Quellen belegen, das halte ich doch fuer sehr fraglich. Sagt man nicht eher, dass man in "Assembler" programmiert, wenn man in der Assemblersprache programmiert?84.59.222.42 18:20, 8. Apr. 2008 (CEST)

Lochkarten

Mir fehlt der Bezug zu Lochkarte. Waren nicht Lochkarten die erste Möglichkeit Programme zu speichern, bzw. von Hand zu erstellen? Da wurde doch auch Maschinensprache als Binärkode in die Karten gelocht. --Suricata 21:44, 2. Okt. 2009 (CEST)

Das ist nicht eine Frage der Sprache, sondern der Darstellung. Ich denke nicht, dass wir hier über Lochkarten reden müssen. Wir haben damals übrigens keinen Binärcode in die Karten gelocht, sondern auch eine textliche Darstellung von Maschinensprache, siehe Assembler (Informatik). Ganz zu Anfang hat man Maschinencode tatsächlich wirklich binär über Steuertafeln mit Schaltern direkt in die Maschine geladen; im Artikel PDP-1 siehst du eine entsprechende Abbildung. --Herbert Klaeren 10:06, 3. Okt. 2009 (CEST)

Wie locht man eine textliche Darstellung in die Karten? Wurde da ld a,0 etc als ASCII in die Karten gelocht und nicht der zugehörige Maschinencode? --Suricata 14:06, 3. Okt. 2009 (CEST)

Genau! Allerdings lochte man Karten nicht in ASCII, sondern eher in EBCDIC (sprich: "ebbsidick"). Dabei entstehen in jeder Lochkartenspalte höchstens zwei Lochungen, für anderes waren die Kartenlocher auch gar nicht vorgerüstet. Auf Wunsch hat einem der Assembler dann den erzeugten Objektcode wirklich binär in Karten gelocht; diese Karten hatten dann in der Regel mehr als zwei Lochungen pro Spalte. Wenn man solche Binärkarten dann in einem Lochkartenlocher duplizieren wollte, konnte es zu Verklemmungen im Stanzmechanismus kommen, schlimmstenfalls wurde das Gerät beschädigt. Um Verwechslungen auszuschliessen, haben die meisten Rechenzentren Binärkarten verwendet, die sich durch die Färbung von den handgelochten EBCDIC-Karten unterschieden. Gruss --Herbert Klaeren 19:00, 3. Okt. 2009 (CEST)

Danke! --Suricata 20:32, 3. Okt. 2009 (CEST)

Sprungadressen

Es ist nicht richtig, dass in Maschinensprache und/oder Assembler nur absolute Sprungadressen verwendet werden können. Der Z80-Prozessor beispielsweise bietet auch relative Sprünge an, also z.B. 20 Bytes nach vorne.

Ich nehme an, der Autor meinte, dass in Assembler symbolische Sprungadressen über Labels angegeben werden können. Falls keiner widerspricht werde ich das demnächst ändern. --85.70.197.210 22:18, 10. Jun. 2010 (CEST)

ja natürlich, das muss es sein, was der Autor gemeint hat. Praktisch jeder Prozessor hat Instruktionen für relative Sprünge. Ändere es ruhig. --Herbert Klaeren 22:56, 10. Jun. 2010 (CEST)

Vieles falsch

Auch das ist in weiten Teilen falsch. Informieren Sie sich bevor Sie Artikel publizieren! (nicht signierter Beitrag von 195.170.70.68 (Diskussion | Beiträge) 21:29, 13. Dez. 2002 (CET))

Stellen Sie bitte eine Kopie der Ihrer Ansicht nach falschen Teile des Artikels hierhin und geben an, was daran falsch ist! Sonst outen Sie sich nur als unproduktiver Nörgler. (nicht signierter Beitrag von 195.186.164.249 (Diskussion | Beiträge) 16:30, 14. Dez. 2002 (CET))

Assemblersprache

Dieser Artikel ist ziemlich ähnlich zu Assemblersprache. Sie sollten aufeinadner abgestimmt werden. (nicht signierter Beitrag von 129.132.73.142 (Diskussion | Beiträge) 15:57, 18. Jan. 2003 (CET))

Erste Korrekturen

Wie hier schon angedeutet, sind bestimmte Teile dieses Artikels falsch. Dieser Kommentar beschreibt und begründet eine erste Korrektur. Aus dem 1. Absatz:

Von Maschinensprache spricht man eher dann, wenn man ein konkretes, in Maschinensprache vorliegendes Programm analysiert oder wenn man den Befehlssatz (etwa vergleichend) auf seine sprachlichen Eigenschaften hin analysiert.

Der erste Teil ist richtig, jedoch der zweite falsch. Er fällt sich schon selbst über die Füsse, indem er den Begriff Befehlssatz im Kontext verwendet. Schelmisch könnte darauf sagen: "Gerade wenn man den Befehlssatz (etwa vergleichend) auf seine sprachlichen Eigenschaften hin analysiert, verwendet man Befehlssatz" :) Im Kontext der sprachlichen Eigenschaften wird der Begriff Maschinencode eher benutzt um z.B. über die Lesbarkeit zu sprechen: "Kannst du diesen Maschinencode lesen?" Dies ist jedoch schon im ersten Teil, bei der Analyse eines vorliegenden Programms gemeint. Ich habe, da es hier auch um Maschinencode, geht, den ersten Teil so fortgesetzt:

Von Maschinensprache spricht man eher dann, wenn man ein konkretes, in Maschinensprache vorliegendes Programm analysiert, also sich auf die Anwendung des Befehlssatzes konzentriert.

2.Absatz:

Da sich der Befehlssatz von Rechner mit unterschiedlichen Prozessoren im allgemeinen unterscheidet, sind in Maschinensprache geschriebene Programme nur sehr schwer übertragbar. Jede Prozessorarchitektur hat eine eigene, unterschiedliche Maschinensprache. Die direkte Programmierung in einer Maschinensprache wird heute kaum noch verwendet. Einige Programmiersysteme für höhere Programmiersprachen gestatten es, Maschinenbefehle in den Quelltext zu integrieren. Die Anwendung beschränkt sich dann auf solche Fälle, in denen es aus Effektivitätsgründen unumgänglich ist, maschinennah zu programmieren, wie etwa bei Hardware-Treibern.

Der erste Satz ist nur schwer verständlich und so wie er dort steht Nonsens. Der erste Teil verallgemeinert auch zu stark, Beispiel, auf diese Logik angewant: "Da sich der Befehlssatz von Rechnern mit unterschiedlichen Prozessoren (Beispiele: Pentium, Pemtium M, Mobile Pentium, Celeron, Athlon, Athlon64, Xeon, Opteron, ..) unterscheidet, sind in Maschinensprache geschriebene Programme (z.B. Viren, Würmer) jeweils nur sehr schwer übertragbar und können deswegen nur sehr schwer von einem System aufs andere Übertragen werden." Viren und Würmer (n ur als Beispiel) verbreiten sich gerade deswegen so gut, weil diese Prozessoren, die alle eine gemeinen Befehlssatz unterstützen, in weiten Teilen zueinander kompatibel sind und sich deswegen greade auch in Maschinensprache geschriebene Programme zwischen ihnen übertragen lassen.

Der Unsinn geht im 2. Satz weiter. Man könnte genauso sagen: "Jede Menschenrasse hat eine anderen, unterschiedlichen Slang". Hier wird der Begriff Maschinensprache auf einer Ebene benutzt, wo eigentlich Befehlsatz verwendet werden müsste, und es wird der Begriff Prozessorarchtektur auf dieser Ebene verwendet, er passt jedoch eher auf die Ebene von RISC und CISC, was viel besser weiter unten behandelt wird. Eher würde in diesem Kontext der Begriff Rechnerarchitektur passen, hier müsste jedoch etwas mehr erklärt werden, da viele Rechnerarchitekturen die Befehlssätze älterer Prozessoren/Architekturen aus Kompatiblität unterstützen.

Der nächste Satz verallgemeinert ebenfalls zu sehr, der dritte spricht von der Integration vn Maschinenbefehlen, wo es beser Assemblerbefehle heissen sollte und man sollte hier spezifischer von den Compilern und nicht von "Programmiersystemen" sprechen. Zum letzten Satz: Gerade bei Hardare-Treibern ist es nicht zwingend notwendig, direkt Assemberinstruktionen direkt in den Quelltest zu integireren. Ein Beispiel dafür sind die Open Source-Treiber im Linux-Kern, die, wenn sie korrekt implementiert sind, auf allen Architekturen verwendet werden können, auf der die entsprechende Hardware zur Verfügung steht. Ein konkretes Beispiel dafür sind die Treiber für PCI-Karten (z.B. Netzwerkkarten) die auf PowerPCs und auf Intel-PCs eingesetzt werden können. Ich habe diesen Absatz daher wie folgt überarbeitet:

Da der Befehlssatz dem für Programme verfügbaren Funktionsumfang eines Prozessors bestimmt, unterscheideen sich die Befehlssätze von von unterschiedlichen Prozessoren sehr oft. Damit in Maschinensprache vorliegende Programme auf neueren Prozessoren weiterververwendet werden können, unterstützen die meisten Prozessoren jedoch den Befehlssatz von einer Rechnerarchitekturen. Jede Rechnerarchitektur hat eine eigene, unterschiedliche Maschinensprache, wobei viele Rechnerarchitekturen Kompatibilität zu anderen Rechnerarchitekturen beinhalten. Einige Compiler höherer Programmiersprachen gestatten die Integration von Assemblerbefehlen in das in Hochsprache geschriebene Programm um. Dies bringt mit sich dass:

• Bestimmte, von Compilern meist nicht verwendete Befehle verwendet werden können, z.B. Behehle der Instruktionserweiterungen MMX, SEE, SSE2, 3DNow!
• Die so implementiere Funktion nur auf System ausgeführt werden kann, die verwendeten Instruktionen unterstützen (nicht signierter Beitrag von 84.148.56.122 (Diskussion | Beiträge) 14:24, 12. Feb. 2006 (CET))

Sektion hierher verschoben

Ich habe diese Sektion hierher verschoben:

Unterschiede zu den Hochsprachen

• Maschinensprachen bieten nur sehr einfache Befehle.
• Ein Programm kann nur auf genau dem Prozessor ablaufen, für dessen Maschinensprache es programmiert wurde. Diese Einschränkung ist weniger schwerwiegend als es zunächst scheint. 24-Bit-Code, der 1964 für ein IBM S/360 geschrieben wurde, läuft noch heute auf zSeries-Rechnern mit 64-Bit Architektur. 16-Bit-Code, der für den mittlerweile 25 Jahre alten 8086-Prozessor programmiert wurde oder 32-Bit-Code, der für 80386 programmiert wurde, ist auf heutigen Pentium-Rechnern lauffähig. Da die Intel-Mikroprozessor-Architektur einen sehr großen Marktanteil hat (auch andere Firmen wie AMD benutzen sie), und die IBM-Architektur den Mainframebereich dominiert, sind Maschinenspracheprogramme, die für diese Prozessoren geschrieben worden sind, sehr langlebig.
  • Anmerkung: die Möglichkeit des Ausführens von Maschinensprache auf einer späteren CPU-Generation wird als Abwärtskompatibilität bezeichnet. Hierfür ist nicht der Verbreitungsgrad einer Architektur, sondern der Entwurf nachfolgender CPU-Generationen ausschlaggebend. Erreicht wird diese Abwärtskompatibilität, indem man entweder

den Vorläufer-Prozessor in der neuen Prozessorarchitektur integriert und mit einem Befehl umschaltbar macht, oder

einen Emulator als Microcode in den neuen Prozessor einbaut.

• Für die Ausführung von Maschinencode auf systemfremden (also ungeeigneten) Prozessoren existieren Emulatoren. Die Ausführung erfolgt interpretativ oder partiell kompilierend, mit grob 10facher Zeitdehnung.

Begründung des Verschiebens: Ein Hinweis auf den Gegensatz zwischen Maschinensprache und Hochsprachen befindet sich schon in der ersten Sektion. Auf den in Maschinensprachen zur Verfügung stehenden Befehlssatz wird in Befehlssatz bereits eingegangen. Der Rest ist praktisch ein Diskussionsthread auf der auf einen sehr kontroversen Satz hin folgt. Insofern passt die Besser auf eine Diskussionseite als in eine Enzykopädie. (nicht signierter Beitrag von 84.148.56.122 (Diskussion | Beiträge) 16:15, 12. Feb. 2006 (CET))

Setzt sehr viel Wissen voraus

Gerade der Absatz über den Befehlssatz setzt sehr viel Wissen voraus und ist für einen Laien extrem schwer lesbar. Fachbegriffe (z.B. Register, Flag) sind oft nicht verlinkt. Ein bisschen mehr Erklärung wäre schön. --88.65.88.143 23:01, 1. Aug. 2011 (CEST)

Habe versucht, hauptsächlich den ersten Absatz in diesem Abschnitt etwas verständlicher zu formulieren. Die jetzt veränderte Kapitelfolge könnte das Verständnis ebenfalls fördern. --VÖRBY 12:54, 3. Aug. 2011 (CEST)

Weblinks

Bis eben linkte der Artikel auf http://www.pst.ifi.lmu.de/~hackling/iMachine/ - sicher, die verlinkte seite hat irgendwas mit maschinencode zu tun, versaeumt es allerdings die imaginaere maschine naeher zu spezifizieren. falls eine turingmaschine gemeint ist sollte es dort auch vermerkt sein - bis dahin sollte der link draussen bleiben. (nicht signierter Beitrag von 78.49.13.193 (Diskussion | Beiträge) 20:46, 17. Dez. 2007 (CET))

Der Weblink zur X86-Architektur war entfernt worden, heute wurde das revertiert. Ich halte die Löschung für ok, denn es geht HIER nicht um eine bestimmte Maschinensprache, sondern um Sprachen im Allgemeinen. Weblinks sollten möglichst exakt zum Lemma passen, was hier nicht der Fall ist - unabhängig davon, ob X86 tatsächlich noch weit verbreitet ist oder nicht. Außerdem: Dieser Link ist bei X86-Prozessor bereits gesetzt, wo er richtig positioniert ist und was m.E. auch genügt. Vorschlag: Link hier wieder löschen. Allerdings sollte dann der Artikel zu X86 hier deutlich verlinkt sein. Wäre das ein Kompromiss? --VÖRBY (Diskussion) 18:03, 13. Jun. 2012 (CEST)

Zusätzliche Begründung für die (zwischenzeitlich bereits stattgefundene) 2. Löschung: Wikipedia:Weblinks schreibt: Generell gilt: Die dort verlinkten Seiten müssen das genaue Artikelthema behandeln (nicht nur verwandte Themen) ....
Siehe jedoch auch den neuen Diskussionabschnitt 'Sprachvarianten'.
--VÖRBY (Diskussion) 11:20, 14. Jun. 2012 (CEST)

Ich hab mir gestern noch die Mühe gemacht und das Zeug in dem Link mal durchgelesen - untragbar, sorry.

Außerdem steht unter WP:WEB klar (zusätzlich zu VÖRBYs Ausführung):

• "wähle das Beste und Sachbezogenste aus, was im Netz zu finden ist": das ist wohl kaum gegeben.
• "Artikel in einer Enzyklopädie müssen für sich selbst sprechen und keine externen Erklärungen benötigen": Was soll also diese "Begründung" die "Weblinks seien (oft) das beste am Artikel"?

Für mich ist nach wie vor klar, dass die entsprechenden Seiten sich nicht für eine Verlinkung aus der WP qualifizieren.

-- Plankton314 (Diskussion) 11:59, 14. Jun. 2012 (CEST)

Direkte Eingabe der Binärcodes über eine Reihe von Schaltern …

seit den 1970er Jahren völlig außer Gebrauch gekommen? Das ist so nicht richtig. Zwar wurde davon, soweit stimmt meine Schätzung überein, seit den 70er-Jahren immer mehr Abstand genommen. Aber das „völlig außer Gebrauch“ ist definitiv falsch. Noch Mitte bis Ende der 80er-Jahre hatte ich mit Rechnern zu tun, die diskret aufgebaut waren und (evtl. sogar deshalb) u.a. mittels Punktmatrix-LED interne Register im laufenden Betrieb darstellen („wer ein schnelles Auge hat …“) konnten und mittels mehrer Tastenfelder bis ins letzte Detail beeinflußt werden konnten. Zwar war dies nicht die übliche Arbeitsweise. Aber zumindest für die Inbetriebnahme solcher Systeme (auch nach einem SW-Upgrade) war dieser Zugang damals, wenn auch kurz, noch zwingend nötig. Dies änderte sich erst, als auch der zentrale Rechnerkern immer mehr aus hochintegrierten Schaltungen, v.a. Mikroprozessoren, aufgebaut wurde – wahrscheinlich wurden einem solchen dabei (vorerst) die Aufgaben des alten Bedienpanels als eine Abart einer Terminal-Emulation übertragen. Mir fehlt allerdings eine breitere Kenntnis dieser Thematik, so daß ich aus „seit den 1970er Jahren“ bestenfalls und möglicherweie ebenso fehlerhaft ein „bis Anfang der 1990er Jahre“ machen könnte. --87.163.79.172 (nicht mit einer Zeitangabe versehener Beitrag von 78.49.13.193 (Diskussion | Beiträge) 03:18, 24. Dez. 2007 (CET))

ich finde dass die maschinensprache ein sehr wichtiger faktor unserer modernen zeitepoche ist. (nicht signierter Beitrag von 84.190.70.19 (Diskussion | Beiträge) 10:57, 11. Jan. 2012 (CET))

Ich bin mir nicht sicher, wie Deine Anmerkung gemeint ist: So wie sie sich liest oder als zynische Bemerkung. Man sollte aber zwei Dinge unterscheiden: a) Die Maschinensprache als Code, der von den Prozessoren ausgeführt wird; so interpretiert ist MS nach wie vor aktuell. b) Das Programmieren in Maschinensprache dürfte tatsächlich 'in unserer modernen Zeitepoche' nahezu ausgestorben sein. Grüße von --VÖRBY 12:47, 11. Jan. 2012 (CET)

Sprachvarianten

Die obige Diskussion über Weblinks (X86) führte bei mir zur Frage, welche Maschinensprachen es überhaupt gibt. Stichworte hierzu: (ggf. hier ergänzen).

• Welche gibt es? Sprachfamilien, Varianten/Dialekte; Entwicklungslinien (Vorgänger/Nachfolger, Schema ähnlich [1], ursprünglich bei Programmiersprache); Zusammenhang zu Rechnerarchitekturen; ...
• weitere Eigenschaften wie Adressierungsbreite; im Einsatz seit; noch im Einsatz? 'Hersteller' ...

Hierzu würde ich mir Aussagen im Artikel wünschen, ähnlich wie das auch bei Sprache und gesprochene Sprache der Fall ist. Bin selbst hierzu leider kein Spezialist. Gibt es Freiwillige?--
VÖRBY (Diskussion) 08:39, 14. Jun. 2012 (CEST)
ergänzt und umformuliert: --VÖRBY (Diskussion) 20:27, 14. Jun. 2012 (CEST)
ergänzt: --VÖRBY (Diskussion) 12:30, 16. Jun. 2012 (CEST)

Texte aufgeräumt

Fortsetzung der Diskussion im nächsten Abschnitt 'Daten als Teil des Maschinencodes'

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 10:51, 7. Nov. 2012 (CET)

Hallo 0x, deine Aufräumaktion halte ich i.W. für sinnvoll. Die von dir entfernte Aussage

Der Prozessor führt nicht nur Anwendersoftware über Maschinencode aus, sondern (ggf. in mehreren Softwareebenen) alle Programme, auch Systemprogramme. Selbst das Betriebssystem wird vom Prozessor – wie jeder andere Code – als Maschinencode abgearbeitet.

halte ich aber für nicht unwesentlich. Alternativ zur Einleitung (wo der Text bisher stand) könnte man sie bei am Ende von #Programmerstellung einschieben - um klarzumachen, dass nicht nur - per SW-Entwicklung - erstellte Programme zu M-Code werden und so ausgeführt werden, sondern ALLES was der Rechner tut. Gerne kann man auch hier umtexten.--VÖRBY (Diskussion) 10:52, 4. Okt. 2012 (CEST)

Hallo Vörby, ich versteh irgendwie immer noch nicht d(e)i(n)e Motivation bei dem Satz. Software wird in Maschinensprache von der Maschine ausgeführt – und die Software ist natürlich „per SW-Entwicklung“ entstanden, was ist jetzt wesentlich daran, ob es sich um Anwendersoftware handelt? Eine Abgrenzung des Betriebssystems von anderer Software gibt es nicht einmal bei allen Rechnern… --Chricho ¹ ² ³ 11:22, 4. Okt. 2012 (CEST)

Ich denke aber, das ist aber nicht jedem Laien so bewusst. Schließlich ist ja bsd. das Betriebssystem praktisch nirgends wirklich sichtbar. Das ordnet niemand unter 'Programmerstellung' ein, deshalb kann der Satz nützlich sein.--VÖRBY (Diskussion) 11:39, 4. Okt. 2012 (CEST)

Das Problem ist, dass der Satz eine falsche Unterscheidung impliziert. Außerdem ist es deine persönliche Ansicht, Laien würden sich um einen angeblichen Unterschied Betriebssysteme/Anwendungssoftware scheren oder das sogar gar nicht erst als Softwareentwicklung einordnen. Kann ich nicht nachvollziehen. Vor allem wichtig ist aber meine erste Aussage: Der Satz impliziert eine Unterscheidung. ʘχ (Diskussion) 14:14, 4. Okt. 2012 (CEST)

Was ist denn daran so falsch, dem Leser explizit nochmal zu erläutern, dass nicht nur das, was er vielleicht üblicherweise unter Software versteht, über MCode ausgeführt wird? Schließlich könnte der die Begriffe Programm, Programmierer, Programmerstellung, Übersetzer etc. mit einem anderen Vorstellung von 'Software' assoziieren.

Wenn du nur relevante 'Unterscheidungen' zeigen möchtest, dann dürfte im Artikel auch nichts von Java, Bytecode, Interpreter oder JIT-Compiler stehen; das alles ist irrelevant, weil in allen Fällen nur Maschinenbefehle ausgeführt werden.

Aber IHR wisst ja, was Leser wissen und was sie nicht wissen. Ich bin es leid, mit euch weiter Erbsen zu zählen. Macht also was ihr wollt! --VÖRBY (Diskussion) 16:42, 4. Okt. 2012 (CEST)

Außerdem ist die Darstellung 'Quellcode > Compiler > Maschinencode > Ausführung' unzulässig vereinfachend, weil sie suggeriert, der erzeugte Maschinencode würde zur Ausführung genügen. In Wahrheit verzweigt jeder Lesebefehl, jede Tastatureingabe, jede Timerabfrage ... in ein weit verzweigtes hierarchisches System von Systemfunktionen inkl. Betriebssystem. Dies könnte mit meiner Aussage ebenfalls klargestellt werden; wie gesagt, ggf. modifiziert. --VÖRBY (Diskussion) 18:36, 4. Okt. 2012 (CEST)

Ok, jetzt kann ich es besser nachvollziehen, in der jetzigen Fassung steht in der Tat nichts davon, dass sämtliche Ausführungen mit der Ausführung von Maschinencode verbunden sind, das sollte man hervorheben. Abgrenzung von sonstigen Einflüssen auf den Prozessor – möglich zu erwähnen, allerdings hab ich gerade keine Idee, wie. Grüße --Chricho ¹ ² ³ 19:18, 4. Okt. 2012 (CEST)

Hier wird dem Leser jegliche Denkfähigkeit abgesprochen. Aber bitte, meinetwegen. Ich habe eine Formulierung angepasst.

Außerdem ist die Darstellung 'Quellcode > Compiler > Maschinencode > Ausführung' unzulässig vereinfachend, weil sie suggeriert, der erzeugte Maschinencode würde zur Ausführung genügen. Nein, das ist nicht unzulässig vereinfachend, sondern eine der wenigen Gewissheiten in diesem Universum. Gibt man der CPU ein Maschinenprogramm, das von einem Compiler erzeugt wurde, dann führt sie das aus, ohne Wenn und Aber, da lässt die nicht mit sich verhandeln. Falls es fehlerhaft sein sollte, dann wird sie eine entsprechende Exception werfen. Aber sie wird keine Bedingungen stellen, etwa ein "weit verzweigtes System von Systemfunktionen". ʘχ (Diskussion) 23:27, 4. Okt. 2012 (CEST)

Versuch es mal, der CPU 'ein Maschinenprogramm zu geben'. Schon zum Laden dieses Programms braucht es X andere 'Maschinenprogramme' (des Betriebssystems etc. - die viele Benutzer/WP-Leser so nicht sehen und die (aus ihrer Sicht) nicht "von einem Programmierer erstellt " und nicht "von einem Compiler erzeugt" wurden. Ist das nicht richtig? Ist es nicht wichtig? Weiß das jeder Wikipedia-Leser? --VÖRBY (Diskussion) 09:33, 5. Okt. 2012 (CEST)

die (aus ihrer Sicht) nicht "von einem Programmierer erstellt " und nicht "von einem Compiler erzeugt" wurden Wie kommst du bloß darauf? Das ist einfach eine Behauptung von dir, eine rein persönliche Ansicht.

Schon zum Laden dieses Programms braucht es X andere 'Maschinenprogramme' (des Betriebssystems etc. Erstens hat das nichts mit Maschinensprache zu tun, und zweitens hängt das von der Domäne ab, ob es überhaupt ein Betriebssystem gibt etc etc etc. ʘχ (Diskussion) 11:18, 5. Okt. 2012 (CEST)

Nun schau mal, wie oft 'Programmier' oder 'Compil' im Artikel vorkommt; das suggeriert einfach klassische Software - oder kann es tun. 'Computer ohne Betriebssystem' - was soll denn das sein? Mir reichts mal wieder! --VÖRBY (Diskussion) 19:29, 5. Okt. 2012 (CEST)

Ähm, auch tiefste Komponenten eines Betriebssystems werden von Programmierern programmiert? Und meist ist dabei auch ein Compiler im Spiel? --Chricho ¹ ² ³ 23:38, 5. Okt. 2012 (CEST)

Lasst uns nochmal zurückgehen zu Chrichos Beitrag vom 4. Okt. 2012, 19:18. Da ward Ihr doch schon ganz nahe beieinander: „... dass sämtliche Ausführungen mit der Ausführung von Maschinencode verbunden sind, das sollte man hervorheben.“ Okay, das lässt sich doch einfach einfügen, ich werde das gleich mal tun. Sonstige Einflüsse auf den Prozessor – hier fallen mir auf Anhieb Interrupts ein; was sollte man noch erwähnen? Gruß aus dem Neckarland, --Mussklprozz (Diskussion) 09:17, 6. Okt. 2012 (CEST)

Gute Korrekturen. Noch eins: Ein Computeranwender, der einfach nur erworbene Software benutzt, erkennt in der Auflistung und im Text unter 'Programmerstellung' seine Situation/Perspektive nicht. Ihm könnte der explizite Hinweis auf diese Art der SW-Nutzung klar machen, dass dabei Maschinencode in gleicher Weise eine Rolle spielt - und das sogar beim Betriebssyxstem so ist. --VÖRBY (Diskussion) 17:39, 13. Okt. 2012 (CEST)

Noch was: Nach der kürzlich vorgenommenen Änderung der Definition (in der Einleitung; "ist der Befehlssatz eines Prozessors") ist die Definition unpräzise:

• 'Befehlssatz eines Prozessors' und 'Maschinencode' sind semantisch nicht dasselbe, vergleichbar mit 'Sprachvermögen eines Lesers' mit 'Buchtext'.
• 'Befehlssatz' (und die dazu ergänzte Erläuterung) lassen vermuten, dass es nur um Befehle geht. Im Maschinencode sind aber auch Daten enthalten - z.B. definierte Konstanten.
• Auch en:Machine code definiert das so: ... a system of impartible instructions executed directly by a computer's central processing unit (CPU).
• Darüber hinaus enthält der Maschinencode weitere interne Formatinformationen. Beispiel: Beim Laden des Programms wird erkannt, ob eine Konstante eine Adresskonstante ist - die dann (anders als bei anderen Konstantenarten) vom Betriebssystem relativ zur Ladeadresse des Programms inhaltlich angepasst wird.

Mein Vorschlag wäre also: Als Maschinensprache (auch Maschinencode oder nativer Code genannt) bezeichnet man das Format eines Computerprogramms, das vom Prozessor des Computers direkt ausgeführt werden kann.
Da nur im Abschnitt 'Unterschied zu Assembler' erläutert wird, dass der Maschinencode auch aus Daten besteht, schlage ich vor, den ersten Satz aus diesem Abschnitt, ggf. angepasst, auch in die Einleitung zu verschieben.
Noch besser wäre eine offiziell belegte Definition.--VÖRBY (Diskussion) 13:10, 14. Okt. 2012 (CEST)

Das ist völlig am Thema vorbei. Es geht hier um die Maschinensprache und nicht um Formate für ausführbare Dateien, Objektdateien oder ähnliches. --Chricho ¹ ² ³ 15:23, 14. Okt. 2012 (CEST)

Du beziehst dich wohl auf den Vorschlag zum Definitionstext. Wenn dir 'Format' nicht gefällt, dann nenne es 'Struktur', die englische Definition nennt es 'system' (of instructions). Neuer Vorschlag: Als Maschinensprache (auch Maschinencode oder nativer Code genannt) bezeichnet man den Programmcode, den der Prozessor des Computers direkt ausführen kann. Dass darin auch Daten (-bereiche) enthalten sind, halte ich nach wie vor für wichtig und erwähnenswert. Die Alternativen wären: 'Offiziell belegter Text' oder 'Übersetzen des englischen Textes'.--VÖRBY (Diskussion) 17:55, 14. Okt. 2012 (CEST)

Die Übersicht bei Programmcode war falsch, ich habe sie eben korrigiert. Die Begriffe Maschinencode und Maschinensprache werden oft synonym gebraucht (was den in der sonstigen Informatik üblichen Bedeutungen der Begriffe "Programmiersprache" und "Programmcode" widerspricht). Das heißt insbesondere, dass "Programmcode" etwas gänzlich anderes ist als "Maschinencode": Maschinencode ist eine Sprache, Programmcode hingegen der Text eines Programms. Man kann Maschinensprache also nicht als einen Programmcode definieren. Wenn man Maschinensprache anhand des Begriffs Programmcode definieren wollte, müsste man korrekterweise sagen, Maschinensprache sei die Menge aller "CPU-Programmcodes", jedoch ist dies für den Laien unverständlich. ʘχ (Diskussion) 19:46, 14. Okt. 2012 (CEST)

Warum soll 'Maschinencode' etwas 'ganz anderes' sein, nämlich eine 'Sprache'? Wo steht das? Diese Quelle sollte m.E. bei der neuen Version von Programmcode noch nachgetragen werden.

Aus meiner Sicht ist 'Programmcode' ein neutraler Überbegriff für alle im SWE-Fortschritt entstehenden Code-Artefakte. Quelltext (oder Quellpgm oder Quellcode) wäre die erste (früheste) Stufe, Maschinencode (oder Maschinenprogramm oder Binärcode) die letzte (die die CPU ausführen kann). Wenn Maschinencode und Maschinensprache als Synonyme gelten (was ja in der Def so steht), ändert das daran nichts. --VÖRBY (Diskussion) 20:18, 14. Okt. 2012 (CEST)

Ich bezog mich nicht nur auf das Wort Format. Irgendwelche Datenbereiche und Loaderinformationen sind nicht Teil der Maschinensprache, sondern des Formats von ausführbaren Dateien. --Chricho ¹ ² ³ 19:55, 14. Okt. 2012 (CEST)

... diese Datenbereiche ... sind aber Teil des Maschinencodes - und der gilt als Synonym für Maschinensprache. Wir haben es hier u.a. auch mit diesem Problem zu tun, ob das Synonym ist oder nicht. --VÖRBY (Diskussion) 20:18, 14. Okt. 2012 (CEST)

1. Wenn Maschinencode und Maschinensprache als Synonyme gelten (was ja in der Def so steht), ändert das daran nichts. Doch, das führt zu einem Unterschied, wie dargelegt: Denn Maschinencode ist dann eine Sprache und damit von Programmcode verschieden.
2. Was für "Datenbereiche" meinst du denn? Grundsätzlich enthält die Maschinensprache bzw. der Maschinencode keine "Datenbereiche", so wie ich diesen Begriff auffasse, denn das sind aus CPU-Sicht High-Level-Features, die erst auf Assembler-Ebene stattfinden.
3. Im Maschinencode sind aber auch Daten enthalten - z.B. definierte Konstanten. Daten sind aus CPU-Sicht Teil eines Befehls, es ist also kein besonderes Problem, dass in einem Maschinenprogramm auch Daten definiert werden. Von Befehlssatz zu sprechen ist also korrekt. Falls du mit Daten bloße Werte meinst, die irgendwo im Arbeitsspeicher liegen und nicht Teil eines CPU-Befehls sind, so können diese zwar in der Tat Teil eines Assemblerprogramms sein und auch Teil einer ausführbaren Datei, allerdings sind sie nicht Teil eines Maschinenprogramms (zumindest kenne ich keine CPU, die mit soetwas umgehen kann).
4. Die Sache mit den Synonymen haben wir leider nicht zu entscheiden, denn das wäre TF. Wir müssen leider damit leben, dass diese Begriffe oft synonym gebraucht werden, unabhängig davon, ob sie Synonyme sind oder nicht. ʘχ (Diskussion) 20:55, 14. Okt. 2012 (CEST)

Guten Morgen. Kurz zu deinen Punkten (die ich nachträglich nummeriert habe):

1. Du gewichtest den Begriff 'Sprache' eben höher; wenn das aber Synonyme sind, dann kann man ebenso sagen, das sei 'Code' und damit vergleichbar mit 'Quellcode' - und letztlich 'Programmcode'. Übrigens könnte man auch zu 'Code' zwei Bedeutungen unterstellen: Code als materieller Begriff (wie Datei ...) oder Code als ~logischer Begriff wie 'Sprache'. Aus diesem Grund halte ich die Synonym-Variante auch für 'akzeptabel'.

2. Wenn du Maschinencode im Hex-Editor oder im Dump ansiehst, erkennst du jede Menge an Dateninhalten. Damit sind diese unzweifelhaft Teil des Maschinencodes. Diese 'Bereiche' werden zwar nicht ausgeführt - das würde zu einem 'Adressierungsfehler' führen, aber sie werden über die Befehle adressiert und vom Rechenwerk angesprochen (gelesen und verändert). Ohne diese 'Daten' wären auch die Befehle nicht ausführbar.

3. Teil eines Befehls: I.d.R. werden die Daten im Befehl nur adressiert (Register, Distanz). Nur in wenigen Befehlen steht der 'immidiate-Wert' direkt im Befehl. In beiden Fällen sind sie Teil des Maschinencodes, nicht nur des Quellcodes. Es gilt sogar als Charaktermerkmal der 'Von-Neumann-Architektur', dass der Rechner Daten und Instruktionen grundsätzlich nicht unterscheidet. Natürlich muss die Pgm-Logik dafür sorgen, dass der Befehlszähler niemals auf solche 'Bytefolgen' zeigen darf.

4. Der springende Punkt unserer Diskussion ist aber nun mal, ob beide Ausdrücke Synonyme sind - oder nicht. Und es kommt darauf an, was HIER beschrieben werden soll; das ist mMn 'das, was der Prozessor ausführen kann'. Offensichtlich sieht das auch die englische Wikipedia so und hat auch nur einen Artikel - nur heißt der dort 'Machine code'. Wahrscheinlich müsste man diese Fragestellung in der Einleitung ausführlicher (als mit Klammerbegriffen) behandeln und erläutern.

--VÖRBY (Diskussion) 09:56, 15. Okt. 2012 (CEST), ergänzt: --VÖRBY (Diskussion) 16:58, 15. Okt. 2012 (CEST)

• Ich sehe hier keinen Sinn mehr. Ich werde daher nun ein letztes Mal darauf eingehen, und dann breche ich ab.
• Zu 1. Sind die üblichen Bedeutungen etwa völlig unverbindlich? Na ja, wenn wir noch ein wenig weiter frei assoziieren, kommen wir vielleicht noch zu ganz anderen Erkenntnissen über Sprache, Informatik und womöglich auch die menschliche Existenz, die sich in diesem Artikel gut machen würden.
• Zu 2. Das ist nicht "unzweifelhaft" Teil des Maschinencodes. Das ist, wie bereits von anderen (z.B. Chricho) angemerkt, spezifisch für bestimmte Dateiformate. Mit Maschinencode hat das nichts zu tun. Und dies: Ohne diese 'Daten' wären auch die Befehle nicht ausführbar. Das ist auch nicht richtig. Es gibt nur einen Sonderfall, wo die Daten tatsächlich irgendwie mit Befehlen in Verbindung stehen, und das ist, wenn ein Programm sich selbst schreibt (selbstmodifizierende Programme), sich also seine eigenen Befehle zusammenzimmert. Dazu braucht es dann irgendwelche Daten, die gewöhnlich im Speicher vorliegen. Aber auch in diesem Fall liegt wenigstens das "Startprogramm" von Anfang an vollständig ausführbar vor, und normale Programme, die sich nicht selbst modifizieren, liegen erst recht bereits mit vollständigen und für die CPU verständlichen, also insbesondere ausführbaren Befehlen vor. (Wobei es sein kann, dass das Betriebssystem noch die Aufgabe hat, die Befehle mit korrekten Speicheradressen auszustatten, sofern nicht absolut adressiert wird, aber auch das ist wieder einmal spezifisch für das Dateiformat.)
• Zu 3. Zunächst ist bei solcher Adressierung nicht das adressierte Datum ein Datum aus CPU-Sicht, sondern die Speicheradresse, und die steht entweder im Befehl selbst oder wurde vorher von einem anderen Befehl in ein Register geschrieben. Die CPU führt lediglich solche Ladebefehle aus, was dann zum Lesen von Speicherzellen führt. Die Daten, die eine CPU zur Ausführung des Programms benötigt, sind immer in den Befehlen verfügbar, sonst wüsste sie ja nicht, wie sie einen bestimmten Befehl ausführen muss, wenn da was fehlen würde. Ich wiederhole es also: Dass man in einem Assemblerprogramm direkt Daten angeben kann, die anschließend in die ausführbare Datei geschrieben und beim Ausführen vom Betriebssystem in den Speicher geschrieben werden, damit das Maschinenprogramm den Speicherinhalt vorfindet, den es erwartet, hat NICHTS mit der CPU und dem Maschinenprogramm selbst zu tun. Das ist eine reine Leistung des Betriebssystems. Noch deutlicher: Wenn das Betriebssystem diese Leistung nicht erbringen würde, müsste man in das Maschinenprogramm eine lange Kette von Speicherbefehlen reinschreiben, die der Reihe nach die gewünschten Werte in den Speicher schreiben. Diese Arbeit wird einem vom Betriebssystem abgenommen. Man darf einfach die Daten direkt im Assemblerprogramm angeben und sich darauf verlassen, dass sie vom OS automatisch in den Speicher geschrieben werden. Das Maschinenprogramm enthält sie bei einem solchen System also nicht, nur das Assemblerprogramm und die ausführbare Datei enthalten sie.
• Zu 4. Ich weiß nicht, was man da diskutieren soll. Diese Begriffe werden leider synonym verwendet, das ist nun einmal so, und weder der Artikel noch die Diskussion hat die Aufgabe, darüber zu spekulieren. Ich sehe auch keine "Fragestellung", die "ausführlicher" behandelt werden müsste. Das einzige, was es zu sagen gibt, ist, dass die Begriffe "Sprache" und "Code" in diesem Kontext anders gebraucht werden als sonst, aber das ist sicher nicht wesentlich genug, als dass die Einleitung sich darüber auslassen müsste.
• Und jetzt höre ich hier auf, denn das nützt weder dem Artikel noch mir etwas. ʘχ (Diskussion) 11:14, 16. Okt. 2012 (CEST)

Wir diskutieren hier über zwei Aspekte:

1. Dass bzw. ob Maschinencode und Maschinensprache Synonyme sind oder nicht. Da es hier (wie auch in en:WP) nur einen (1) Artikel gibt, in dem auch noch (durch die Klammerausdrücke) ausdrücklich die Synonym-Eigenschaft 'festgelegt' ist, muss der Text entsprechend formuliert sein. Mein Vorschlag dazu war, die evtl. differierende Bedeutung beider Begriffe dort zu erläutern - was du wieder mal notorisch ablehnst.
2. Dass zum Maschinencode auch Daten gehören: Ich weiß nicht, wo du was über Programmierung und Betriebssysteme etc. gelernt hast: Genauso wie zum Quellcode Datendeklarationen gehören (deren Syntax auch in jeder Programmiersprache (!) festgelegt ist), so gehören deren Äquivalente (ich nannte sie 'Datenbereiche'; das kann man ggf. anders nennen) zum Inhalt des Maschinencodes (syn. 'Maschinenprogramm') - der bei der Ausführung (i.d.R. vollständig) im Hauptspeicher liegt und dort vom Prozessor abgearbeitet wird inkl. Inputverwendung und Ergebnisbereitstellung (die 'Daten'). Wenn die Daten nicht dazugehören würden, wäre (siehe Compiler) der Maschinencode kein 'semantisches Äquivalent' des Quellcodes.

Ich erwarte nicht, dass du deine seltsame Sichtweise hier korrigierst, hoffe aber, dass jemand, der von der Sache wirklich etwas versteht - und einen gesunden Menschenverstand hat - diesen Aspekt in der Diskussion mit 'klären' hilft.--VÖRBY (Diskussion) 12:24, 16. Okt. 2012 (CEST)

Die Syntax von Datenbereichen wird aber nicht durch die Maschinensprache festgelegt, sondern durch ein Format für ausführbare Dateien. Es ist keineswegs notwendig, es ist reiner Service des Laders des Betriebssystems. Wie ʘχ bereits dargestellt hat: Man kann auch einfach in Maschinensprache mit den entsprechenden Anweisungen Wort für Wort die Daten bei sich im Speicher anlegen. --Chricho ¹ ² ³ 14:43, 16. Okt. 2012 (CEST)

In der Maschinensprache (= im Maschinencode!!!) wird natürlich nichts 'festgelegt', sondern das Pgm existiert einfach als 'Code' (Datei/Binärstring etc., vom Compiler ... erzeugt), den das Betriebssystem komplett lädt und der dann an der 'Startadresse' (steht auch im erzeugten Code) zur Ausführung startet. Sogar einfach Wort für Wort angelegte Befehle (ein m.E. theoretisches Szenario) würden sich wohl i.d.R. auf irgendwelche Datenfelder beziehen müssen - die man dann ebenfalls anlegen müsste.

Nochmal zusammenfassend: Wenn in einem Quellprogramm Datendeklarationen enthalten sind, dann sind deren Äquivalente (im entsprechenden Format) auch im Maschinencode (= in der ausführbaren Datei und dann auch im Hauptspeicher) enthalten. Und: Der Artikel HIER unterscheidet nicht zwischen 'Maschinensprache' und 'Maschinencode'!! Dass letzterer in Dateiform (ausführbare Datei, ein weiteres "~Synonym", das man evtl. in der Einleitung erläutern könnte) vorliegt, ist keine Besonderheit, das ist bei allen anderen Programmcode-Varianten auch so. --VÖRBY (Diskussion) 17:25, 16. Okt. 2012 (CEST)

Nein, ein Maschinenprogramm muss auf keinerlei deklarierte Datenfelder zugreifen, ich weiß nicht, wie du darauf kommst, aber das ist hier auch unwichtig. Maschinencode ist jedenfalls nicht dasselbe wie das, was in einer ausführbaren Datei steht. Ein Maschinenprogramm ist das, was letztlich im Speicher steht und vom Prozessor direkt abgearbeitet wird (er kann natürlich auch woanders stehen, etwa als Teil einer ausführbaren Datei oder auf dem Papier). Und in solchen gibt es keine Datendeklarationen. --Chricho ¹ ² ³ 00:22, 17. Okt. 2012 (CEST)

Wie soll denn z.B. ein Additionsbefehl ohne Datenfelder ablaufen? Der Befehl selbst adressiert die beiden beteiligten Felder - die in der Befehlsausführung 'gelesen' oder geändert werden: Das Decodieren des Befehls, die Übernahme der 'Datenfelder' ins Rechenwerk, dann das Addieren selbst und das Rückschreiben ins Empfangsfeld gehören zum 'Ausführen' des Befehls 'ADD' im Prozessor. Jetzt sage nur nicht, es gäbe auch Befehle, die nur in Registern arbeiten. Ja, die gibt es, aber es gibt auch viele andere; und ohne Datenfelder kann der Rechner (als Hardware-Blackbox gesehen) seine 'Leistung' nicht 'nach außen' transportieren. Weiterhin verweise ich auf mein Argument "semantisches Äquivalent" (s.o.).

'Papier' ist wohl ein Scherz von dir? Und dass der Maschinencode etwas anderes ist als die ausführbare Datei, haben wir ja schon oben behandelt, aber im Wesentlichen ist beides dasselbe, zumindest häufig im Sprachgebrauch.

Doch mal zurück zum Problem: Ich denke, wir diskutieren hier über völlig unterschiedliche Begriffe. Das kommt daher, dass in diesem Themenkomplex viele nah verwandte Begriffe zusammenwirken, die zT nur um Nuancen voneinander abweichen, zum Teil auch als Synonyme (evtl. in unkorrekter Weise) verwendet werden. So bin ich der Ansicht, dass M-Programm und M-Sprache eigentlich niemals dasselbe sein können. Der Artikel in der jetzigen Form beschreibt die Begriffe aber quasi als 'Synonym' und versucht, alle diese Begriffe 'unter einen Hut' zu bringen. Währenddessen unterstellen unsere Aussagen unterchiedliche 'Begriffe' (z.B. hebt Ox den Aspekt 'Sprache' besonders heraus). Deshalb diskutieren wir uns hier 'einen Wolf'. Ich wiederhole meinen Vorschlag nochmal: Man sollte die hier zusammenwirkenden Begriffe/Ausdrücke aufzählen und ihre 'Differenz' bzw. ihre 'Beziehung' zum Hauptbegriff erläutern, ebenso dass die Ausdrücke zT auch unterschiedlich interpretiert werden oder werden könnten (zB bei Code, Sprache), und dass sie zT als Synonyme benutzt werden. Vielleicht sollte das Lemma auch 'Maschinencode' (wie in en:WP) heißen. Ich würde in beiden Fällen (..Code/..Sprache) einen Unterabschnitt 'Verwandte Begriffe' einfügen und die Aussagen evtl. grafisch unterstützen. Ich hoffe, diesmal nicht "völlig am Thema vorbei" zu sein; denn dann wären wir drei nicht nur auf einem anderen Stern, sondern in einer anderen Galaxis.  ;-) --VÖRBY (Diskussion) 17:11, 17. Okt. 2012 (CEST)

Hast du mal darübe nachgedachte, wie diese Daten, auf denen deine Operation vllt. ausgeführt wird, in den Speicher kommen? Das läuft über Maschinencode! Der passende Befehl erhält eine Adresse und einen Wert und schreibt dann dahin (im einfachsten Fall, bei virtuellem Speicher etc. passiert natürlich noch wesentlich mehr). Und so verfährt auch der Lader des Betriebssystems, wenn er die ausführbare Datei mit den Datenbereichen sieht. Solche sind völlig unnötig und gehören zu einem Service des Dateiformats. --Chricho ¹ ² ³ 20:08, 17. Okt. 2012 (CEST)

Dein Beitrag macht mich völlig konfus! Du schreibst selbst "Das läuft über Maschinencode!", wobei ich präzisiere "das sind Teilstrings im Maschinencode (= Maschinenprogramm)", gemischt mit den Befehlen (siehe mein Hinweis zu 'Von-Neumann'*), kommen so gemeinsam beim Laden (ja, aus der ausführbaren Datei) in den Hauptspeicher und beide werden vom Prozessor beim 'Ausführen' (siehe oben*) be- bzw. verarbeitet. Also: Maschinencode = Befehle und ~Daten. Das ist aber alles schon mehrfach beschrieben.

(*) bitte schau dir diese Hinweise genau an. Nochmal: Entweder einer von uns "liegt gründlich daneben" oder wir reden von unterschiedlichen Dingen. --VÖRBY (Diskussion) 09:43, 18. Okt. 2012 (CEST)

Mit Maschinencode meinte ich da natürlich nur Befehle, weil es nur das ist. Von Datenbereichen weiß der Prozessor nichts, der bekommt Instruktionen und führt die aus, dass dabei auf irgendwelche Datenbereiche zugegriffen werden mag, ist ihm völlig egal. Die englische Wikipedia hat übrigens auch diese klare Beschreibung von Maschinencode: Zusätzliche Features von ausführbaren Dateien gehören nicht zum Begriff. --Chricho ¹ ² ³ 11:23, 18. Okt. 2012 (CEST)

"... meinte ich natürlich nur Befehle, weis es nur das ist." Du meinst, weil du das so meinst. Schau mal in der en:WP nach. Dort steht: "Harvard architecture is contrasted to the Von Neumann architecture, where data and code are stored in the same memory." D.h.: Auch im selben Maschinencode. Da hätten wir evtl. den Grund für unsere unterschiedlichen Ansichten.

Mindestens für V.N.-Architekturen betreffen die "zusätzlichen Features" bestimmt nicht diese dort offensichtlich zum Code gehörenden Datenbereiche. Interessant wäre noch, wie diese Datenbereiche bei der Harvard architecture genannt werden; zum 'semantischen Äquivalent' des Quellcodes sollten sie auf jeden Fall gehören.

zuletzt aktualisiert: --VÖRBY (Diskussion) 13:23, 18. Okt. 2012 (CEST)

Daten als Teil des Maschinencodes

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 16:03, 14. Nov. 2012 (CET)

(Fortsetzung von früheren Diskussionen)

Zu dieser kontroversen Fragestellung führte das Diskutieren bisher nicht zum Konsens. Deshalb halte mich an belegte Fakten: In Die Assemblersprache der intel 80x86-Prozessoren ([2]) nennt Prof Dr. Wüst (auf Seite 11) das Ergebnis des Compilers "Maschinencode". Dieser wird lt. Seite 28 im 'Speicher' in die Bereiche Stack, Daten und Code aufgeteilt. Man kann also sagen, im engeren Sinn ist 'Maschinencode' die Summe der Maschinenbefehle (Seite 9); zusätzlich zählen dazu - als Teilergebnis aus der Compilierung (die ein semantisches Äquivalent des Quellcodes herstellt) - auch die generierten Datenbereiche, die Voraussetzung (Quelle und Ziel) für die Maschinenbefehle sind. Je nach Rechnerarchitektur werden diese als getrennte Bereiche (bei 80x86-Prozessoren als 'Datensegment' im Datenspeicher bzw. als 'Codesegment' im Programmspeicher; siehe Seite 15) oder gemischt mit dem Befehlscode (bei der Von-Neumann-Architektur) abgelegt.

Dies zeigt auch, dass die verwendeten 'Ausdrücke' unterschiedliche Bedeutungen haben können - was ebenfalls als Erläuterung nützlich wäre. --VÖRBY (Diskussion) 09:17, 19. Okt. 2012 (CEST)

Im Einleitungskapitel die unterschiedliche Bedeutung ergänzt. Mit Quellenangabe, nach der die Datenbereiche je nach Architektur getrennt von oder gemischt mit den Maschinenbefehlen abgelegt wird. --VÖRBY (Diskussion) 11:09, 25. Okt. 2012 (CEST)

@Cricho und 0x: Ihr ignoriert die vorgelegten Belege und korrigiert wieder nach eurer "sturen Weltsicht", Daten gehörten nicht zum Maschinencode - trotz der Belege dafür hier in der Diskussion, zu der ihr keine Stellung mehr bezogen hattet. Nun ist es ja schon mal ein Erfolg, dass jetzt im Artikel steht, 'Maschinencode' habe auch eine von 'Maschinensprache' abweichende Bedeutung, nämlich als 'Maschinenprogramm'. Was das aber ist, wurde inkl. Beleg aus den Texten entfernt.
Nochmal: Wenn (lt. Beleg) der 'Maschinencode' (i.S. M-Programm) bei manchen Rechnerarchitekturen in ein Datensegment und ein Befehlssegment aufgeteilt wird, dann sind diese Datenbereiche ohne Zweifel Teil des 'Maschinencodes' (in diesem Sinn); woher sollten sie sonst kommen? Und: Im Maschinencode für die V-N-Architektur (aus der en:WP!) lassen sich die Daten gar nicht von den Befehlen abgrenzen, weil sie in einem (1) String hintereinander stehen, sowohl in der ausführbaren Datei als auch im Speicher. Ich werde deshalb diese Textpassage (entsprechend der en:WP) wieder in den Artikeltext aufnehmen und ggf. die QS (Informatik) in diese 'Aktion' einschalten. --VÖRBY (Diskussion) 13:01, 26. Okt. 2012 (CEST)

Nicht wir sind stur, sondern du. Du kommst regelmäßig mit eigenen Interpretationen und TFs an, findest dann Textstellen, die du in deinem eigenen Sinne interpretierst, um nicht zu sagen missverstehst, und baust die Artikel um. Tut mir leid, aber du verstehst diese Dinge offenbar nicht und hast auch kein Verständnis von Informatik. Warum bist du in diesem Bereich bloß aktiv?

Um dir das zu zeigen, brauchen wir bloß einen Blick auf die von dir genannte Seite 28 im Skript von Wüst werfen. Dort steht mit keinem Wort, der Maschinencode sei in Stack, Daten und Code aufgeteilt. Dort wird die Aufteilung des Speichers in diese drei Bereiche erklärt, und zwar im Kontext von 16-Bit-Umgebungen. Auf Seite 11 findet sich der Satz: Compiler erzeugen in der Regel direkt Maschinencode, manche Compiler können aber optional auch Assemblercode erzeugen. Ich wiederhole, was wir bereits deutlich sagten: Der Satz bedeutet nicht, dass jedes einzelne Byte, das vom Compiler in eine Datei geschrieben wird, Maschinencode ist. Du lässt mir keine Wahl, ich muss es ganz deutlich sagen: Du hast keine Ahnung von Compilern, keine Ahnung von Architekturen (du meinst bekanntlich, x86 sei keine Von-Neumann-Architektur), und keine Ahnung von Maschinensprache. ʘχ (Diskussion) 15:06, 26. Okt. 2012 (CEST)

Danke für die Komplimente. Damit kann ich leben. Nie habe ich behauptet, 'jedes einzelne Byte' in der ausführbaren Datei sei Maschinencode. Es ist aber umgekehrt: Der volle Maschinencode befindet sich in der a.D., in welcher Form auch immer - plus 'andere Informationen zur Verwaltung, zum Laden und Ausführen' (wie ich mal geschrieben hatte, was aber wieder gelöscht wurde). Zu 'Daten im M-Code' wiederhole ich mich nochmal (für besonders kompetente Leute) und bitte um konkrete Antwort:

1. Woher kommen die 'Informationen', die im auf S. 28 genannten Fall als bzw. im 'Datensegment' abgelegt werden? Sag ja nicht, aus der 'ausführbaren Datei' - denn diese ist lediglich das Medium, in dem der 'Maschinencode' (i.S. M-Programm) gespeichert ist.
2. Wenn in 'anderen' Architekturen Daten und Befehle total gemischt angelegt werden (kein TF, sondern aus en:WP), wie sollen dann eben diese 'Daten' nicht zum Maschinencode (i.S. M-Programm) 'gehören'?

Im Übrigen waren diese Architekturunterschiede nicht Gegenstand der Diskussion; es ging nur um die Mini-Aussage, dass die ~Daten Teil des M-Programms seien. Dass M-Code zwei unterschiedliche Bedeutungen hat und wir hier i.S. von M-Programm diskutieren, hast du ja hoffentlich mitbekommen.--VÖRBY (Diskussion) 17:47, 26. Okt. 2012 (CEST)

Mit von-Neumann-vs.-Harvard-Architektur hat das einfach überhaupt nichts zu tun. Bei der Harvard-Architektur gibt es eine physische Trennung von Daten- und Befehlsspeicher, während bei einer von-Neumann-Architektur wie x86 und Konsorten der gesamte Speicher sowohl für Daten wie auch für Befehle verwendet werden kann (in jüngerer Zeit mit bestimmten Schutzemechanismen, bei denen Teile als ausführbar markiert werden). Davon unabhängig können ausführbare Dateien, Objektdateien etc. neben Maschinencode auch Datenbereiche enthalten, als besonderer Service des Laders, unabhängig von der zugrundeliegenden Architektur. Das, was Wüst Datenbereich nennt, ist etwas völlig anderes, das ist ein Teil des Hauptspeichers, der eben nicht für Stack oder Code vorgesehen ist, hier können zum Beispiel die Datenbereiche aus der ausführbaren Datei hingeschrieben werden, an dieser Stelle einen Heap zu verwalten wäre allerdings ebenso denkbar. In jedem Fall gilt: Weder besagte Teile des Hauptspeichers noch die Datenbereiche in einer ausführbaren Datei sind Maschinencode, Maschinencode ist das, was durch den Befehlsdecoder der Maschine o. ä. geht. --Chricho ¹ ² ³ 18:14, 26. Okt. 2012 (CEST)

Ist ja alles gut. Was willst du immer mit dem 'besonderen Service des Laders'? Der lädt einfach das 'Maschinenprogramm' (hier Synonym zu Maschinencode) in den Speicher, mit allem was dazu gehört. Warum willst du 'Code' nur auf die Befehle beziehen? Auch die Daten liegen in 'codierter Form' vor. Übrigens ist das beim 'Quellcode' genauso; da gehören auch die Datendefinitionen dazu. Zu deiner 'ausführbare Datei' erspare ich mir die Antwort, das hatten wir schon. Jedenfalls werden die Daten genauso in den Speicher geladen wie die Befehle, notfalls in getrennte Bereiche.

Du hast aber meine beiden Fragen nicht beantwortet. Und jetzt käme noch die Analogie mit Quellcode dazu. Bitte nur noch kurz diese 3 Antworten, nicht wieder neue Romane.

PS: zu meinem Wissen über Maschinencode: Schon vor über 30 Jahren habe ich Maschinencode (inkl. Datenbereichen!) ge-debugged und ge-patched. --VÖRBY (Diskussion) 20:01, 26. Okt. 2012 (CEST)

Ich habe die beiden Fragen oben beantwortet. Sowohl, wie bei der im Skript aufgezeichneten Speichersegmentierung für 16-Bit-Systeme Sachen in den Datenbereich kommen, als auch, warum das mit Von-Neumann- und Harvard-Architektur nichts zu tun hat. Definitionen globaler Variablen gehören zum in Hochsprache verfasstem Quellcode, weil die entsprechenden Codeteile (static int x = 1;…) eben durch die Sprache (etwa C) beschrieben werden. Datenbereiche in ausführbaren Dateien sind dagegen nicht durch die Maschinensprache beschrieben, sondern durch die „Sprache der ausführbaren Datei“, die mit der Maschine nichts am Hut hat. --Chricho ¹ ² ³ 20:26, 26. Okt. 2012 (CEST)

Es ist zum Haareraufen: Wer hat behauptet, diese Daten seien durch die Maschinensprache beschrieben? Du bist immer noch und immer wieder auf dem Trip, dass M-Code ausschließlich ein Synonym zu M-Sprache ist. Es geht aber hier um den M-Code i.S. von Maschinenprogramm. Deshalb formuliere ich meine Fragen nochmal und bitte, nur mit JA oder NEIN zu antworten:

1. Stammen die 'Informationen', die der Lader im auf S. 28 genannten Fall als bzw. im 'Datensegment' speichert, aus dem vom Compiler etc. generierten (und in der ausführbaren Datei gespeicherten) Maschinenprogramm?
2. Sind die Datenbereiche, die (in bestimmten Architekturen) gemischt mit den Befehlen im Speicher angelegt werden, Teil des erzeugten und dann im Speicher stehenden Maschinenprogramms?
3. Ist ein Maschinenprogramm das 'semantische Äquivalent' (so steht es bei 'Compiler') des Quellcodes (dessen Instruktionen ebenfalls aus Daten und Befehlen bestehen)?

PS: Was soll das mit 'globalen Variablen' zu tun haben? Es geht um alle für das Programm spezifizierten Datenfelder, egal wie diese im Speicher abgelegt werden.--VÖRBY (Diskussion) 11:30, 27. Okt. 2012 (CEST)

1. Nein, sie stammen aus der vom Compiler generierten ausführbaren Datei.
2. Nein, genauso wenig wie andere Sachen, die irgendwer im Speicher ablegt, etwa was auf dem Stack liegt.
3. Der vom Compiler erzeugte Maschinencode ist semantisches Äquivalent zu Teilen des Quelltextes, aber evtl. wird beim Kompilieren noch weiteres erzeugt, das kein Maschinencode ist und streng genommen zum semantischen Äquivalent zählt (denke zum Beispiel an das Zeug, was so in .jar-Dateien landet), aber das ist Haarspalterei, und darauf näher im Compilerartikel einzugehen, wäre TF. --Chricho ¹ ² ³ 18:57, 27. Okt. 2012 (CEST)

Danke, mir sollen diese Antworten genügen. Mit derart viel Ignoranz und Selbstüberschätzung ist das Ganze sinnlos. So etwa antwortest du zu 1. mit 'nein', ergänzt aber dasselbe, das in der Frage genannt ist. Irgendwie schräg. Nur weiter so! Ich schließe hier ab. --VÖRBY (Diskussion) 09:54, 28. Okt. 2012 (CET)

Aus meiner Sicht fallen die Antworten wie folgt aus:

Zu 1: JA, woher sollten sie sonst kommen? Daten und Befehle (der Maschinencode) sind ein aufeinander abgestimmtes 'System von Instruktionen' (s. en:WP). Die Lage (Adresse, Länge) und das Format der Datenfelder werden vom Compiler überprüft und im M-Code/M-Programm (zwischengespeichert in der ausführbaren Datei) exakt so angelegt, dass die Befehle (die diese Daten ansprechen) korrekt ausführbar sind.

Zu 2: JA, wenn das ganze Maschinenprogramm eine Folge von 'Bytes' ist, dann sind die darin (ggf. verstreut) enthaltenen Datenbereiche zwangsläufig 'Teil des Maschienprogramms'.

Zu 3: JA, 'semantisch äquivalent' betrifft das Zusammenwirken ('System') von Befehlen und definierten Daten. 'Ein bisschen äquivalent' gibt es in diesem wesentlichen Funktionsbereich des Compilers (und seiner Ergebnisse) nicht. Das schließt nicht aus, dass in der ausführbaren Datei weitere Informationen enthalten sind.

Benutzer:VÖRBY, ursprünglich leider ohne Signatur, Nachtrag heute erfolgt:--VÖRBY (Diskussion) 18:52, 2. Nov. 2012 (CET)

Was bringt dich bloß dazu, vehement mit deinen Privatmeinungen gegen Leute zu wettern, die sich mit diesen Dingen besser auskennen? Bitte interpretier die Tatsache, dass wir uns mit dir beschäftigen, nicht so, dass diese deine Privatansichten irgendwie im Kontext des Artikels diskussionswürdig wären. Wir müssen den Artikel einfach schützen, wie bereits in der Compiler-Disk.

• Zu 1 und 2: Chricho hat Recht, und das hatten wir alles schon. Siehe meine ausführliche Beschreibung des Verhältnisses Programm/Daten vor 2 Wochen und meine Demonstration unten.
• Zu 3: Chricho hat Recht. Ganz streng genommen ist das erzeugte Maschinenprogramm für sich allein genommen kein semantisches Äquivalent, denn ihm fehlen diejenigen Informationen, die separat vom Programm in der ausführbaren Datei abgelegt werden. Das liegt daran, weil eben der Compiler von der Existenz einer bestimmten Umgebung (Lader etc) ausgeht. Wenn man nun also mit TF anfängt, könnte man sagen, der gesamte Inhalt einer ausführbaren Datei ist ein semantisches Äquivalent zum Quellcode bezüglich der Systemumgebung, jedoch ist das -- wie Chricho bereits sagte -- weitgehend unwichtig.

So, und jetzt habe ich mir die Mühe gemacht, dir sogar mal vorzuführen, wie das aussieht, siehe unten. ʘχ (Diskussion) 10:49, 29. Okt. 2012 (CET)

Eine Demonstration des Unterschieds ...

Gegeben ist dieses C-Programm:

const char s[] = "Dies ist ein Datenbereich.";

int main(int argc, char** argv) {
	return s[argc];
}

In diesem Programm ist der String s ein "Datenbereich" (besser: ein Datum), der vom Compiler nicht ins Maschinenprogramm geschrieben wird. Statt dessen wird dem Lader überlassen, diese Daten in den Speicher zu schreiben, siehe das Listing:

   1              		.file	"asm.c"
   2              		.intel_syntax noprefix
   3              		.text
   4              	.Ltext0:
   5              		.globl	main
   7              	main:
   8              	.LFB0:
   9              		.file 1 "asm.c"
   1:asm.c         **** const char s[] = "Dies ist ein Datenbereich.";
   2:asm.c         **** 
   3:asm.c         **** int main(int argc, char** argv) {
  10              		.loc 1 3 0
  11              		.cfi_startproc
  12              	.LVL0:
   4:asm.c         **** 	return s[argc];
  13              		.loc 1 4 0
  14 0000 4863FF   		movsx	rdi, edi
  15 0003 0FBE8700 		movsx	eax, BYTE PTR s[rdi]
  15      000000
   5:asm.c         **** }
  16              		.loc 1 5 0
  17 000a C3       		ret
  18              		.cfi_endproc
  19              	.LFE0:
  21              		.globl	s
  22              		.section	.rodata
  23              		.align 16
  26              	s:
  27 0000 44696573 		.string	"Dies ist ein Datenbereich."
  27      20697374 
  27      2065696E 
  27      20446174 
  27      656E6265 
  28              		.text
  29              	.Letext0:

Wie man ganz offensichtlich sieht, ist der String s zwar Teil des Assemblerprogramms, aber nicht Teil des Maschinenprogramms: denn das besitzt keinen einzigen Befehl, der in der Lage wäre, s zu erzeugen. Statt dessen liegt s einfach so im Speicher (Zeile 27), und es wird einfach so adressiert -- weil das Maschinenprogramm davon ausgeht, dass der Lader den String vorher in den Speicher geschrieben hat. Ich will es betonen: Wenn dieses Assemblerprogramm nun in eine ausf. Datei umgewandelt wird, ist nicht das erzeugte Maschinenprogramm, sondern der Lader dafür verantwortlich, die Daten in den Speicher zu packen.

Im Gegensatz dazu präsentiere ich dir jetzt ein Programm, dessen Daten tatsächlich Teil des Maschinenprogramms werden:

int main(int argc, char** argv) {
	const char s[] = "Dies ist ein Datenbereich.";
	return s[argc];
}

Der String s wird in diesem Fall ins Maschinenprogramm aufgenommen, und der Lader ist aus dem Rennen:

   1              		.file	"asm.c"
   2              		.intel_syntax noprefix
   3              		.text
   4              	.Ltext0:
   5              		.globl	main
   7              	main:
   8              	.LFB0:
   9              		.file 1 "asm.c"
   1:asm.c         **** int main(int argc, char** argv) {
  10              		.loc 1 1 0
  11              		.cfi_startproc
  12              	.LVL0:
   2:asm.c         **** 	const char s[] = "Dies ist ein Datenbereich.";
  13              		.loc 1 2 0
  14 0000 C74424E0 		mov	DWORD PTR [rsp-32], 1936025924
  14      44696573 
  15 0008 C74424E4 		mov	DWORD PTR [rsp-28], 1953720608
  15      20697374 
  16 0010 C74424E8 		mov	DWORD PTR [rsp-24], 1852400928
  16      2065696E 
  17 0018 C74424EC 		mov	DWORD PTR [rsp-20], 1952531488
  17      20446174 
  18 0020 C74424F0 		mov	DWORD PTR [rsp-16], 1700949605
  18      656E6265 
  19 0028 C74424F4 		mov	DWORD PTR [rsp-12], 1667851634
  19      72656963 
  20 0030 66C74424 		mov	WORD PTR [rsp-8], 11880
  20      F8682E
  21 0037 C64424FA 		mov	BYTE PTR [rsp-6], 0
  21      00
   3:asm.c         **** 	return s[argc];
  22              		.loc 1 3 0
  23 003c 4863FF   		movsx	rdi, edi
  24 003f 0FBE443C 		movsx	eax, BYTE PTR [rsp-32+rdi]
  24      E0
   4:asm.c         **** }
  25              		.loc 1 4 0
  26 0044 C3       		ret
  27              		.cfi_endproc
  28              	.LFE0:
  30              	.Letext0:

Das sollte es ja wohl endlich klar machen. ʘχ (Diskussion) 10:49, 29. Okt. 2012 (CET) Korrektur: ʘχ (Diskussion) 12:39, 29. Okt. 2012 (CET) Typo fix ʘχ (Diskussion) 12:41, 29. Okt. 2012 (CET)

Hallo ʘχ oder Cricho (?): Du hast dir viel Arbeit mit den Beispielen gemacht. Leider zeigen diese aus meiner Sicht aber keine unser Thema betreffenden Unterschiede:

Oben steht jeweils das Quellprogramm, unten sieht man den daraus generierten Maschinencode. In beiden Fällen wird genau dieser Code beim Load des Programms in den Speicher geladen, die 'Befehle' werden ausgeführt, ggf. unter Nutzung (Quelle, Ziel) der dazugehörenden und adressmäßig exakt passenden Datenfelder. Wenn ein Pgm keine 'Daten' hat, entfällt natürlich der Aspekt 'Datenbereiche', das gibt es aber praktisch kaum.

Unsere Diskrepanz ist wohl 'lediglich' ein Definitionsproblem: Du meinst mit 'Maschinenprogramm' und -Code nur die Befehle, ich meine alles, was generiert wurde und zur Ausführung erforderlich ist. Darüber hinaus scheint für dich 'M-Code' und 'M-Programm' ausschließlich das zu sein, das im Speicher ausgeführt wird, während m.E. die Definition dafür auf das Codeformat abstellt, was bedeutet, dass ein 'M-Pgm' z.B. auch in der ausführbaren Datei liegen kann. Für meine These (M-Pgm = Befehle und Daten) füge ich weitere Belege an:

• Computerlexikon [3]:

Maschinenprogramm = Lauffähiges Programm im Binärcode. Ergänzung meinerseits: Ohne die Daten ist das Programm nicht lauffähig.

• Uni Ulm [4]:

Seite 8: Aufgaben eines Binders: Suche in Bibliotheken nach externen Referenzen und Einfügen der gefundenen Code- oder Datenfragmente in das resultierende Maschinenprogramm

Seite 2 zeigt für einen 'hypothetischen' Fall den Quellcode, den Ass-Code und den Maschinencode - jeweils mit Daten und Befehlen

Seite 14 zeigt nochmal Maschinencode, beide Teile enthaltend.

Wir sollten die weitere Diskussion jetzt einstellen und sie 'Dritten Meinungen' überlassen. Denn wir beide kommen da wohl nicht mehr zusammen. --VÖRBY (Diskussion) 18:55, 29. Okt. 2012 (CET), ergänzt: --VÖRBY (Diskussion) 12:31, 30. Okt. 2012 (CET)

Dritte Meinung erbeten

Nach wiederum neuen Reverts im Artikel habe ich um eine 'Dritte Meinung' gebeten.--VÖRBY (Diskussion) 13:36, 28. Okt. 2012 (CET)

Imo ist "Daten" zu ungenau.

• Variable existieren nur als Adressen (Offsets) in den MemoryBefehlen des Codes
• Konstante bzw. die Werte davon sind im Code enthalten.

Sprich, der Maschinencode besteht grundsätzlich aus Instruction-code und Literalen. Wer dann was wohin transferieren muss (und ob), ist auch im Code festgelegt und dadurch Teil davon. --RobTorgel (Diskussion) 15:35, 2. Nov. 2012 (CET)

Btw: In den ob. Beispielen sieht man, dass der Inhalt des Strings in beiden Fällen im Code enthalten ist. Das bei dieser konkreten Plattform der Loader bei geeigneter Codierung den Transfer übernimmt, hat ja damit nix zu tun. --RobTorgel (Diskussion) 15:38, 2. Nov. 2012 (CET)

Das hat insofern damit zu tun, dass der Code für den Inhalt des Strings im einen Fall kein Maschinencode ist, sondern durch ELF vorgesehen ist, was mit der Maschine nichts zu tun hat, und vom Lader interpretiert wird. Die Sachen, die da ab Zeile 19 stehen, entsprechen keinem Maschinencode, da es so etwas in x86-64 gar nicht gibt. --Chricho ¹ ² ³ 16:10, 2. Nov. 2012 (CET)

Danke RobTorgel. Nur ein kurzer Hinweis: Für die strittige Frage sind nur Beispiele passend, bei denen im (Quell-) Programm tatsächlich Daten definiert sind - wie Konstanten, IO-Bereiche für Daten, Register-Save-Area, Arbeits-Arrays, Schalter, Gruppensummenfelder etc. (= Angabe zu "'Daten' zu ungenau"). Ist das nicht der Fall, stellt sich 'unsere' Frage natürlich nicht. RobTorgel bestätigt aber anscheinend, dass "der Inhalt des Strings in beiden Fällen im Code enthalten ist". --VÖRBY (Diskussion) 18:42, 2. Nov. 2012 (CET)

Erstens sind in den Beispielen Daten definiert im Programm. Tut mir leid, DIE STEHEN DA, Diskussion nicht möglich. Was ist das für ein Kindergarten hier?

Zweitens: Was RobTorgel dazu sagt, geht am Thema vorbei. ʘχ (Diskussion) 19:31, 2. Nov. 2012 (CET)

Ein wenig kommt es darauf an, wie weit man auf die modernen Praktiken eingehen oder doch beim Grundsätzlichen bleiben will (würde ich bevorzugen). Natürlich gibt es spätestens heutzutage eine Reihe Möglichkeiten für den Compiler/Linker, Daten (Konstanten, Literale) für den Lader bereitzustellen (s.o. ELF). Aber welche davon ergriffen wird, legt der Compiler fest. Bei allen Variablen, die erst zur Laufzeit befüllt werden können (weil sie z.B. am Stack liegen), muss der Code und die Werte dazu letzlich vom Compiler generiert werden. Das Beispiel oben mit der globalen Variablen ist ja eher ein Sonderfall. Read-Only Konstanten/Texte werden auch oft/meist garnicht in ein Datenbereich verschoben, sondern bleiben dort im Code, wo sie grad in der Source angegeben wurden. --RobTorgel (Diskussion) 19:42, 2. Nov. 2012 (CET)

Ich habe doch selbst die Funktionsweise dieser Geschichte oben vorgeführt, wieso erklärst du mir das jetzt? Und was anderes haben Chricho und ich ja auch nie gesagt. Wie ich oben ausführlich dargelegt habe, gibt es genau zwei Möglichkeiten, Daten in einer ausf. Datei unterzubringen: Entweder im Maschinenprogramm selbst oder eben außerhalb davon. Es geht hier also nicht um den Compiler oder was der tut, das ist nicht das Problem! Und diese Debatte ist absolut hinfällig, das ist alles eine Farce hier. Abgesehen von der Theorie, die VÖRBY ablehnt, weil nicht versteht, ignoriert er sogar die technischen Beweise, die ich ja mittlerweile gebracht habe. ʘχ (Diskussion) 21:18, 2. Nov. 2012 (CET)

DISKUSSIONSENDE: Auch unter Beteiligung von zwei 3M-Autoren (siehe folgende Teilabschnitte) wurde die strittige Fragestellung 'Sind Daten Teil des M-Progrmams' durch eine 'Kann'-Formulierung im Artikel behandelt. Ob sich dieses 'Kann' lediglich aus einer anderen Auslegung des Begriffs 'Maschinencode' ergibt oder von technischen Gegebenheiten abhängt, bleibt offen. Trotzdem kann die Diskussion aus meiner Sicht beendet werden. Mich persönlich wundert nur, dass eine derart triviale Fragestellung nicht von einer größeren Anzahl an 'IT-Wikipedianern' eindeutig mit Ja oder Nein beantwortet werden kann. --VÖRBY (Diskussion) 10:36, 7. Nov. 2012 (CET)

"Frage offen", trotz Dritter Meinungen, in einer derart trivialen Frage - mit diesem Status wollte ich die Diskussion nicht auf ERLEDIGT setzen. Ich suchte deshalb die Antwort über eine weitere Quelle und stellte einem Informatik-Fachbereich einer Deutschen Universität die Fragestellung zu.

Frage: Sind die in einem Programm deklarierten Datenbereiche Teil des Maschinenprogramms?'

Potenzielle Antwort - von mir verfasst: Wie sollte ein Programm ohne die darin deklarierten Daten funktionieren? Quellprogramme bestehen aus Datendeklarationen und den darauf operierenden Befehlen. Der Übersetzer überprüft diese Zusammenhänge und legt Befehle und Daten im Maschinenprogramm exakt so an, dass die Befehle bei der Ausführung im Hauptspeicher (wohin beide beim Laden transferiert werden) ihre referenzierten Datenfelder korrekt ansprechen können - für das Ausführen der Maschinenbefehle absolute Voraussetzung. So bilden Daten und Befehle über den gesamten Lebenszyklus eines Programms hinweg (und sogar schon bevor Quelltext entsteht, in der System- und Datenmodellierung) einen engen, gegenseitig eng voneinander abhängigen 'Systemverbund'.

Fazit: Daten sind selbstverständlich Teil des Maschinenprogramms, unabhängig davon, in welcher Form dieses in Erscheinung tritt, als Objektmodul, als Lademodul oder im Hauptspeicher; gemischt mit den Maschinenbefehlen oder in getrennten Datensegmenten. Dass unter 'Maschinencode' umgangssprachlich oft nur die 'Maschinenbefehle' gemeint sind, ändert daran nichts. Daraus resultierenden Missverständnissen könnte durch entsprechende Hinweise im Artikeltext vorgebeugt werden.

Antwort des Lehrstuhls dazu: "völlig richtig, kann ich 100% akzeptieren!"

Vor dem endgültigen Setzen auf 'ERLEDIGT' eingefügt: --VÖRBY (Diskussion) 11:04, 13. Nov. 2012 (CET)

Lehrbuchdefinitionen

seid ihr euch sicher, dass man euer problem nicht durch nachschlagen in einem lehrbuch loesen kann? --Mario d 20:01, 4. Nov. 2012 (CET)

Es ist gerade VÖRBYs Spezialität, sich Texte aus Lehrbüchern zu nehmen, die nach eigenem Gutdünken falsch zu verstehen oder um eigene Zusätze zu ergänzen und dann zu sagen, seine Ansichten würden von allen möglichen Professoren geteilt. Aber selbstverständlich ist das Problem, um das es geht, eine Banalität und den ganzen Aufriss nicht wert. ʘχ (Diskussion) 20:41, 4. Nov. 2012 (CET)

Das Problem ist, dass die in diesem Zusammenhang relevanten Begriffe sowohl in Fachpublikationen als auch im Sprachgebrauch zT unterschiedlich benutzt werden, teils als Synonyme, teils als Homonyme. Dies im Artikel entsprechend zu erläutern, wäre eigentlich für eine Enzyklopädie angebracht, wurde von mir mehrfach vorgeschlagen - siehe z.B. Disk vom {17:11, 17. Okt. 2012 (CEST)} und {16:58, 15. Okt. 2012 (CEST)} - wurde aber immer wieder - siehe z.B. {11:14, 16. Okt. 2012 (CEST)} - abgelehnt. Die oben benannten Quellen jedenfalls bezeichnen sowohl Befehle als auch Daten als Teil des 'Maschinenprogramms' (bzw. Synonymbezeichnungen). --VÖRBY (Diskussion) 08:58, 5. Nov. 2012 (CET)

Wenn es zulässige Quellen mit verschiedenen Sichtweisen gibt, dann ist es unsere Aufgabe, das auch darzustellen. Dann müssen wir, was den Artikel betrifft, auch akzeptieren, persönlich eine andere Meinung zu haben. Dass es fast generationsabhängige Unterschiede gibt, verwundert nicht, denn die Altspatzen mussten Maschinenprogramme erstellen, laden und damit arbeiten, bevor die neue Informatik versuchte zu erklären, was das überhaupt ist. --RobTorgel (Diskussion) 09:28, 5. Nov. 2012 (CET)

Na ja -- die Berechenbarkeitstheorie, die eben diese Frage behandelt, "was das überhaupt ist", wurde im Laufe der 1920/30er Jahre aufgebaut. Von daher würde ich sagen, dass ein Programmierer in den 50er oder 60er Jahren durchaus hätte wissen können, wenn er hätte wissen wollen. ʘχ (Diskussion) 10:33, 5. Nov. 2012 (CET)

Aus gutem Grund werden wir solche Überlegungen zu „Synonymen und Homonymen“ hier nicht in den Artikel einfließen lassen. Es wäre schlimme Theoriefindung, die darauf basieren müsste, aus dem Wortgebrauch verschiedener Autoren irgendwelche Implikationen über verschiedene Bedeutungen herauszulesen, die wahrscheinlich überhaupt nicht gewollt sind, weil ein sehr präziser Wortgebrauch nicht notwendig war (weil es in den Büchern eben nicht um die Abgrenzung von Maschinencode von was auch immer geht, sondern um ganz andere, konkretere Dinge). --Chricho ¹ ² ³ 12:59, 5. Nov. 2012 (CET)

dass fachbegriffe von verschiedenen autoren verschieden genutzt werden, ist keine seltenheit. in dem fall sollten alle relevanten ansichten dargestellt werden. hier geht es aber wohl nur um einen einzigen satz, da waere es besser, eine neutrale formulierung zu finden die von allen schulen akzeptiert wird. ich schlage vor, ihr hoert auf, euch gegenseitig ueberzeugen zu wollen (das scheint mir bei definitionen eher sinnlos) und arbeitet gemeinsam eine formulierung aus mit der alle leben koennen. --Mario d 13:08, 5. Nov. 2012 (CET)

Es geht in der Tat nur um eine Winzigkeit, nämlich ob Daten Teil des Maschinenprogramms sind oder nicht. Das wird im Artikel zwar bereits an drei Stellen erwähnt, doch wurde genau diese Daten-Aussage, die sich sinngemäß auch in der en:WP ('#Storing [machine code] in memory') findet, bereits mehrfach korrigiert, entfernt und zT wieder revertiert. Deshalb schien die fachliche Klärung erforderlich.

Wieder lehnt Chricho ab, verwandte oder Synonym-Begriffe im Artikel präziser zu erläutern. Dabei fehlen gerade in diesem Lemma solche begriffliche Abgrenzungen und Erläuterungen: Schon M-Sprache und M-Code sind einerseits Synonyme, andererseits ist M-Code auch Synonym zu M-Programm oder auch zu Befehlscode oder zu Opcode. Und im Sprachgebrauch treten sie auch unterschiedlich auf. Alles zusammen immer wieder Ursache von Missverständnissen, auch hier in der Diskussion. Aber "da gibts nichts zu diskutieren". --VÖRBY (Diskussion) 19:22, 5. Nov. 2012 (CET)

Ich würde M-Programm hier herausheben. Ein M-Programm ist eine Zusammenstellung von M-Code. (Analog Text vs. Ascii-Code)--RobTorgel (Diskussion) 19:59, 5. Nov. 2012 (CET)

ich sehe hier drei optionen:

• ihr lasst den strittigen satz einfach weg
• ihr erklaert mithilfe von fachliteratur und gut belegt die verschiedenen bedeutungen des wortes "maschinencode" (ist immerhin eine weiterleitung auf diesen artikel)
• ihr macht weiter mit "der Chricho macht immer ..." und "der VÖRBY hat aber ...", dann gehe ich davon aus, dass das hier ein benutzer- und kein sachkonflikt ist und setze ich den eintrag in der QSI gleich auf erledigt. --Mario d 20:34, 5. Nov. 2012 (CET)

Wenn es so funktionieren würde, warum wurde dann eine so einfache Lösung nicht längst gewählt? Das hier ist längst kein Sachkonflikt mehr. Die informatischen Fakten sind elementar und simpel, dennoch werden sie nicht akzeptiert, und sogar Dinge, die schwarz auf weiß auf dem Bildschirm erscheinen, werden geleugnet. (Guck mal die Antworten auf meine "Demonstration" an ...) Also meinetwegen alles auf "erledigt" setzen und gut ist. Aber ich bezweifle, dass das funktioniert. Im Grunde macht VÖRBY hier Vandalismus, allerdings mit raffinierter, gut getarnter Methode. ʘχ (Diskussion) 21:05, 5. Nov. 2012 (CET)

wenn ich mir im artikel den einzelnachweis und die literaturangabe (beides singular!) anschaue, dann weiss ich als laie erstmal nicht, welcher der hier auf der disku vorgeschlagenen definitionen ich glauben soll. wenn der artikel etwas besser aussaehe, waeren solche diskussionen auch einfacher zu fuehren. --Mario d 23:53, 5. Nov. 2012 (CET)

Ja, auch meinetwegen setzen wir das Ganze auf ERLEDIGT; denn auf das Erläutern verschiedener Bedeutungen und verwandter Begriffe können WIR uns auf diesem Planeten wohl nicht mehr einigen. Allerdings muss wenigstens der gestern gelöschte (soviel zu 'Vandalismus'), bisher einzige, sparsam erläuternde Hinweis auf die Synonymbeziehung zwischen M-Code und M-Programm, wieder in den Text eingestellt werden. Quelle: Gabler Verlag (Herausgeber), Gabler Wirtschaftslexikon, Stichwort: Maschinencode, online im Internet: [5]: „Synonym für Maschinenprogramm (Programm), das im Binärcode eines Computers dargestellt ist und deshalb von ihm direkt ausgeführt werden kann.“ Wenn das sonst niemand tut, werde ich das nachholen und danach die ganze Disk hier auf ERLEDIGT setzen. Schade, dass der eigentlich triviale Sachverhalt 'M-Code = Befehle + Daten' (abgesehen vom sprachlichen 'Dickicht') niemand auf die eine oder andere Weise bestätigen kann / will. --VÖRBY (Diskussion) 10:14, 6. Nov. 2012 (CET)

der link alleine stuetze deine these nicht; meinem verstaendnis nach fuehrt man ein programm auf einer eingabe aus, zum beispiel so: "der Lochstreifen enthielt jeweils eine Rechenoperation und eine Speicheradresse." (Computerprogramm#Erste_Programme_auf_Lochstreifen) wenn man bei deiner definition auf "programm" klickt, landet man hier: "2. Speziell: bei Verwendung einer prozeduralen Programmiersprache maschinenverständliche Darstellung des Algorithmus und der Daten, die dieser bearbeitet." kann mir jemand erklaeren, warum dort "prozedural" und nicht "maschinennah" steht? --Mario d 10:47, 6. Nov. 2012 (CET)

Denke, weil "prozedural" ein wichtiges Merkmal eines M-Programmes ist. (Auch ein Compiler mit deklarativen Statements muss das in Prozeduren auflösen). --RobTorgel (Diskussion) 11:02, 6. Nov. 2012 (CET)

• Nein, so ist das nicht gemeint. Mit "maschinenverständlich" ist in dem zitierten Wirtschaftslexikon nicht "maschinensprachlich" gemeint, sondern "formal". Ein C- oder Java-Programm ist maschinenverständlich, weil es formal definiert ist; ein in normalem Deutsch beschriebener Algorithmus hingegen ist nicht maschinenverständlich, weil nicht formal.
• Im Falle einer rein prozeduralen Sprache hat man i.d.R. den Fall, dass man zwischen einem Algorithmus und den Daten, die er verarbeitet, unterscheidet. Daher sagt das Lexikon bei Verwendung einer prozeduralen Programmiersprache maschinenverständliche Darstellung des Algorithmus und der Daten, die dieser bearbeitet. Zumindest nehme ich mal stark an, dass das der Grund ist.
• @RobTorgel: Gängige Maschinensprachen sind keine prozeduralen Sprachen. ʘχ (Diskussion) 11:29, 6. Nov. 2012 (CET)
• Nachtrag: Ha, guckt mal auf diese Diskussion, da hat der seine Masche auch schon abgezogen. Die Debatte wird eröffnet mit "jetzt bauen wir mal den ganzen Artikel um", hat überhaupt keine Ahnung, ein Riesentext folgt... und am Ende das hier: Dein aktueller Vorschlag ist schlimmer als der vorherige. Jetzt wird richtig alles in einen Topf geschmissen und kräftig umgerührt. Ich habe das Gefühl dass jede weitere Diskussion zwecklos ist. Kein bischen von der Mega-Diskussion kommt bei dir an.--Avron 20:12, 8. Apr. 2011 (CEST) Oh Mann, die Sache hat wirklich System. Absurd, dass wir uns mit ihm hier beschäftigen. ʘχ (Diskussion) 11:43, 6. Nov. 2012 (CET)

Wie armselig; statt die Argumente und Belege zu akzeptieren, forschst du in der Historie - wo es übrigens auch darum gegangen war, dass der Ausdruck für zwei grundverschiedene Begriffe steht - was zuletzt in der Disk auch berücksichtigt wurde. --VÖRBY (Diskussion) 14:14, 6. Nov. 2012 (CET)

Ich habe keineswegs geforscht. Ich wollte bei der Prozeduralen Programmierung was ändern und hab das dann gesehen.

Wir wollen nun aber nicht einfach löschen, was wir geschrieben haben! VÖRBY schrieb nämlich:

Aber auch ich will dir beim 'Schmutzige-Wäsche-Waschen' helfen und darf kurz zwei dich betreffende Kommentare eines im Thema wirklich versierten Kollegen wiedergeben - bevor ich sie hier dann wieder lösche:

"Was manche da absondern [...] lässt mich manchmal an der Frage zweifeln, ob wir eigentlich alle auf dem gleichen Stern bzw. in der gleichen Galaxis leben. Bei einigen korreliert die Heftigkeit ihrer Äusserungen mit ihrer Ahnungslosigkeit."

"... weiß nur, dass dieser ... mit seinen schrägen Ansichten mir erheblich auf die Nerven geht. Irgendwie lebt der anscheinend in einem Parallel-Universum."

Du denkst dir sicher schon, dass ich es sehr bezweifle, dass der von dir als "im Thema wirklich versiert" beschriebene Kollege tatsächlich so versiert ist, nach allem, was ich hier mit dir bisher erlebt habe. ʘχ (Diskussion) 14:43, 6. Nov. 2012 (CET)

no comment. Bleib dir treu auf deinem Stern! --VÖRBY (Diskussion) 18:57, 6. Nov. 2012 (CET)

Mario S., mein Link zu Gabler sollte nur der Einzelnachweis dafür sein, dass M-Code AUCH als Synonym zu M-Programm (und nicht nur als Synonym zu M-Sprache) benutzt wird. Allerdings hast du durch Weiterklicken sogar auch einen Beleg für 'Daten sind Teil des Programms' gefunden.

'Prozedural' ist bei Gabler als Quellsprache gemeint - weil sich hierbei der Quellcode und der Maschinencode bezüglich der Befehlsfolge weitgehend entsprechen. Vielleicht sollte auch abgegrenzt werden zu Sprachen, die von Intepretern in Maschinenbefehle umgewandelt werden. 'Maschinencode' (i.S. M-Progr) ist im Übrigen immer prozedural [6].--VÖRBY (Diskussion) 14:12, 6. Nov. 2012 (CET)

ich habe den eindruck, dass ein wirtschaftslexikon zur beantwortung einer so speziellen frage eher ungeeignet ist. die ausdrucksweise scheint mir zu schwammig und richtet sich wohl auch nicht an informatiker. hat niemand hier ein lehrbuch zu dem thema zur hand? --Mario d 14:39, 6. Nov. 2012 (CET)

Zu welcher Frage jetzt genau? Dass Masch.code ein bisweilen gebrauchtes Synonym für M.programm ist, ist jedenfalls bekannt und wird nicht bestritten. Dass manche Daten Teil eines Masch.programms sind, wird ebenfalls nicht bestritten. Bestritten (und auch bereits sogar widerlegt) wurde, dass immer alle Daten Teil des Masch.programms sind.

Ich möchte jedenfalls bzgl. irgendwelcher Begriffsbestimmungen nochmal Chricho zitieren: Es wäre schlimme Theoriefindung, die darauf basieren müsste, aus dem Wortgebrauch verschiedener Autoren irgendwelche Implikationen über verschiedene Bedeutungen herauszulesen, die wahrscheinlich überhaupt nicht gewollt sind, weil ein sehr präziser Wortgebrauch nicht notwendig war (weil es in den Büchern eben nicht um die Abgrenzung von Maschinencode von was auch immer geht, sondern um ganz andere, konkretere Dinge). ʘχ (Diskussion) 14:47, 6. Nov. 2012 (CET)

Da sind wir ja i.W. beieinander:

• M-Code syn zu M-Progr nicht bestritten: Dann kann diese Aussage auch wieder in den Artikel, möglichst (nach Mario S.) mit Belegen (von Gabler und/oder zB auch [7]
• Daten Teil des M-Codes: Auch hierzu wäre unser Disput mit einem Hinweis 'aus der Welt': Mit 'Maschinencode' wird zum Teil das ganze Ergebnis des Compilierens (Äquiv. des Quellprogramms) bezeichnet wird (dazu 'meine' Quellen), häufig aber auch nur die 'Maschinenbefehle' (Belege ...). --VÖRBY (Diskussion) 18:57, 6. Nov. 2012 (CET)

Die verschiedenen Verwendungen von Maschinencode finden sich in der momentanen Einleitung (erster Satz und dritter Satz). Zu dem Punkt mit den Daten: Die Wikipedia veröffentlicht keine Studien zur Verwendung von Wörtern. Wenn jemand sagt, dass das Ergebnis des Kompilierens Maschinencode wäre, damit aber die ganze ausführbare Datei und insbesondere den darin enthaltenen Maschinencode meint, reicht das nicht, um hier solche Sätze in den Artikel aufzunehmen, sondern ist streng genommen falsch und in der jeweiligen Quelle nur so ausgedrückt, weil es nicht drauf ankam und es sich nicht um Erörterungen des Begriffs Maschinencode handelt. --Chricho ¹ ² ³ 20:14, 6. Nov. 2012 (CET)

Ja, bei genauem Lesen kann man im Einleitungstext diese zweiseitige Synonymbeziehung (Code = Sprache, Code = 'Programmstück') erkennen. Die strittige Aussage zu 'Daten' ist u.a. bei 'siehe auch' in der Kann-Form beschrieben - was meinem o.g. Formulierungsvorschlag ungefähr entspricht. Dass gerade hier im Lemma eine Vielzahl von Synonyme, Homonymen und sonstigen Verwandtschaften auftritt, hätte man dem Leser evtl. deutlicher aufzeigen können, falsch ist der Text aber nicht. So wären wir dann mit der Diskussion durch?! --VÖRBY (Diskussion) 10:20, 7. Nov. 2012 (CET)

Konkrete Fragen zu 3M

Redaktioneller Nachtrag: Die hier für 3M zur Debatte stehende Frage lautet: Sind 'Daten' Teil des Maschinenprogramms/Maschinencods?

3M-Autoren sollten dazu final eine Aussage treffen, ggf. nach Einzeldiskussionen.

In den vorangegangenen Diskussionen waren zahlreiche Teilaspekte immer wieder und mehrfach diskutiert und verargumentiert worden. Ich (VÖRBY) habe schließlich dritte Meinungen angefordert und, damit diese Leute nicht die ganze Diskussion nachvollziehen müssen, die Fragestellung auf die nachfolgenden 3 Teilfragen aufgebrochen. Ein 3M-Autor hatte diese aus den obigen Texten hier eingestellt. 3 JA-Teilantworten ergeben dabei die Antwort JA für die Hauptfrage. --VÖRBY (Diskussion) 10:15, 4. Nov. 2012 (CET)

Die Diskussion wird von den Herren und Damen wohl oder übel nachvollzogen werden müssen. Nicht-Eingeweihte wissen gar nicht, was du mit deinen unpräzisen Fragen überhaupt meinst. Und last but not least: Über Wahrheit kann nicht abgestimmt werden. ʘχ (Diskussion) 10:44, 4. Nov. 2012 (CET)

Ich will da nicht oben reinfriemeln. Die Fragen:

1.Stammen die 'Informationen', die der Lader in dem in [8] auf S. 28 genannten Fall  
als bzw. im 'Datensegment' speichert, aus dem vom  Compiler generierten (und in der ausführbaren Datei
gespeicherten) Maschinenprogramm?

2.Sind die Datenbereiche, die (in bestimmten Architekturen) gemischt mit den Befehlen im Speicher angelegt 
werden, Teil des erzeugten und dann im Speicher stehenden Maschinenprogramms?

3.Ist ein Maschinenprogramm das 'semantische Äquivalent' (so steht es bei 'Compiler') des Quellcodes 
(dessen Instruktionen ebenfalls aus Daten und Befehlen bestehen)?

ANTWORTEN einzelner Benutzer:

• Chricho: 3 mal NEIN, Kommentare siehe hier
• VÖRBY: 3 mal JA, Kommentare siehe hier
• RobTorgel: 20:56, 2. Nov. 2012 (CET)

zu 1: Das Buch hab ich nicht. Also generell: JA, der Maschinencode besteht grundsätzlich aus Instruction-code und Literalen (zur Compile-Time festehende Werte)

Siehe Link weiter oben (09:17, 19. Okt. 2012 (CEST)), jetzt eingefügt: --VÖRBY (Diskussion) 18:14, 4. Nov. 2012 (CET)

zu 2: Eigentlich detto JA. Viele Daten stecken ja auch direkt in den Instructions (Load Immediate)

zu 3: In dieser allgemeinen Formulierung JA

WEITERE Diskussionen zu den Antworten:

Liegt das Problem darin, dass die Gegenmeinung nur Machine-Instructions als "Maschinenprogramm" akzeptiert ? Dann wären auch viele Instructions nur teilweise ein Maschinenprogramm --RobTorgel (Diskussion) 20:56, 2. Nov. 2012 (CET)

Du hast dich wohl nicht hinreichend mit den Details dieser sogenannten Diskussion beschäftigt, sonst würdest du auf die Dinge, die Chricho und ich vorgebracht haben, eingehen und entweder bestätigen oder widerlegen. So aber sind deine Antworten entweder falsch oder sinnlos, weil schon die jeweilige Frage keinen Sinn hat, Gründe siehe oben. ʘχ (Diskussion) 21:16, 2. Nov. 2012 (CET)

Die Antworten von RobTorgel sind durchaus nicht unsinnig. Da allerdings der Fragesteller mit Datenbereichen, Datensegmenten und Daten allerhand Dinge meint, die er durcheinander wirft, sodass je nach Interpretation quasi beliebige Antworten möglich sind, hat das wenig zu bedeuten. Ich stimme RobTorgel zu, dass man sich auf das Grundsätzliche konzentrieren sollte, auf den aus den Instruktionen (in denen eben auch Adressen und Konstanten stehen können) bestehenden Maschinencode. Was in einer ausführbaren Datei alles möglich ist, kann irgendwo zur Abgrenzung Erwähnung finden, es macht allerdings keinen Sinn, darüber zu philosophieren, wann man von einem semantischen Äquivalent sprechen kann, weil etwa Daten zwar in der ausführbaren Datei, nicht aber im Maschinencode stehen oder was das mit der von-Neumann-Architektur zu tun hat (nämlich nichts). --Chricho ¹ ² ³ 22:09, 2. Nov. 2012 (CET)

Nur kurz, da RL fällig: Mit vN oder Harvards hat das da tatächlich noch nix zu tun. Immerhin versucht der Compiler/Linker auch bei vN ja read-only und read-write Bereiche zu trennen.

Was man versuchen sollte abzugrenzen, wäre "ausführbare Datei" und "Maschinenprogramm". Ich vermute, dass ihr das Masch.Prog (nur) als Teil der ausf. Datei seht. Das sind dann Unterschiede in der Sichtweise, wo wir lange streiten können. --RobTorgel (Diskussion) 08:01, 3. Nov. 2012 (CET)

Ebenfalls nur kurz: VN und Harvard ist auch nur ein Nebenaspekt - der so auch in der en:WP steht. Hauptfrage ist 'Daten Teil des Maschinenprogramms?'. Einen Vorschlag, 'verwandte Begriffe' zu erläutern und abzugrenzen, hatte ich schon mal gemacht; wurde abgelehnt.--VÖRBY (Diskussion) 09:35, 3. Nov. 2012 (CET)

Die Antworten von RobTorgel sind durchaus nicht unsinnig. Entweder falsch oder unsinnig, je nachdem, wie man die Fragen interpretieren will. Ich kann es auch gerne nochmal ausführen:

Zu 1. Zuerst kommt ein JA, aber dann folgt eine Einschränkung, die zeigt, dass das JA in Wirklichkeit gar nicht ein JA auf die Frage ist, sondern irgendwas anderes. Zudem steht da das Buch habe ich nicht, so dass die Frage von RobTorgel ohnehin nicht beantwortbar ist.

Zu 2. Dasselbe wie bei 1: Zuerst JA (allerdings nur "eigentlich", was immer das heißen mag), danach wieder eine Einschränkung. Hier ignoriert RobTorgel VÖRBYs Wortwahl "Datenbereiche", die mehr beinhaltet als nur irgendwelche Literale, die vom Compiler direkt in den Code geschrieben werden. RobTorgel bezieht sich mit seiner Antwort ausschließlich auf den Fall, wo Literale direkt im Code stehen, der aber völlig unstrittig ist, siehe auch meine Beispiele oben.

Zu 3. RobTorgels Antwort in dieser allg. Formulierung JA ist gerade falsch. Ausgerechnet in der allgemeinen Formulierung gilt das nicht. Nur in Spezialfällen gilt es. ʘχ (Diskussion) 10:38, 3. Nov. 2012 (CET)

Ist mir klar, dass ein Anwendungsentwickler auch nach Jahrzenten nicht unbedingt ein guter Theoretiker ist. Meine Meinung hab' ich gesagt. Da die "ausführbare Datei" als Output des Compiler/linkers die Verwendung und Inhalte der zugewiesenen Speicherbereiche vollständig beschreibt bzw definiert, halte ich eine Auseinanderdividieren von OpCode und "Daten" für willkürlich. So, that's it.

Eigentlich typische Aufgabe der WP, Begriffe zu erläutern ? --RobTorgel (Diskussion) 10:59, 3. Nov. 2012 (CET)

So, hiermit kann man arbeiten: Da die "ausführbare Datei" als Output des Compiler/linkers die Verwendung und Inhalte der zugewiesenen Speicherbereiche vollständig beschreibt bzw definiert, halte ich eine Auseinanderdividieren von OpCode und "Daten" für willkürlich.

Das ist genau der Punkt, um den es ging. Wie ich oben auch erläutert habe, ist in der Tat die ausf. Datei insgesamt ein semantisches Äquivalent. Nun geht es aber speziell um das Maschinenprogramm, das in der ausf. Datei enthalten ist. Was das ist, ist auch klar, nämlich ein in Maschinensprache geschriebenes Programm. Genauso, wie ein C-Programm ein in C geschriebenes Programm ist. Daraus folgt Chrichos und mein Standpunkt unmittelbar. ʘχ (Diskussion) 11:44, 3. Nov. 2012 (CET)

Auch im C-Programm besteht das Quellprogramm (der Quelltext / -Code) i.W. aus Befehlen und Datendeklarationen. Wäre es ohne die Datendefinitionen vollständig? Nein. Daraus folgt mein auf den genannten Quellen (u.a.) basierender Standpunkt. --VÖRBY (Diskussion) 12:53, 3. Nov. 2012 (CET)

Der Punkt ist gerade, dass je nach Situation Daten aus dem C-Programm (oder welche Sprache auch immer) nicht im Maschinenprogramm, sondern separat davon abgelegt werden. Wo ist bloß das Problem? Ich habe das auch oben mit den Listings belegt. Und aus deinen Quellen geht das gar nicht hervor, das behauptest du nur. ʘχ (Diskussion) 12:58, 3. Nov. 2012 (CET) Korrekturen: ʘχ (Diskussion) 12:59, 3. Nov. 2012 (CET) ʘχ (Diskussion) 13:00, 3. Nov. 2012 (CET)

Das ist doch total chaotisch: Was ist denn 'separat davon' Wo ist das? Das 'M-Programm' (oder -Code) entsteht aus dem Quellcode, wird zunächst in einer ~ausführbaren Datei gespeichert und zur Ausführung in den Speicher geladen. "Wo ist nur das Problem?"

In deinen Listings hat nur das Pgm 1 'Daten' (die Konstante), das Pgm 2 hat keine (und ist deshalb als Beispiel ungeeignet). Meine Belege - siehe 12:31, 30. Okt. 2012 (CET) - ergeben ausnahmslos, dass 'Befehle und Daten' im Maschinenprogramm enthalten sind. Da ich keine Luste habe, das alles noch X-mal zu schreiben, diskutiere ich jetzt nur noch mit 3M-Autoren - wenn diese das anfragen. --VÖRBY (Diskussion) 10:04, 4. Nov. 2012 (CET)

Es ist mal wieder soweit: Die 'Spezialisten' sagen auch 3M-Autoren (RobTorgel hat richtig erkannt, dass es hier begriffliche Unterschiede gibt), was richtig und falsch ist. Richtig motivierend, bei der WP weiter mitzuarbeiten. Allerdings: Es geht tatsächlich nicht um die 'Immediate'-Literale im M-Befehl, sondern um alle anderen Formen von Daten (Cricho nennt das oben 'Durcheinanderwerfen)', die man in einem Pgm definieren / benutzen kann (siehe vorheriges Kapitel). Im Beispielpgm 2 sind solche nicht vorhanden - ein m.E. sehr theoretischer Fall. Zum Kommentar 3. von Ox: Was ist das für eine 'Denke', dass ein Programm nur 'in Spezialfällen' Datendefinitionen hat / braucht? --VÖRBY (Diskussion) 11:35, 3. Nov. 2012 (CET)

Das ist nicht die "Denke" und auch nicht meine Aussage. Das hat sogar mit meiner Aussage nicht mal ansatzweise was zu tun. ʘχ (Diskussion) 11:44, 3. Nov. 2012 (CET)

Hier wird auch definiert (->speziell), wenn auch nicht exklusiv "Maschinenprogramm". Ich seh' mich jedenfalls noch weiter um --RobTorgel (Diskussion) 18:51, 3. Nov. 2012 (CET)

Hier taucht der Begriff "ausführbares Maschinenprogramm" auf. --RobTorgel (Diskussion) 18:57, 3. Nov. 2012 (CET)

M-Code vs M-Sprache

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 10:51, 7. Nov. 2012 (CET)

Maschinencode und Maschinensprache werden häufig als Synonyme benutzt und hier im Artikel auch als solche beschrieben. Abweichend hiervon können die beiden Ausdrücke jedoch etwas gänzlich anderes bedeuten - was schon für 'Maschinencode' selbst auch der Fall sein kann. Unter anderem war dies in der Vergangenheit häufig der Grund für Missverständnisse in Diskussionen.
Ich schlage deshalb vor, für die beiden Ausdrücke getrennte WP-Artikel zu führen. Hier in 'Maschinensprache' sollte das erhalten bleiben, was der Bedeutung 'Sprache' (i.S. von Struktur, Syntax etc.) entspricht, M-Code (bisher Weiterleitungsseite) erhält Teile der hier bisher geführten Texte, entsprechend angepasst. In beiden Artikeln wird (per Link) darauf hingewiesen, dass die Ausdrücke auch als Synonyme benutzt werden. Bereits vorhandene Links müssen deshalb nicht angepasst werden. Gibt's dazu Meinungen? --VÖRBY (Diskussion) 13:45, 22. Okt. 2012 (CEST)

Jo, gibt’s. Ich schlage vor, dass sein zu lassen, solange es keine Belege für eine solche begriffliche Trennung gibt. Grüße --Chricho ¹ ² ³ 13:47, 22. Okt. 2012 (CEST)

In der schon oben genannten Quelle ('Die Assemblersprache der intel 80x86-Prozessoren') heißt es u.a. auf S.9: Wenn dann alle Aktionen als Maschinenbefehle formuliert sind, nennt man dieses Programmstück Maschinencode. Unser Maschinencode sieht dann so aus:

A1 00 2A 8B D8 C1 E0 02 03 C3 40 A3 00 28

Das bedeutet, hier ist nicht von einer 'Sprache' die Rede sondern von einem 'Programmstück', also von etwas, das konkret erzeugt wird. Ergänzend dazu kann man natürlich sagen, dieses Programmstück sei 'in Maschinensprache' formuliert/notiert. 'Maschinencode' (in diesem Sinn) gehört rein linguistisch zu einer anderen Wortkategorie und ist deshalb - hier - kein Synonym für 'Maschinensprache'. Zum Vergleich wird auch niemand sagen, dass ein Schriftssteller 'Deutsch' produziere, vielmehr schreibt er einen Roman - vielleicht 'in Deutsch' als Sprache. Oder: Ein Insertbefehl auf die Festplatte erzeugt auch keinen 'EBDCID-Code', sondern einen 'Datensatz' (in EBCDIC-Code). Nur wenn 'Maschinencode' auch in der Bedeutung 'Syntax etc.' auftritt, kann das Wort als Synonym zu M-Sprache gelten. Aber dieser Ausdruck wird eben auch in anderer Weise benutzt und verstanden.

Alternativ zu zwei Artikeln könnte man den Artikel inkl. M-Code ausdrücklich als auf den Aspekt 'Sprache' bezogenes Lemma belassen, müsste aber dann darauf hinweisen, dass der Ausdruck auch in anderer Bedeutung verwendet wird. Vielleicht die bessere Lösung. Danke für deine 'Beleg-Anregung'. --VÖRBY (Diskussion) 18:03, 22. Okt. 2012 (CEST), Bsp ergänzt: --VÖRBY (Diskussion) 08:28, 23. Okt. 2012 (CEST)

Im Einleitungskapitel die unterschiedliche Bedeutung ergänzt. --VÖRBY (Diskussion) 11:11, 25. Okt. 2012 (CEST)

Wurde zwischenzeitlich wieder entfernt, Doppelbedeutung wird indirekt im Einleitungstext sichtbar. --VÖRBY (Diskussion) 10:51, 7. Nov. 2012 (CET)

Abschnitt Maschinenprogramm

Auf dateilosen Systemen, wie beispielsweise [...] befindet sich das Maschinenprogramm oft unveränderbar im ROM

Eigentlich hat das mit "dateilos" und "System" nicht unbedingt zu tun, und "unveränderbar" ist (Flash) auch nicht ganz treffend. Vorschlag, wenn man die µController nicht unbedingt erwähnen will:

„Teile des Maschinenprogramms (z.B. ein Bootloader) befinden sich oft permanent im ROM“

Ist nur ein Vorschlag --RobTorgel (Diskussion) 11:09, 24. Jan. 2013 (CET)

Dieser Abschnitt wurde i.Z. mit dem Auflösen des Siehe-auch-Abschnitts geschaffen. Mein Vorschlag: "Bei vielen 'eingebetteten (embedded) Systemen' oder Mikrocontrollern befindet sich das Maschinenprogramm oder Teile davon, z. B. ein Bootloader meist permanent im ROM." --VÖRBY (Diskussion) 11:29, 24. Jan. 2013 (CET)

Änders doch einfach. Ich würde nur den Schwerpunkt jedoch nicht zu sehr auf PCs legen. 90% der Prozessoren (in denen Maschinenprogramme vorkommen) sind eingebettete Controller, allein 50 Stück im Auto, dann in Kaffeemaschinen, Fernsteuerungen, Handies, Rolladensteuerungen etc. Da wird das Programm in der Produktion eingebrannt und bleibt dann bis zum Elektroschrott unverändert. --Siehe-auch-Löscher (Diskussion) 11:34, 24. Jan. 2013 (CET)

Gut, Ich hab Vörby Vorschlag aufgegriffen und geändert. @Siehe-auch-Löscher: Man sieht's dem Lemma nicht an, aber da steckt Pfeffer drin *g*. Ohne Disk ändere ich da nur Typos, ich will ja noch länger leben --RobTorgel (Diskussion) 11:54, 24. Jan. 2013 (CET)

"bleibt bis zum Elektroschrott unverändert" stimmt nicht so allgemein, bei vielen Geräten wie z.B. den meisten Handys, aber auch vielen Digitalkameras, Festplattenrekordern, blu-ray-Player, Fernsehern und vielen anderen Geräten ist ein Firmware-Update möglich, auch wenn natürlich nicht jeder Benutzer diese Möglichkeit nutzt. --MrBurns (Diskussion) 16:18, 24. Jan. 2013 (CET)

Das ist richtig. Meine Aussage war auch nicht allgemein, sondern bezog sich auf 90% Prozessoren. Der Prozentsatz ist geraten. Du kannst ja mal durchzählen wieviele Prozessoren Du in Deinem Hauhalt, Auto, Computer oder Skijacke findest, und bei wieviel Du die Firmware updaten kannst. So genau weiß ich auch nicht wo echte Maschinenprogramme ablaufen, also Geldkarte, RFID, Autoschlüssel, Computermaus, Fahrradkilometerzähler. --Siehe-auch-Löscher (Diskussion) 17:07, 24. Jan. 2013 (CET)

µC sind heutzutage in jeder Büroklammer. Aber: Die Hardware muss auch für In-Circuit-Programming ausgelegt sein --RobTorgel (Diskussion) 17:13, 24. Jan. 2013 (CET)

(BK) Sehr einfache elektronische Geräte wie z.B. Autoschlüssel, Fernbedienuzngen, etc. sind oft "hard-wired", d.h. sie enthalten kein Programm im eigentlichen Sinn, sondern alle Funktionen sind allein durch den Aufbau der Hardware bestimmt. Daher statt nach dem Prinzip Eingabe-Algorithmus-Ausgabe ist jeder Eingabe schon durch die Hardware eine Ausgabe zugeordnet, Software und Firmware sind daher überflüssig und können auch nicht eingesetzt werden, da diese Geräte keinen Programmspeicher (bzw. in ganz einfachen Fällen so wie z.B. bei einer Fernbedienung, die hard-wired ist, garkeinen Speicher). "In-Ciruit-Programmierung" würde ich nicht als Programmierung im eigentlichen Sinne sehen, da eben die Funktion schon durch die Hardware vorgegeben ist und es daher kein Programm im eigentlichen Sinne gibt, sondern eben eine fixe Anordnung von elektronischen Elementen, auch wenn einige Arbeitsschritte in der Entwicklung dem Aufgabengebiet eines Programmierers entsprechen. --MrBurns (Diskussion) 17:24, 24. Jan. 2013 (CET)

Hallo, interessante Diskussionen! Ich denke aber, für den Artikel HIER genügen die derzeitigen Formulierungen und ich denke, sie sind auch nicht falsch. --VÖRBY (Diskussion) 17:41, 24. Jan. 2013 (CET)

Der Meinung bin ich auch, da man Elektronik, die hard-wired ist üblicherweise nicht als Prozessor bezeichnet. Die weit verbreitete Annahme, in jedem modernen elektronischen Gerät ist ein Prozessor, dürfte falsch sein. --MrBurns (Diskussion) 17:46, 24. Jan. 2013 (CET)

Dann sind wir ja Eins. Btw: Das Laden eines Programms in einen Controller nennt man (leider) auch "programmieren", ist halt so, das sollte uns aber hier egal sein. --RobTorgel (Diskussion) 19:17, 24. Jan. 2013 (CET)

Ich hab mich mit hard-wired vorher eigentlich auf Controller bezogen, die eben garkein Programm im herkömmlichen Sinn gespeichert haben und auf die daher auch nichts geladen wird, sondern wo die Funktion vollständig durch die elektronischen Elemente ("Bauelemente") wie z.B. Transistoren bestimmt ist, auf die wird dann nichts geladen, sondern sie sind direkt anch der Fertigung einsetzbar. --MrBurns (Diskussion) 19:30, 24. Jan. 2013 (CET)

Alles klar, hab ich auch so verstanden. --RobTorgel (Diskussion) 19:42, 24. Jan. 2013 (CET)

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 08:50, 1. Mär. 2013 (CET)

Grafik zu Maschinenprogramm

ursprünglich hier gezeigt (mit Bildunterschrift: <<Datei:Programmcode.png|600px|right|'Maschinenprogramm', Begriffszusammenhänge und im Sprachgebrauch auftretende Synonyme>>. Auf Aufruf reduziert: --VÖRBY (Diskussion) 08:50, 1. Mär. 2013 (CET)

Die nebenstahende Grafik - jetzt nur noch HIER als Aufruf eingestellt: (Datei:Programmcode.png|miniatur|Der Begriff 'Maschinencode' und seine Zusammenhänge - inkl. im Sprachgebrauch auftretende Synonyme) - kann die Zusammenhänge und auch die vielfältig vorkommenden Synonyme aufzeigen. Was haltet Ihr davon, sie im Artikel aufzunehmen? --VÖRBY (Diskussion) 12:54, 29. Jan. 2013 (CET); Grafikaufruf nur noch als Text: --VÖRBY (Diskussion) 10:18, 1. Feb. 2013 (CET)

Habe nochmal geringfügig modifiziert und in den Artikel eingestellt.--VÖRBY (Diskussion) 10:18, 1. Feb. 2013 (CET)

Was ins Auge springt: Java und BASIC werden in ihrem Leben normalerweise nie zu Maschinencode, sondern allenfalls zu einem Zwischencode, der von einem Interpreter ausgeführt wird. Der Maschinencode des Interpreters bleibt durch das Programm unverändert. --Siehe-auch-Löscher (Diskussion) 11:15, 1. Feb. 2013 (CET)

Danke für das Feedback. Man kann aber in einer solchen Grafik nicht alle Varianten berücksichtigen; das war schon mal bei Compiler ein sehr großes Diskussionsproblem. Ich hatte mir das bei JAVA schon überlegt und deshalb den Interpreter mit reingenommen, das hielt ich für besser als JAVA ... wegzulassen. Das Wesentliche sollte aber doch passen. Ich sollte vielleicht den Pfeil zum Internen Speicher nicht vollständig bei 'Maschienprogramm' beginnen lassen, sondern irgendwo zwischen 'Zwischencode' und 'Maschienprogramm'. Unverändert bleibt der Code beim Ausführen ja wohl immer - außer im Hauptspeicher, wo zB Variable, Datenstrukturen etc. immer bearbeitet und verändert werden. Ich kann gerne die Grafik nochmal anpassen - aber sie darf halt nicht zu kompliziert werden. Gruß von --VÖRBY (Diskussion) 12:31, 1. Feb. 2013 (CET)

Der Maschinencode, den der Prozessor bei Ablauf eines BASIC-Programms zu Gesicht kriegt, hat mit dem BASIC-Programm nichts zu tun. Es ist nur der Interpreter. Daher hat BASIC mit Maschinensprache im Grunde nichts zu tun und JAVA auch nicht. Wenn man das Bild entsprechend vereinfacht wäre es auch verständlicher. Alternativ könnte man dann nochmal dasselbe Bild für JAVA, also Bytecode machen und für reine Interpreter. --Siehe-auch-Löscher (Diskussion) 12:56, 1. Feb. 2013 (CET)

Genau das war das Problem bei der Compiler-Diskussion: Jede Entwicklungstechnologie arbeitet diesbezüglich irgendwie anders. Mehrere Grafiken HIER wären mir aber zu viel, im Wesentlichen wollte ich eigentlich die Synonyme in einem Begriffsmodell darstellen - weil das oft und auch HIER schon zu Diskussionen geführt hatte.

Zu Basic (es gibt viele Dialekte und Arbeitsweisen!): Auch hier gibts i.d.R. Zwischencode. Der Prozessor 'sieht' dabei natürlich nur den von einem Interpreter (woraus auch immer) erzeugten Befehlscode - wie der geknickte Pfeil rechts zeigen soll. Die Linie von 'Programmcode' (bisher von 'Maschinencode') nach 'interner Speicher' wäre also allgemeingültig. Zusätzlich könnte man auch 'Maschinenprogramm' gestrichelt darstellen. Rausnehmen möchte ich diese Varianten/Beispiele aber nicht, sonst wäre das unvollständig. Wird schon! --VÖRBY (Diskussion) 15:58, 1. Feb. 2013 (CET)

Übrigens noch ein technischer Hinweis: Solche Grafiken sollten wenn möglich in SVG erzeugt werden, damit sie, dem Wiki-Prinzip folgend, von allen Autoren verändert werden können, siehe Wikipedia:WikiProjekt SVG. --Siehe-auch-Löscher (Diskussion) 16:38, 1. Feb. 2013 (CET)

Danke, SVG kann ich nicht erzeugen, mir wurde mehrfach PNG empfohlen.

Eine überdenkenswerte Alternative zur Darstellung wäre: Die Grafik stellt den 'Normalfall' (?) dar, also mit 'Maschinenprogramm', auf das abweichende Handling bei Interpretersprachen wird nur verbal hingewiesen. Dann wird die Grafik auch sehr viel einfacher. Bitte nochmal kurz Feedback. Danke. --VÖRBY (Diskussion) 16:58, 1. Feb. 2013 (CET)

Make it simple. Mit allen Details und Möglichkeiten klopfen dir zwar alle Insider auf die Schulter, aber der Laie, für den das ja ist, blickt nicht durch.

Btw: Auf VMS halten wir mal einen Basic-Compiler. Es geht eben alles auch anders. --RobTorgel (Diskussion) 19:11, 1. Feb. 2013 (CET)

Danke. Ja, da gibt es viele Unterschiede, abhängig von den verwendeten Entwicklungstechnologien. Nochmal: Meine Absicht war in erster Linie, die (viel diskutierten) Synonyme über ein Begriffsmodell zu zeigen. Das sollte auch einfacher machbar sein - und mit ein paar verbalen Hinweisen 'relativiert' werden können. --VÖRBY (Diskussion) 11:01, 2. Feb. 2013 (CET)

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 08:50, 1. Mär. 2013 (CET)

Grafik-Formate

(entstanden in #Grafik zu Maschinenprogramm)

@Siehe-auch-Löscher: Wieso sollten SVG-Grafiken leichter bearbeitbar sein als Rastergrafiken? PNG z.B. kann man ja z.B. mit einfachen Bildbearbeitungsprogrammen wie MSPaint bearbeiten, SVG nicht (übrigens gilt das auch für viele aufwändigere Bildbearbeitungsprogramme wie z.B. Photoshop). Außerdem ist das SVG-Format ja relativ neu, daher von älteren Programmen wird es generell nicht unterstützt. Gut, man kanns noch immer in einem Texteditor bearbeiten, aber das ist wohl kaum einfacher als in einem einfachen Bildbearbeitungsprogramm, das wohl fast jeder Benutzer hat, die Linien und Rechtecke zu zeichnen + die Beschriftung vorzunehmen (beim manuellen Editieren von SVG dürfte es vorallem mühsam sein, die richtigen Koordinaten zu finden). SVG hat sicher Vorteile gegenüber Rastergrafiken (vor allem bei der Skalierung), aber die einfachere Editierbarkeit gehört wohl eher nicht dazu. --MrBurns (Diskussion) 12:48, 2. Feb. 2013 (CET)

Hallo, die von mir neu hochgeladene Version 3 enthält angeblich einen Fehler und wird deshalb nicht angezeigt. Wer hat dazu eine Idee? Sind wir damit doch bei der Formatdiskussion zu Grafiken? --VÖRBY (Diskussion) 13:28, 2. Feb. 2013 (CET)

Jetzt ok, hatte wahrscheinlich ein falsches Datenformat hochgeladen. Inhaltlich: Sachverhalt 'Interpreter' jetzt nur noch verbal angedeutet. --VÖRBY (Diskussion) 13:38, 2. Feb. 2013 (CET)

@MrBurns: Versuch doch in PNG mal die Texte zu ändern. Vörby hat diese Grafik ja sicher nicht als PNG erstellt, sondern in einem Vektorformat wie Powerpoint etc. Ändern kann nur der, der auch die Originaldatei hat. Leider ist SVG das einzige Vektorformat, das Wikipedia kennt, auch wenn es nur wenige Programme editieren können. Die Grafik könnte irgendwann in der Kategorie:Datei:In SVG konvertieren (Diagramm) landen und dann muss auch Vörby ein SVG-Programm verwenden um die Grafik zu ändern. --Siehe-auch-Löscher (Diskussion) 15:54, 2. Feb. 2013 (CET)

Ja ihr beiden, ich glaube schon, dass es hier ein grundsätzliches Wikipedia-Problem gibt. Ich habe schon viele PNG-Dateien (konvertiert aus PPT oder einem Prozessmodell-Tool) hochgeladen; die kann keiner außer mir ändern. Was wenn es mich mal (in der WP) nicht mehr gibt??? Andererseits hätte ich meine Bedenken, ob jeder in jeder Grafik rumfummeln darf. Da sollte es schon irgendwelche Kriterien geben, die über die Editrechte von Text hinausgehen. Wie gesagt: Grundsätzlich offene Baustelle. --VÖRBY (Diskussion) 17:35, 2. Feb. 2013 (CET)

Die Bilder dürfen üblicherweise auch von anderen weiterverwendet und verändert werden, siehe Hilfe:Bildertutorial/2 Bildrechte. SVG ist immer etwas Frickelei. Probier beispielsweise mal die Bilder nach pdf zu drucken, öffne Sie dann mit Inkscape und speichere sie als SVG. Oder erstelle Sie direkt mit Inkscape. Das ist etwas gewöhnungsbedürftig, aber nach einer Weile kommt man schon damit zurecht. --Siehe-auch-Löscher (Diskussion) 18:47, 2. Feb. 2013 (CET)

Das Weiterverwenden und Ändern verstehe ich so, dass diese Datei downloaded und dann benutzt/verändert werden kann. Das betrifft aber wohl nicht das Recht, die Dateien in WP durch Jedermann zu ändern. Dazu bräuchte es einen (mir derzeit noch nicht bekannten) Lösungsansatz, der sowohl die technische als auch die lizenzrechtliche Seite abdeckt. Dein Link sagt dazu nichts.

Zu privaten Tools: Ich will mir da nicht einen "Zoo" halten. Offizielle Lösungen in WP wären hier zweckmäßig. --VÖRBY (Diskussion) 09:48, 3. Feb. 2013 (CET)

Den Text bei einer Rastergrafik ändern in MSPaint ist bei einem einfarbigen Hintergrund einfach: zuerst "löscht" man man den alten Text (das geht so: man wählt al Hintergrundfarbe die Farbe aus, die der bereits vorhandene Hintergrund hat, dann markiert man den Text mit einem Rechteck und drückt die Entf-Taste) mit einem Rechteck, das die selbe Farbe hat wie der Hintergrund, dann erstellt man ein neues Textfeld, postioniert es an der richtigen Stelle und schreibt seinen Text rein. Der einzige Nachteil ist, dass man den Text nachdem man aus dem Textfeld raus ist nicht mehr ändern kann. Wenn man also nicht noch mal von Vorne anfangen will, sollte man sich vorher überlegen, was man schreibt. Bei professionelleren Bildbearbeitungsprogrammen ist es aber oft so, dass der Text erst beim Speichern eingebunden wird und daher vorher noch editierbar ist. Ein weiterer Nachteil der vorherigen Methode ist es natürlich, dass wenn man nicht weiß, was der Ersteller für eine Font und Schriftgröße verwendet hat, entweder herumprobieren muss, bis mans erraten hat oder eben alle Texte neu schreiben, wenn man das einheitliche Schriftbild bewahren will. Daher die Texte ändern könnte bei SVG tatsächlich einfacher sein, wenn man nicht auch sonst noch was anpassen muss. Aber insgesamt ist das Bearbeiten von PNGs wohl in den allermeisten Fällen unkomplizierter und weniger Arbeit als SVGs manuell mit einem Texteditor zu bearbeiten. --MrBurns (Diskussion) 19:13, 2. Feb. 2013 (CET)

Man bearbeitet SVG üblicherweise nicht mit einem Texteditor, sondern mit Inkscape oder einem Grafikprogramm, das SVG importieren und exportieren kann. --Siehe-auch-Löscher (Diskussion) 12:56, 3. Feb. 2013 (CET)

Ja klar, aber so ein Programm haben wahrscheinlich die meisten Wikipedia-User nicht, irgendein Bildbearbeitungsprogramm hat aber fast jeder. --MrBurns (Diskussion) 17:37, 3. Feb. 2013 (CET)

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 08:50, 1. Mär. 2013 (CET)

Verständnisfrage

Moin! Es hat zwar nicht direkt etwas mit dem Artikel zu tun und hier ist auch kein PC-Forum, aber.... ► Frage 1: Programme, die in einer Assemblersprache geschrieben wurden, sind doch (bei geübten Programmierern) in der Regel kleiner und schneller als welche, bei denen C, C++, Java etc. verwendet wurde. Was ist mit Programmen, die direkt in Maschinencode verfasst wurden? Sind die auch kleiner und schneller als "Assemblerprogramme" oder spielt das dann keine Rolle mehr? ► Frage 2: "Assemblerprogramme" sind also kleiner und schneller als "Hochsprachenprogramme" und brauchen weniger Festplattenkapazität bzw. Prozessorleistung. Aber verbrauchen z.B. 3D-Spiele oder Bildbearbeitungssoftware, die in Assemblersprache verfasst wurden, auch weniger Arbeitsspeicher und Festplattenkapazität? Danke! 88.134.37.238 11:59, 2. Jun. 2013 (CEST)

Servus! Ja, ASS-Programme können deshalb kleiner sein, weil höhere Programmiersprachen i.A. mehr Maschinenbefehle erzeugen. In Maschinencode programmierte Programme wären grundsätzlich nicht kleiner als aus ASS-Code erzeugte zumindest im Wesentlichen - weil auch ein Assembler gewisse Codeteile erzeugt, die zB ein Mensch nicht erzeugen würde oder müsste. Aber in Maschinensprache wird heute niemand mehr programmieren, genausowenig wie jemand - zum Vergleich - mit Hammer und Meisel ein Haus bauen würde/könnte; denn die höheren Sprachen entlasten den Programmierer in vielen Dingen, während dem Speicherplatz (intern und auf Platten) und meist auch der Rechenzeit in der Regel keine derart hohe Bedeutung mehr zukommt wie früher, wo z.B. der ganze Hauptspeicher (in dem das Betriebssystem und Anwenderprogramme laufen mussten) nur 16 oder 32 KB groß war.

Ich bin kein 3D-...Programmierer, kann mir aber nicht vorstellen, dass man sowas in Maschinensprache programmieren könnte, man würde wohl jahrelang daran rumcodieren - und nie fertig werden. Zumal dabei überwiegend Funktionen benutzt werden, die in Programmbibliotheken bereitstehen - die üblicherweise auch über Hochsprachen angesprochen/benutzt werden.

Fazit: Maschinensprachen sind nichts, mit dem Programmierer heute noch direkt arbeiten - aus gutem Grund. Man braucht sie 'nur noch', weil Prozessoren nur diese 'Sprache verstehen'; Compilern etc. leiten den Maschinencode aus dem jeweiligen Code einer höheren Programmiersprache ab. --VÖRBY (Diskussion) 12:38, 2. Jun. 2013 (CEST)

Herzlichen Dank für diese ausführliche Antwort! Das hatte ich nicht erwartet. :-o 88.134.37.238 21:27, 2. Jun. 2013 (CEST)

► Frage 1: Programme, die in einer Assemblersprache geschrieben wurden, sind doch (bei geübten Programmierern) in der Regel kleiner und schneller als welche, bei denen C, C++, Java etc. verwendet wurde. Na ja, dafür muss man schon sehr geübt sein. Optimierende Compiler können einiges rausholen.

Was ist mit Programmen, die direkt in Maschinencode verfasst wurden? Sind die auch kleiner und schneller als "Assemblerprogramme" oder spielt das dann keine Rolle mehr? Zwischen Assemblercode und Maschinencode kann man in der Regel eine 1:1-Korrespondenz herstellen, so dass sich keinerlei Vorteile einstellen.

► Frage 2: "Assemblerprogramme" sind also kleiner und schneller als "Hochsprachenprogramme" und brauchen weniger Festplattenkapazität bzw. Prozessorleistung. Das stimmt so nicht. Ob ein Assemblerprogramm kleiner ist als ein Hochsprachenprogramm, hängt davon ab, a) auf welche Weise man programmiert und b) wie der Compiler konfiguriert ist. Ein Compiler, der hinsichtlich Größe optimiert, könnte ein Assemblerprogramm erzeugen, das kleiner ist als das selbstgeschriebene. Auch muss ein selbstgeschriebenes Assemblerprogramm bei weitem nicht schneller sein als das von einem Compiler erzeugte. Moderne Compiler können teilweise sehr fortgeschrittene mathematische Methoden anwenden, um ein Programm schneller oder kleiner zu bekommen, wodurch sie einem menschlichen Entwickler überlegen sein können. Man muss außerordentlich gut sein, um einem guten Compiler das Wasser zu reichen.

Aber verbrauchen z.B. 3D-Spiele oder Bildbearbeitungssoftware, die in Assemblersprache verfasst wurden, auch weniger Arbeitsspeicher und Festplattenkapazität? Das grundsätzliche Prinzip, um das es hier geht, ist unabhängig von der Art des Programms. Ob du nun ein 3D-Spiel entwickelst oder eine Textverarbeitung oder noch was anderes, ist ganz egal: Es gelten dieselben Regeln. ʘχ (Diskussion) 12:51, 2. Jun. 2013 (CEST)

Aber verbrauchen z.B. 3D-Spiele oder Bildbearbeitungssoftware, die in Assemblersprache verfasst wurden, auch weniger Arbeitsspeicher und Festplattenkapazität? ► Auch an Dich: Herzlichen Dank! Statt "Festplattenkapazität wollte ich aber "Grafikkartenleistung" schreiben. :-/ Wie sieht es damit aus? 88.134.37.238 21:27, 2. Jun. 2013 (CEST)

Die Programmierung von Grafikkarten geschieht ein wenig anders als die Programmierung von PCs:

• Zum einen gibt es die Möglichkeit, dem Grafikkartentreiber Befehle zu geben, z.B. zum Rendern von Polygonen. Diese Befehle gibt man ihm über den Aufruf bestimmter Funktionen. Ob man diese Funktionen jetzt über ein C++-, Java- oder Assemblerprogramm aufruft, ist der Grafikkarte egal. Der Performanceunterschied entsteht hier immer auf der Seite des Hauptprozessors. Das bedeutet, die Wahl der Programmiersprache beeinflusst nicht die Leistung der GPU. Wohl aber kann natürlich ein Java-Programm die CPU stärker belasten als ein Assemblerprogramm, wodurch das Spiel dann insgesamt langsamer läuft.
• Zum anderen gibt es die Möglichkeit, Programme direkt auf der GPU ausführen zu lassen. Das können allerdings nicht beliebige Programme sein, sondern nur sogenannte Shader-Programme, die in einer Shader-Programmiersprache geschrieben sein müssen. Bei Shader-Programmiersprachen gibt es eine Assemblersprache, die en:ARB assembly language, und auch Hochsprachen, z.B. die OpenGL Shading Language. Hier kann also die Wahl einer Sprache wieder relevant sein. Da ich selbst jedoch keine GPUs programmiere, kann ich keine Angaben dazu machen, wie groß die Performanceunterschiede sind. ʘχ (Diskussion) 21:53, 2. Jun. 2013 (CEST)

Was bei deinem kommentar aber nicht erwähnt wird: Shader werden nicht nur verwendet, um allgemeine Programme auf der GPU auszuführen (GPGPU), sondern auch für Teile der Grafikberechnungen (sieht man z.B. heute daran, dass man bei vielen Spielen die "Shader-Qualität" eisntellen kann, was einen erheblichen Einfluss auf die Grafikqualität hat). --MrBurns (Diskussion) 00:37, 4. Jun. 2013 (CEST)

Bzgl. der technischen Details kann ich mich meinen Vorrednern nur anschließen.

Ich würde es jedoch allgemeiner formulieren und zwar: Es ist praktisch nicht möglich, eine hinreichend komplexe Software in Assembler zu erstellen, geschweige denn zu warten (da unvertretbar hoher Aufwand und somit Kosten). Insbesondere C- und C++-Compiler haben eine derartig lange Reifezeit hinter sich, dass von ihnen generierter und optimierter Code praktisch von keinem noch so findigen Assembler-Programmierer auch nur reproduziert werden könnte. Also weder kleiner noch schneller (wobei kleiner nicht gleichzeitig ein Vorteil ist).

Auch gibt es wesentlich mehr potentielle Fehlerquellen bei Assembler, da es einfach mehr Quelltext ist, als eine vergleichbare Anweisung in einer Hochsprache.

Für komplexe Programme braucht es entsprechende Hochsprachen, sonst verliert man sich. Und der Mythos, dass mit Assembler alles schneller ginge, hat nur bei Mikro-Optimierungen Gültigkeit (zB. bei Rechenoperationen in numerischen Simulationen).

Zuletzt ist (optimierter) Assemblercode immer nur für eine bestimmte Plattform geeignet und müsste bereits für einen anderen Prozessor völlig umgeschrieben werden. Wohingegen bei Hochsprachen ein erneutes Kompilieren genügt. --Plankton314 (Diskussion) 23:15, 2. Jun. 2013 (CEST)

Künstliche Intelligenz ist in einem gewissen Sinne meist auch eine numerische Simulation. Die wird man eventuell auch teilweise mit Assembler optimieren, auch in Spielen. Aber insgesamt wird wohl bei modernen Spielen auch bei der Engine (die wohl für die Performance abgesehen von den grafischen Details (Polygonen, Texturen, etc.), die heute nicht mehr programmiert werden, am wichtigsten ist) wenn überhaupt nur ein sehr kleiner Teil in Assembler geschrieben, der Rest in Hochsprache, soviel ich weiß sehr oft C/C++. --MrBurns (Diskussion) 00:37, 4. Jun. 2013 (CEST)

Künstliche Intelligenz ist in einem gewissen Sinne meist auch eine numerische Simulation. Das kann ich nicht bestätigen. Numerische Algorithmen spielen da eher eine untergeordnete Rolle.

Die wird man eventuell auch teilweise mit Assembler optimieren Kann ich auch nicht bestätigen. Egal, ob numerisch oder nicht: Assembler hilft da nicht. Erstens sind die gängigen C++-Compiler bei weitem gut genug (waren sie schon in den 90ern, Watcom C++ und Visual C++ 6.0 waren damals die Klassiker der Spieleentwicklung), und zweitens wäre es es bei den Algorithmen ohnehin nicht schlimm, wenn irgendwo mal ein paar Mikrosekunden verschwendet werden. Die Probleme sind andere (z.B. Komplexität, Parallelisierung). ʘχ (Diskussion) 22:37, 4. Jun. 2013 (CEST)

Ich meinte die künstliche Intelligenz in Spielen, nicht allgemein. Soviel ich weiß funktioniert das heute meist so, dass der PC für verschiedene "Züge" (was das im konkreten Spiel auch immer sein mag) Wahrscheinlichkeiten, dass diese bei bestimmten Annahmen zur Strategie (+eventuell den Fähigkeiten) des Gegners erfolgreich sind (wobei manche KIs auch die Strategie des Spielers auswerten und ihre daran anpassen, insbesondere bei Strategiespielen), berechnet und dann per Zufallsgenerator eine Möglichkeit auswählt, aber eben nicht mit gleichen Wahrscheinlichkeiten, sondern mit den Wahrscheinlichkeiten, die vorher berechnet wurden (natürlich auf eine Summe von 1 normiert). Natürlich könnte er auch einfach den besten Zug nehmen, aber dann wäre das Verhalten der Computergegner vorhersehbar (d.h. in der gleichen Situation reagiert er immer gleich) und das will man meist nicht. Da die Wahrscheinlichkeiten numerisch sind, muss zumindest ein gewisser Teil der Berechnung numerisch sein. Und dafür, dass C/C++ Compiler immer gut beim Optimieren sind gibts genügen Gegenbeispiele auch für moderne Compiler, z.B. Assemblersprache#Vorteile sowie die ersten beiden in diesem Abschnitt verlinkten Quellen (auch wenn diese Beispiele nicht x86 sind). Und auf ein paar µs kommts wohl nicht an, aber sobald sich das in den ms-Bereich akkumuliert, kanns bei Spielen durchaus wichtig sein, z.B. wenn eine Berechnung um 50 ms zu spät fertig ist, dann führt das auf jeden Fall schon zu einem deutlichen Ruckler (50 ms entsprechen 20 fps) und z.B. 10 ms mehr oder weniger können einen deutlichen Unterschied machen (40 ms entspricht 25 fps, bei 25 fps ist für die allermeisten noch kein Ruckeln feststellbar, wenn die 25 fps wirklich konstant sind). Ob Assembler wirklich noch zur Optimierung von Spielen/Engines eingesetzt wird ist eine andere Frage, aber zumindest bei häufig verwendeten Routinen halte ich es prinzipiell für Sinnvoll. Und für eine Engine wird ja auch recht viel Entwicklungsaufwand betrieben (obwohl eine fertige Engine (als binary) wohl meist nur ein paar MB hat), nicht umsonst ist die Zahl der Engines nur ein kleiner Bruchteil der Zahl an Spielen, die es gibt und viele Engines werden von dutzenden verschiedenen Spielen benutzt. --MrBurns (Diskussion) 12:09, 5. Jun. 2013 (CEST)

Hallo, wie ich das sehe, war die ursprüngliche Anfrage sehr viel einfacher gemeint: Wie sich die Größe und Performance von Programmen unterscheidet, abhängig davon, ob in einer Hochsprache, in Assembler oder direkt in Maschinencode programmiert wurde. Die Details zu KI, Parallelisierung und mehr oder weniger mips/fps halte ich deshalb HIER für der Fragestellung nicht mehr angemessen. Die Disk dürfte hier erledigt sein, die neuen Artikelergänzungen zeigen die Unterschiede ASS vs. MaschCode jetzt deutlicher. --VÖRBY (Diskussion) 12:32, 5. Jun. 2013 (CEST)

Dieser Abschnitt kann archiviert werden. --Plankton314 (Diskussion) 13:00, 5. Jun. 2013 (CEST)

"Dateiformate" entfernt

Ich habe diesen Absatz entfernt:

Der Quelltext eines Assemblerprogramms liegt als Textdatei vor, während der Maschinencode als ausführbare Datei eine Binärdatei ist. Ein Größenvergleich Assemblercode vs. Maschinencode ist deshalb nicht sinnvoll möglich.

Erstens haben Programmiersprachen mit dem Thema "Dateiformate" nichts zu tun, und zweitens sind die aufgestellten Behauptungen im Allgemeinen entweder sinnlos oder nicht korrekt:

• Quelltexte liegen immer im Textformat vor, sonst wären sie kein Quelltext. Falls man manuell ein Programm in Maschinensprache schreibt, würde dieses ebenfalls im Textformat vorliegen. Das bedeutet, der Hinweis darauf, dass der Maschinencode binär gespeichert würde, ist sinnfrei an dieser Stelle, da auf einmal die Kategorie gewechselt wird (von Quelltext zu Kompilat).
• Was eine ausführbare Datei ist, bestimmt die Plattform. Das Format der ausf. Datei kann frei gewählt werden. Das kann ein Binärformat sein oder auch nicht. Unter Unixoiden beispielsweise sind ausführbare Textdateien äußerst üblich.
• Ein Größenvergleich zwischen Assemblercode und Maschinencode ist nicht nur sinnvoll möglich, sondern sogar sehr einfach. Die Länge der Programme unterscheidet sich nur um eine multiplikative Konstante. ʘχ (Diskussion) 23:54, 4. Jun. 2013 (CEST)

Also Textdatei zu Binärdatei wie Assembler zu Maschinencode finde ich schon sehr charakteristisch. Vorschlag:

Ein Assemblerprogramms liegt, wie bei Quelltexten üblich als Textdatei vor, während der Maschinencode eine Binärdatei ist.

Übrigens kann ein Maschinenprogramm mit einem HexEditor schreiben oder ändern. --Siehe-auch-Löscher (Diskussion) 08:54, 5. Jun. 2013 (CEST)

Hallo OX: Jedenfalls zeigt dieser Text einen grundlegenden 'Unterschied zwischen Assemblersprache und Maschinensprache'. Ein in Textformat vorliegendes Maschinenprogramm wäre zumindest kein 'Maschinencode', ansonsten schließe ich mich dem Argument 'HexEditor' an. Insofern schließe ich mich dem Vorchlag von Siehe-auch-Löscher, ergänzt um deinen Hinweis zu 'ausführbaren Textdateien' an und setze dessen Textvorschlag wieder ein. Ob der Vergleich von Äpfel mit Birnen sinnvoll ist, mag dahingestellt bleiben; lassen wir's also draußen (es war die Antwort auf eine kürzlich gestellte Disk-Frage).--VÖRBY (Diskussion) 09:17, 5. Jun. 2013 (CEST)

An OX zu 'Unixoiden': Wäre mal interessant, wie ein Unix-System die CRLF-Zeichen einer 'ausführbaren Textdatei' behandelt. Sieht für mich so aus, als ob da noch eine Übersetzung erforderlich ist (die dann den wirklichen Maschinencode erzeugt). Oder in diesen Systemen wird das 'Maschinen-Textprogramm' über eine Art Interpreter ausgeführt.

'Sprache': Hier im Artikel wird nicht nur die 'Sprache', sondern auch der Aspekt 'Code' (sowohl als Format als auch als 'Maschinenprogramm') behandelt. Insofern ist hier die 'ausführbare Datei' genauso relevant wie syntaktische Aspekte. Das hatten wir aber schon mal  :-( --VÖRBY (Diskussion) 09:34, 5. Jun. 2013 (CEST)

Ein Shell-Skript, also eine ausführbares UNIX-Textdatei wird durch einen Interpreter ausgeführt und im Allgemeinen nicht übersetzt. Welcher Interpreter es tun soll steht direkt zu Beginn der Datei im Shebang. Ob es eine Textdatei oder Binärdatei ist, ist UNIX egal. --Siehe-auch-Löscher (Diskussion) 09:52, 5. Jun. 2013 (CEST)

Danke, es gibt also hier bei UNIX kein 'Maschinenprogramm' im allgemeinen Sinn - sondern der Interpreter erzeugt die Maschinenbefehle - die der Prozessor einzeln ausführt. Eine 'ausführbare Datei' kann also 'Code' enthalten, der von einem Interpreter verarbeitet ODER vom Prozessor direkt verarbeitet wird. Ein Unterschied zwischen Ass-Code und Maschinencode (Ass-Sprache und Maschinensprache) würde insofern hier, wie auch bei allen anderen Interpretervarianten, irrelevant sein - weil es den tatsächlichen Maschinencode nur temporär gibt; jedenfalls wäre dieser 'Binärcode'. --VÖRBY (Diskussion) 10:19, 5. Jun. 2013 (CEST)

"Shell-Skript" und "ausführbare UNIX-Textdatei" sind NICHT dasselbe. Ich kann es nur wiederholen: Ob eine ausf. Datei eine Textdatei oder eine Binärdatei ist, ist kein Unterschied. ʘχ (Diskussion) 10:07, 5. Jun. 2013 (CEST)

Könntest Du das bitte erläutern? --Siehe-auch-Löscher (Diskussion) 12:32, 5. Jun. 2013 (CEST)

Welche meiner beiden Behauptungen soll ich erläutern? Ich erläutere jetzt einfach beide:

Ein Shell-Skript ist einfach eine Datei, in der ein Quellcode steht, geschrieben normalerweise in einer der üblichen Sprachen wie z.B. Bash, Python der Perl. Da sind wir uns sicherlich einig.

Eine ausführbare Textdatei hingegen ist einfach nur eine Datei, die als ausführbar markiert ist und deren Inhalt auf Text eingschränkt ist. Da KANN jetzt ein Shell-Skript drinstehen, muss aber nicht. Beispielsweise kann da auch ein C-Quellcode drinstehen, der beim Aufruf der Datei kompiliert und anschließend ausgeführt wird (sowas gibt es). Das ist dann natürlich kein Shell-Skript, sondern ein ganz normales C-Programm, das ganz normal kompiliert und nativ ausgeführt wird.

Du magst nun vielleicht diese Unterscheidung für Haarspalterei halten, ich aber nicht.

Und bezüglich meines Satzes mit den Text-/Binärdateien: Das habe ich unten beim Thema "Dokumentation" ausgeführt. ʘχ (Diskussion) 11:15, 6. Jun. 2013 (CEST)

Das hatten wir aber schon mal  :-( --VÖRBY (Diskussion) 09:34, 5. Jun. 2013 (CEST) Damals ging es um was anderes. Jetzt geht es darum (wie ich bereits oben beschrieben habe), dass der Vergleich zwischen Assemblerprogramm und Maschinencode *keinen Sinn hat*, weil es sich im einen Fall um Quellcode, im anderen um Kompilat handelt. Der Fehler sollte dir klar werden, wenn du Assembler- und Maschinen*sprache* miteinander vergleichst, denn nur so macht es Sinn! Dann ist auch beides Text. Der Abschnitt hat da nichts verloren. ʘχ (Diskussion) 10:11, 5. Jun. 2013 (CEST)

"keinen Sinn": So änlich hatte ich das ja auch formuliert. Wenn jemand gefragt hatte, ob ein Ass-Programm größer ist als ein Maschinenprogramm, dann könnte er dieses gemeint haben - wahrscheinlich aber die Größe des ASS-Pgms als Maschinencode vs. Maschinencode nativ programmiert (was es ja wohl kaum mehr gibt). Ich denke aber, mit dem Weglassen sind wir jetzt auf einer Linie.--VÖRBY (Diskussion) 10:35, 5. Jun. 2013 (CEST)

Finalisierung: Die zeitlich letzten Disk-Beiträge hier (was ausführbare Dateien sind und welches Format sie haben, Shell-Scripte etc) sind insofern irrelevant, als die Diskussion ihren Ursprung in den Unterschieden zwischen Maschinensprache und Assemblersprache hatte. Texte können in einem Maschinenprogramm (~Maschinensprache) zwar auch vorkommen, das sind dann aber keine Kommentare, sondern deklarierte Datenfelder. Insofern hier:

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 21:59, 6. Jun. 2013 (CEST)

Dokumentation ist auch bei Maschinensprache möglich...

...nur halt nicht direkt neben dem Programmcode, auf die sie sich beziehen. Man kann aber z.B. eine Textdatei erzeugen, wo bestimmte Teile vom Programmcode erklärt werden und dazu die Position in der Binärdatei angeben (als Hexadezimaloffset in dem Sinne, dass z.B. 00000100 dem 257. Byte der Datei entspricht). Da auch Hexeditoren diese Adresse anzeigen, ist die Zuordnung eindeutig, es ist nur halt etwas mühsamer zu lesen als wenn man die Kommentare direkt im Quellcode hat (allerdings kann man natürlich in der Textdatei die enstprechenden Maschinencodeschnipsel einbauen, ums schneller lesbar zu machen). Natürlich kann man diese Texte auch direkt in die binary einbauen (einfach als Text, der aber von der Anwendung nie aufgerufen wird), aber das macht wohl keinen Sinn, weils dadurch auch nicht schneller lesbar wird, die binary unnötig aufgeblasen wird und wohl keiner, der nichts davon weis in einer binary nach einer Dokumentation sucht. --MrBurns (Diskussion) 19:41, 5. Jun. 2013 (CEST)

Sicher kann 'man' (?) mit einem entsprechenden Editor (und den erforderlichen Kenntnissen über die Dateistruktur) in jeder Datei alles einbauen. Der Inhalt dieser Datei ist aber dann kein 'Maschinencode' mehr, sondern irgendein 'Mischmasch' - der höchstwahrscheinlich kaum fehlerfrei geladen und ausgeführt werden könnte. Gültig bleibt also: Dass im Ass-Code dokumentiert werden kann, ist ein 'grundsätzlicher' (!) Unterschied zu Maschinencode. Dass man eine zusätzliche Textdatei anlegen kann, gilt ja wohl immer und hat damit nichts zu tun. --VÖRBY (Diskussion) 23:10, 5. Jun. 2013 (CEST)

Der Inhalt dieser Datei ist aber dann kein 'Maschinencode' mehr, sondern irgendein 'Mischmasch Wir kommen hier wieder einmal zu deiner inkorrekten Vorstellung von ausführbaren Binärdateien. Diese Dateien enhalten bei weitem nicht nur Maschinencode, sondern folgen einem ziemlich komplexen Dateiformat. Wenn du den Inhalt einer ausführbaren Binärdatei (z.B. COFF oder ELF) direkt einem Prozessor geben würdest, würde er noch nicht einmal das erste Byte überleben.

Ich betone und wiederhole also noch einmal: JEDE ausführbare Datei muss von einer anderen Software geladen und interpretiert werden, ganz wurscht, welches Dateiformat verwendet wird, deswegen gibt es keinen Unterschied zwischen Text- und Binärformaten.

Es ist sogar überhaupt kein Problem, direkt in eine ausführbare Binärdatei eine solche Dokumentation, von der hier die Rede ist, einzubauen, ohne dass das zu Problemen führt. Wie das geht, kann man sich mit Minimalkenntnissen über Assembler selbst erschließen. ʘχ (Diskussion) 10:16, 6. Jun. 2013 (CEST)

Es gibt durchaus auch ausführbare Dateien, die direkt Maschinencode enthalten, z.B. das COM-Dateiformat in MS-DOS (zu beachten ist das, dass die Dateiendung .COM und .EXE nichts über das Dateiformat aussagt, sondern man Dateien im "EXE-Format" an den Header-Bytes 0x4D5A (MZ in ASCII) erkennt. So hat z.B. die COMMAND.COM in neueren DOS-Versionen, das "EXE-Format"). --MrBurns (Diskussion) 05:24, 8. Mär. 2017 (CET)

Die Diskussion begann i.Z. mit den Unterschieden zwischen der Assemblersprache und der Maschinensprache, wo als einer dieser Unterschiede die 'Dokumentation' genannt ist. Hier jetzt wieder um ausführbare Dateien, Textdateien, Binärdateien (siehe dort) zu diskutieren, halte ich nicht für relevant. --VÖRBY (Diskussion) 13:11, 6. Jun. 2013 (CEST)

Mathematische Berechnungen

... im Bereich von Million, Milliarden, Trillionen bis 10 hoch 9999

Es gibt in Skandinavien eine Eisenbahnstrecke mit geschätzt 2.000.000 Metern von Stockholm nach Narvik (Schweden/Norwegen). Auf dieser Strecke soll ein Eisenbahnzug (Passagiere und Ladung) jeden Meter mit 200 Kilometer pro Stunde zwischen Stockholm und Narvik Fahren. Bei diesem Zug wird also eine Informatik-Software benötigt, die bei jeden Meter Eisenbahngleis , die Daten hat, wo sich der Zug befindet und wie schnell der Zug fährt und um wieviele Kilometer pro Stunde (1000 Meter) der Zug gebremst wird. Das sind zirka 4 mal 2 Millionen mathematische Berechnungswerte in der Zugsoftware. Auf dieser 2.000.000 Meter Strecke eine Richtung fahren derzeit September 2017 bis zu 250 Loks pro Tag in eine Richtung. Theoretisch fahren alle 250 Loks (Autopilot) in einer Reihe auf 2 Millionen Metern. In Stockholm und in Narvik gibt es Halteplätze (250). Mit welcher Berechnungssoftware wird dieses Informatikproblem berechnet und auf Bildschirmen dargestellt (Wolfram Alpha, Bing, Google, Yandex, Baidu)? 195.35.101.1 16:46, 12. Sep. 2017 (CEST)

Jedenfalls ist die Diskussionsseite von einem Artikel die falsche Stelle, um solche Fragen zu stellen. --MrBurns (Diskussion) 18:19, 12. Sep. 2017 (CEST)

Derartige permanent wiederkehrende Berechnungen und Überwachungen gibt es im Technischen Bereich zuhauf, etwa im Flugverkehr. Oder stelle Dir nur vor, was ein selbstfahrendes Auto (in Sekundenbruchteilen und praktisch 'gleichzeitig') berechnen muss. Das ist jedenfalls keine Frage zur Maschinensprache. Tipp: Versuche, das bei der skandinavischen Eisenbahn in Erfahrung zu bringen oder stelle die Frage ggf. in Wikipedia:Auskunft. Hier ERLEDIGT.--VÖRBY (Diskussion) 18:46, 12. Sep. 2017 (CEST)