Diskussion:Assemblersprache/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:Assemblersprache/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Hallo-Welt-Java-Quelltext

Ich fände es sinnvoller wenn hier ein Turbo Pascal-Beispiel oder meinentwegen auch BASIC stehen würde, da die puristischer sind.

 program Hallo;
 begin
     writeln('Hallo Welt');
 end.

(nicht signierter Beitrag von 79.214.98.207 (Diskussion | Beiträge) 20:25, 22. Jan. 2010 (CET))

Sehe ich auch so. So würde die Abgrenzung noch deutlicher visualisiert. Christian A. Schneider 10:34, 25. Jun. 2010 (CEST)

Zustimmung, wird erledigt.

Somit nach 4 Jahren:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:10, 21. Jun. 2014 (CEST)

Alte Diskussion (1)

Wer immer diesen Blödsinn geschrieben hat, Sie haben nicht die geringste Ahnung von der Materie !!!

Was genau ist nicht korrekt? Kritik ist willkommen, kann aber nur qualitätswirksam werden, wenn sie spezifisch ist.

Wer Enzyklopädien zu Müllhalden für Diletanten verkommen läßt, vergewaltigt junge Menschen die nach Wissen streben. Diese Menschen haben ein Recht auf Kompetenz. Ich bezweifle daher den Sinn Ihrer Vorgangsweise, ungeprüfte Artikel ins Netz zu stellen.

 Wer "Diletanten" beschimpfen will, sollte vielleicht vorher die Schreibweise erlernen!? 

Ich finde es schon etwas dreist, dass jemand, der mehrfache Ausrufezeichen benutzt, plenkt und vor allem keine konkreten Änderungswünsche vorträgt, sich berufen fühlt, an der Wikipedia herumzunörgeln. Die Möglichkeit, den Artikel sachlich zu korrigieren, besteht durchaus. Rummaulen kann jeder, Du machst auf mich nicht den Eindruck, als könntest du mehr.

---

Ich habe die Diskussion aus dem Artikel rausgenommen und hier eingefügt. Hier kann man dann weiter diskutieren. Die Diskussionsbeiträge stammen nicht von mir. (--WKr 19:05, 11. Aug 2003 (CEST)):

Solcher Murks gehört (bestenfalls!) ins Archiv:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:11, 21. Jun. 2014 (CEST)

Alte Diskussion (4): Windowsform

Wieviele Codezeilen braucht man ungefähr um eine stinknormale Windowsform zu erstellen? --Jonathan Hornung 18:49, 25. Mai 2005 (CEST)

Die OpenGL-Tutorials bei NeHe (nehe.gamedev.net) enthalten meist auch ASM-Konvertierungen. Vielleicht zeigt Dir das ungefähr den Umfang... 8) -- Markus Moll, 1.8.2005

Was ich noch sagen möchte, es ist fast immer so dass der der mehr Erfahrung hat die besseren Programme schreibt!--84.57.128.226 18:06, 12. Nov. 2010 (CET)

Nichts wie ins Archiv damit...

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:21, 21. Jun. 2014 (CEST)

Frage

Kleine Frage um zu testen ob ich das hier richtig verstanden hab: Könnte man also gaaanz einfach gefasst sagen das Assembler die Dolmetscher zwischen Mensch und Maschine sind?

Joah, würde ich sagen. Man kann Assemblersprache als eine verständlichere Repräsentation des Bytecodes sehen. Und der Assembler (der Compiler) übersetzt die Befehle 1:1 in Bytecode. cljk 16:39, 14. Dez. 2006 (CET)

Na ja... Etwas genauer: Mensch → Maschine: Assemblerprogramm, Maschine → Mensch: Disassemblerprogramm; die beiden sind sozusagen Gegenteile. Aber: In einem Quelltext, den ein Disassembler erstellt hat fehlen u.a. die Kommentare und anderes. Man braucht also zwei „Dolmetscher“ für die verschiedenen Richtungen. --79.230.75.46 00:24, 21. Aug. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:28, 21. Jun. 2014 (CEST)

Hello World Programm

Habe die Fehler im "Hello World" entfernt.

Und einige Kommentare zum Programm hinzugefügt.

Ich hoff es entspricht euren Ansprüchen.

LG Martin M.

--212.33.33.83 14:19, 23. Mär. 2007 (CET)

Das mit dem Fehler entfernt halte ich für ein Gerücht. mW heißt das Datensegment DATA und nicht wie im Beispiel DATEN.--Rotkaeppchen68 01:44, 30. Sep. 2007 (CEST)

Es hieß schon immer und heißt bis heute DATA und nicht DATEN PF20080208

---

To do:

1. Der Quellcode läuft bereits auf einem 8086/8088.
2. Es fehlt der Hinweis darauf, daß man auch ein DOS 2.x-kompatibles Betriebssystem braucht.
3. Es fehlt der Hinweis darauf, daß es sich um MASM-Syntax handelt.
4. Hinweis und Link zu "Red tape"/"Amtsschimmel".
5. Quellcode noch mal für NASM und als .COM-Datei um Newbies zu zeigen, daß es auch mit weniger Quelltext geht?

--213.54.158.83 23:00, 17. Mai 2007 (CEST)

---

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:29, 21. Jun. 2014 (CEST)

Letzter Teil:

Habe AltiVec entfernt, da es in Spielen heute nicht mehr verwendet wird. Weiters habe ich den Hinweis auf Intel-CPUs bei SSE entfernt, da mittlerweile auch alle aktuellen AMD-CPUs SSE (mit kleineren Einschränkungen) beherrschen. --85.127.30.156 02:37, 28. Aug. 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:29, 21. Jun. 2014 (CEST)

Hello World in Assemblersprache

Habe den Abschnitt

Hello World in Assemblersprache (Jasmin)

hinzugefügt. Ich denke dieser Zusatz passt an dieser Stelle. Zum Vergleich ist auch der Java-Quelltext zum Assembler-Quelltext mit hinzugefügt. Jasmin nutzt die Operationscodes bzw. Mnemoniks der virtuellen Java Maschine.

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:35, 21. Jun. 2014 (CEST)

"Hello World"-Beispiele aneinander angepasst, NASM verbessert

Habe mal die "Hello World"-Beispiele umgeordnet (NASM hinter MASM weil beide recht ähnlich sind) und sowohl am MASM- als auch am NASM-Beispiel inhaltliche Verbesserungen vorgenommen:

• MASM:
  • Verbliebene Bezeichnung "DATEN" durch "DATA" ersetzt. (Ich bin aber überzeugt, das hier beides richtig wäre - nur eben keine Mischung aus beidem.)
  • "mov ah, 9" durch "mov ah, 09h" ersetzt. Sonst könnte man denken, dass der MASM den gleichen Befehl aus dem NASM-Beispiel nicht nehmen würde. (Tatsächlich ist es dem Programmierer vorbehalten, was er lieber mag.)
  • Programm mit Int21.4C00 beendet, anstatt nur Int21.4C. Letzteres ließe nämlich den Rückgabewert ("Errorlevel") offen (bzw. würde zufällig immer 24h geben), was man einfach nicht tut. Der Wert 00 bedeutet bei DOS-Programmen für gewöhnlich "Alles in Ordnung" oder "Normal beendet".
• NASM:
  • Komische eckige Klammern bei der ORG-Anweisung entfernt. Hab ich ja noch nie gesehen. (Auch in anderer Leute NASM-Programme nicht.) Die NASM-Dokumentation sagt nichts darüber und verwendet die Klammern nicht, also scheint es ohne Klammern normal zu sein.
  • Label "Hallo" durch "Meldung" ersetzt. Siehe "mov ah, 9" beim MASM-Beispiel. (Außerdem finde ich, dass "Meldung" vielleicht weniger verwirrt als "Hallo".)
  • Programm mit Int21.4C00 beendet. Siehe MASM-Beispiel.
  • Label der Nachricht mit Doppelpunkt abgeschlossen. Bei Labels ohne Doppelpunkt gibt NASM in der Standardeinstellung eine Warnung aus; diese sind also nur als Kompatibilitätsmaßnahme unterstützt.
  • Anführungszeichen und Aufteilung der Nachricht wie beim MASM-Beispiel. Entscheidet am Ende alles der Programmierer.

Ich weiß, dass ich pingelig bin ;) --Estron 22:10, 28. Mär. 2008 (CET)

NASM:

1. Ist beides möglich. So weit ich weiß wird mit den Klammern die Direktive direkt angesprochen und ohne wird in Makro aufgerufen, was das selbe bewirkt (zumindest bei [BITS 16])

4. Bei mir nicht. --217.185.137.83 19:50, 30. Mär. 2008 (CEST)

1. Stimmt wahrscheinlich. Aber bei ORG bewirkt das Benutzer-Makro dann wohl das gleiche wie die "rohe" Direktive, und deswegen wird meistens das Makro verwendet. (Das SECTION/SEGMENT-Macro beispielsweise setzt ja auch noch ein Makro mit dem Namen der neuen Sektion, macht also durchaus etwas anderes.)

4. War mein Fehler. Gibt nur eine Warnung dafür aus, wenn der Doppelpunkt am Ende fehlt und kein Code dem Label folgt. Ist also hier egal. --Estron 14:00, 4. Apr. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:35, 21. Jun. 2014 (CEST)

Ist "Assemblersprache" eine Begriffserfindung?

Ich kann mich nicht erinnern, dass jemand ersthaft von Assemblersprache gesprochen hat. Es heisst immer nur "Assembler". Auch früher (vor ca. 30 Jahren), als Assembler weit verbreitet gewesen ist, ist Assemblersprache nicht verwendet worden. Ich plädierere dazu, den Artikel nach "Assembler (Programmiersprache)" zu verschieben, da der Begriff "Assemblersprache" nicht die korrekte Bezeichnung ist. -- Raubsaurier 13:49, 21. Aug. 2010 (CEST)

"Assemblersprache" sagt mir auch nichts. Ich habe damals in den 80ern auf meinem C16 und C128 mühsam "Assembler" programmiert.--TheRealScot 23:24, 9. Sep. 2010 (CEST)

Da würde ich definitiv zustimmen. Das Lemma sollte imho besser "Assembler (Sprache)" heißen. 93.223.121.49 01:21, 30. Sep. 2010 (CEST)

Ein Assembler (engl. assembler) ist ganz klar ein Programm, das Code kompiliert. Den Unterschied zur Assemblersprache (engl. assembly language), auch als Assemblercode bezeichnet, sollte man schon aufrecht erhalten. Die umgangssprachliche Gleichsetzung/Vermischung beider Begriffe kann man in der Einleitung der Artikel erwähnen. --Doodee 23:53, 25. Nov. 2010 (CET)

Spricht etwas dagegen, in den nächsten Tagen mit dem Verschieben nach "Assembler (Programmiersprache)" zu beginnen? -- Raubsaurier 14:12, 22. Mai 2011 (CEST)

Wenn niemand widerspricht, werde ich am Wochenende verschieben. -- Raubsaurier 21:59, 26. Mai 2011 (CEST)

Naja, der letzte Beitrag war ein Argument für die Trennung von "Assembler" und "Assemblersprache". Wie kann man da fragen, ob etwas gegen das Verschieben spricht?

Zur Frage, ob es Begriffserfindung ist: Nein, siehe hier oder hier, hier, hier (bestätigt auch die Aussage von Doodee) und hier. Was jetzt üblicher ist, ist die eigentliche TF, solange dafür nicht Quellen angebracht werden. --Zahnradzacken 22:23, 26. Mai 2011 (CEST)

möglicherweise einer der in der IT nicht ganz seltenen fälle, wo in lehrbüchern "korrektere" bezeichnungen verwendet wurden als von denen, die tatsächlich damit arbeiteten. "assemblersprache" las ich in wikipedia jedenfalls auch das erste mal. -- ∂ 23:02, 26. Mai 2011 (CEST)

---

Ich muss dazu nochmal 'aufwärmen': Aktuell lautet die Einleitung ist eine spezielle Programmiersprache, welche die Maschinensprache einer spezifischen Prozessorarchitektur in einer für den Menschen lesbareren Form repräsentiert. Jede Computerarchitektur hat folglich ihre eigene Assemblersprache. Das ist doch was falsch dargestellt: Denn die Ass-Sprache (der ASS-Code) ist doch nicht nur eine 'menschengeeignete' Repräsentarion des Maschinencodes, sondern wie bei anderen Programmiersprachen auch zunächst mal Quellcode, der vom Assembler (als Pgm) zu Maschinencode wird; die jetzige Formulierung ließe eine umgekehrte Reihenfolge vermuten. Und 'speziell' ist jede Programmiersprache. --VÖRBY (Diskussion) 09:38, 14. Mär. 2013 (CET)

Naja, mit "repräsentiert" ist wohl gemeint, dass es eine 1:1 Beziehung gibt. Aber es gibt sicher bessere Formulierungen. Mich stört etwas, dass da Prozessor- und Computerarchitektur durcheinandergeschmissen wird. Letzteres (+Betr.System) beeinflußt eigentlich nicht die Assemblersprache selbst, sondern die Statement-Sequenzen, die man braucht, um dieses oder jenes zu erreichen. --RobTorgel (Diskussion) 10:08, 14. Mär. 2013 (CET)

Entwurf für eine neue Einleitung:

Eine Assemblersprache (oft abgekürzt als ASM bzw. asm) ist eine Programmiersprache der Zweiten Generation, die der Maschinensprache (Sprache der ersten Generation) noch sehr nahe steht, jedoch bereits Sprachkonstrukte verwendet, die für den Menschen besser les- und bearbeitbar sind. Jede Computerarchitektur hat ihre eigene Assemblersprache. Umgangssprachlich wird häufig nicht zwischen Maschinensprache und 'Assemblersprache' unterschieden.

PS: Definitionen sind über Google tatsächlich schwierig zu finden; viele Quellen zitieren die Wikipedia. Aus der 2. von Zahnradzacken zitierten Quelle ließen sich evtl. weitere Def-Kriterien ableiten. --VÖRBY (Diskussion) 13:41, 14. Mär. 2013 (CET)

alternativ (mit Beleg): Eine Assemblersprache (aus engl. to assemble = montieren) [, abgekürzt auch mit „Assembler“ bezeichnet,] ist eine maschinenorientierte Programmiersprache. Für jeden Computertyp gibt es spezielle, auf den Befehlsvorrat des Computers [, d. h. seines Prozessors ] zugeschnittene Assembler-Sprachen. Von den Maschinensprachen unterscheiden sie sich [i. W.] dadurch, dass anstelle eines ... Binärcodes die Befehle und Operanden durch leichter verständliche mnemonische Symbole dargestellt sind.

Im Sprachgebrauch werden die Ausdrücke 'Maschinensprache' und 'Assemblersprache' häufig synonym verwendet.

--VÖRBY (Diskussion) 17:46, 14. Mär. 2013 (CET)

Ich habe die Einleitung gem. der angegebenen Quelle umgeschrieben. --VÖRBY (Diskussion) 19:28, 15. Mär. 2013 (CET)

---

Temporär:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:39, 21. Jun. 2014 (CEST)

Vorteile?!

Vllt. ist der Nachteil an Assembler ja, dass es Architektur gebunden ist, aber der Vorteil ist doch, dass es eigentlich dafür meistens Betriebsystem unhabhängig ist, oder? Beim compilieren, werden meißtens ja keine Funktionen eingepackt(wenn man nicht welche reinprogrammiert, oder?) die nur ein bestimmtes Betriebsystem hat (Bsp.: Fenster). Verbessert mich wenns falsch ist. Bin noch relativ Anfänger auf dem Gebiet! (nicht signierter Beitrag von 84.57.128.226 (Diskussion) 18:17, 12. Nov. 2010 (CET))

Nein - Assembler ist ebenso an ein Betriebssystem gebunden, weil auch ein Assemblerprogrammiere das Rad nicht neu definiert und für die Ausgabe auf dem Bildschirm bereits fertige Funktionen verwendet - und diese stammen vom Betriebssystem.

Des weiteren muss der Code das richtige ABI-Format haben. Ein ELF-Binary unter Linux kann nicht unter Windows gestartet werden, das Windows das EXE-Format erwartet.

Assembler ist sogar noch empfindlicher was das System betrifft.Thomas Merbold 14:45, 24. Nov. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:39, 21. Jun. 2014 (CEST)

Unterschiede

Aus dem Artikel geht nicht hervor, weshalb sich bei unterschiedlichen Betriebsystemen die Assemblerprogramme unterscheiden, obwohl die Prozessorarchitektur gleich ist. Soweit ich das verstanden habe, handelt es sich bei Assemblerbefehlen ja direkt um die Opcodes für den Prozessor, warum funktioniert ein Assemblerprogramm für DOS dann nicht 1:1 unter Linux, sofern der gleiche Compiler und Prozessor verwendet wird? --193.83.26.64 09:19, 4. Mär. 2013 (CET)

Meines Wissens ist dazu folgendes zu sagen: Ein Assembler erzeugt zwar überwiegend Maschinenbefehle, aber auch viele Systemaufrufe, z.B. für READ/Write, Bildschirmein-/ausgaben, Timerabfragen, Aufruf von Unterprogrammen u.v.a. Diese Aufrufe sind im ASS-Maschinencode lediglich als Verzweigungen abgelegt, meist zu Routinen des 'Betriebssystems' i.w.S. Zum Teil werden diese Aufrufe 'SVC' genannt, sie geben auch 'Parameter' mit, wobei bestimmte Register auf strukturell/formal exakt defininierte Datenbereiche zeigen müssen. In diesen Systemroutinen (auch Gerätetreiber gehören dazu) laufen dazu dann die tatsächlichen (nicht im Ass-Code enthaltenen) Maschinenbefehle ab, und zwar inkl. Parameterstruktur BS-spezifisch.

Insofern müsste es so sein, dass ein ASS-Programm von einem BS-spezifischen Assembler übersetzt werden muss, nicht nur vom einem prozessor-spezifischen. Die Basisbefehle dagegen (wie ADD, Compare-Varianten etc.) sollten tatsächlich prozessorspezifisch einheitlich sein. Bin selbst auch daran interessiert, ob diese Sicht richtig und vollständig ist. Gruß von --VÖRBY (Diskussion) 08:37, 5. Mär. 2013 (CET)

Vollstens korrekt; vielleicht als Anmerkung: Auf vielen Plattformen darf ein Anwendungsprogramm viele Vorgänge gar nicht selbst erledigen, sondern muss dafür BS-Dienste/Funktionen verwenden.

--arilou (Diskussion) 19:44, 21. Jun. 2014 (CEST)

PS:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 19:44, 21. Jun. 2014 (CEST)

Alte Diskussion (2): 1:1-Abbildung vs. Makro

Die einfache 1-zu-1 Abbildung ist dann u.U. für den Programmierer nicht mehr sichtbar.

Anm: Auch Makroassembler übersetzen 1-zu-1 in Maschinensprache. Lediglich die Bedienung wird durch die Definition von Makros vereinfacht. Diese Makros werden aber durch die entsprechenden Befehle ersetzt, bevor der eigentliche Assembliervorgang durchgeführt wird.

(Dann übersetzen aber auch C-Compiler 1-zu-1 in Maschinensprache, schließlich ist die Programmiersprache letztendlich nur die Bedienung des Assemblers innerhalb des C-Compilers...)

Makroassembler übersetzen insofern 1-zu-1 in Maschinensprache als dass normalerweise genau jeder Assemblerbefehl genau einem Maschinenbefehl entspricht. Die Makros werden vom Präprozessor des Makroassemblers verarbeitet. In einem C-Compiler entspricht ein einzelner C-Befehl egal welcher Granularität mehreren Maschinenbefehlen. Die Aussage, dass jeder Assembler eine 1-zu-1 Abbildung erzeugt, halte ich für korrekt, die Aussage, dass die 1-zu-1-Abbildung in einem Makroassembler für den Programmierer manchmal nicht mehr sichtbar ist, für ebenfalls. Man sollte zudem nicht vergessen, dass es auch C-Compiler gibt, die keine Assembler verwenden, sondern direkt Objektcode erzeugen. --ChristianHujer 20:40, 12. Sep 2004 (CEST)

(Sehr späte Anmerkung...)

So manche C-Anweisung wird zu nur 1 Assemblerbefehl.

Ansonsten stimme ich der Aussage von Benutzer:ChristianHujer zu, auch wenn ich bezweifle, dass es noch einen C-Compiler gibt, der nicht über Assembler geht; schließlich kann er nur dann noch weiter optimieren.

--arilou (Diskussion) 19:21, 21. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:07, 5. Feb. 2015 (CET)

Alte Diskussion (3): Optimierung / Codequalität

Die Aussage "In vielen Fällen können moderne Compiler höhere Programmiersprachen in effizienteren und schnelleren Code übersetzen als ein unerfahrener Assemblerprogrammierer, speziell auf RISC-Prozessoren, die in stärkerem Maß als CISC-Prozessoren von optimierenden Compilern abhängen." halte ich für übertrieben und sogar falsch. Wenn niemand mit RISC-Erfahrung widerspricht, werde ich den Artikel entsprechend abändern. --ChristianHujer 20:40, 12. Sep 2004 (CEST)

  Dem Satz würde ich bis zum Komma zustimmen, aber gerade (neuere im PC) CISC-Prozessoren scheinen
  mir den Anfänger mit seinen riesigen Befehlsumfang zu überfordern, womit dieser ungenutzt
  bleibt. 62.246.48.36 16:06, 31. Jul 2005 (CEST)

Dieser Satz ist absolut korrekt und bestätigt nur meine Erfahrung. Im Compilerbau hat sich sehr viel getan und ein unerfahrener Assemblerprogrammierer, der an die Lösung ebenso herageht wie in einer anderen Sprache - ohn die Vorzüge von Assembler zu kennen und somit zu nutzen - produziert definiv schlechtern Code. Des weiteren: Es gibt heute keine Nicht-RISC-Prozessoren mehr. PF 17.03.2206

Vielleich sollte man dies einmal mit einem Beispiel untermauern. Plakativ geht dies muit der Darstellung des Intel-Dreisprungs im Realmode. Ein IF-Bedingung einer Hochsprache führt zu einem bedingten Sprung. Das dumme eines bedingten Sprunges ist, das er nur 128 Byte weit reicht. Dies führt z.B. bei einem Vergleich auf 0 zu folgendem Konstrukt:

label:
    ...
    mov cx,_counter
    cmp cx,0
    je label2
    jmp label
label2:
    ...

Da jedoch ein Compiler nicht weiß ob sich das Sprungziel innerhalb dieser 128 Byte befindet, nutzt er einen unbedingten Sprung zum Rücksprung und den bedingten um über den Rücksprung hinweg zuspringen - zwei Sprungbefehle hintereinander sind der natürliche Feind einer jeden Sprungvorhersage. Der Assemblerprogrammierer kann sich die Distanz ausrechnen und weiß, ob er innerhalb der 128 Byte liegt, in diesem Fall:

label:
    ...
    mov cx,_counter
    cmp cx,0
    jne label
    ...

Es ist kürzer, schneller und für die Branch-Prediction (bedingung auf cx) bestens vorhersagbar. --80.129.247.159 22:07, 30. Mär. 2009 (CEST)

Magst Du das einarbeiten? Ich bin daz zu wenig Fachmann... --Carbenium 12:48, 31. Mär. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:07, 5. Feb. 2015 (CET)

Ein Kern an Code muss immer in Maschinensprache programmiert werden.

Ich muss grad überlegen, was damit gemeint sein soll...

Ein Kern an Code muss immer in Maschinensprache programmiert werden.
Dazu gehören Teile der Systemprogrammierung, z. B. Betriebssystemerstellung
oder Betriebssystem-API-Programmierung, sowie auf einigen Plattformen
die Treiber-Programmierung.
Dazu werden häufig Cross-Assembler eingesetzt, die Code für eine andere
Rechnerarchitektur erzeugen als die, auf der sie selbst ablaufen. 

Und mir will kein Kontext einfallen, in dem der Satz Sinn macht oder zutreffen würde..?! Wieso sollte es nicht möglich sein, Betriebssysteme komplett in Hochsprachen zu programmieren? -cljk 23:51, 12. Mär 2006 (CET)

Da kann ich dir helfen: Bootblock, Kontextswitch, Interrupthandling. Alle Kompilate benötigen gewisse Systemvorraussetzungen, die z.B. beim Booten noch nicht gegeben sind. So ist der Bootblock des PC auf 512 Byte begrenzt - nicht gerade viel. Der Kontextswitch seinerseit ist hochsensibel, da während dieses Vorganges gewisse Register und Befehle nicht verwendet werden dürfen. Dies kann man jedoch bei einem Compiler nicht garantiert werden. Zudem können diverse Register aus einer Hochsprache heraus grundsätzlich nicht gezielt ausgelesen werden. PF 17.03.2006

Das mit den 512 Bytes im Bootblock weiss ich nicht - mag vielleicht stimmen - das hat aber nicht direkt was mit Assembler zu tun. Und das mit dem nicht möglichen Register-Zugriff in Hochsprachen stimmt so nicht generell. Ich finde es zwar einleuchtend, dass viele Teile zwecks Effektivität etc. in Assembler programmiert werden sollten - aber müssen... ?! Von daher ist die Formulierung schwammig und eigentlich nicht richtig. Ich lass mir da was zu einfallen. -cljk 14:43, 17. Mär 2006 (CET)

Es geht nicht darum ein x-belieniges Register zu verwenden, sondern bestimmte Register - z.B. im Falle erine iA32 ein MMX Register. Freilich ist dies durch ein Macro aus C heraus möglich, aber dieses Makro bedient sich des Inline-Assemlings und verlässt damit an dieser Stelle die Eigenschaft einer Hochsprache, derne primäres Ziel es ja schlißelich ist die Hardware von der Softwaredefinitionsebene zu enkoppeln. PF 19.12.2007

Die Programmiersprache C kann viel, sie ist jedoch dennoch eine Hochsprache und der Compiler kann keine Instruktionen einer CPU nutzen, die der Selbstverwaltung dienen der CPU dienen. Ein normale Anwenderprogramm, ja auch ein Systemprogramm und selbst ein Gerätetreiber ist in C möglich - ein Betriebssytem ist noch eine Stufe darunter. Das Laden der Decriptorentabellen, die Initialisierung der Security-Ringe der CPU oder das Registerretten und setzen eines Kontextswitch ist in C oder einer anderen Hochsprache nicht möglich. Einfaches Beispiel: Wie liest oder schreibst du in C das Maschinenstatuswort einer CPU - OHNE dabei auf Inline-Assembler oder Bibliotheksfunktionen zurückzugreifen - einfach mit plain C. Es geht nicht, glaube es mir, ich mach das Ganze schon zu lange um das zu wissen. C ist hardwarenah, es bietet direkten Zugriff auf den Speicher, aber keinen direkten Zugriff auf die CPU-Register und wenn dann das Argument kommt, man könne doch den Inlineassembler nehmen, dann programmiert man in Assembler und nicht in C. Der Satz, das ein Teil eine BS immer in Assembler gehalten werden muss, ist absolut korrekt. Es ist der Teil, der auf eine CPU und die nahe Hardware (z.B. DMA, Interrupt-Controler oder die MMU) maßgeschneidert ist. 80.129.190.87 01:40, 12. Sep. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:07, 5. Feb. 2015 (CET)

Programmgröße

Mir machen immer solche Formulierungen wie "Assemblerprogramme sind fast immer um ein Vielfaches kleiner ..." Verständnisprobleme, denn mir ist schleierhaft, wie aus einer Multiplikation, die ihrerseits eine verkürzte Addition ist, eine Verkleinerung resultieren soll.? Deshalb habe ich mir erlaubt, den Text zu ändern.

Das hat aber meistens schon so seine Richtigkeit, weil oftmals Compiler Routinen mit einbinden, die gar nicht notwendig sind. Die Optimierungen von Compilern sind auch teilweise schon ziemlich gut - aber begrenzt. cljk 22:25, 17. Mär 2006 (CET)

Ein Computerprogramm besteht nicht nur aus einfachen Rechenoperationen. Freilich bei einer einfachen Addition läßt sich auch mit Assembler nicht mehr soviel gewinnen. Es lohnt sich einmal einen Blick in den Befehlssatz eines z.B. Intel Prozessors zu werfen. Es gigbt eine ganze menge von Instruktionen, die zum Teil sehr aufwändige Konstrukte die durch Hochsprachen erzeugt werden, ersetzen. Bedingt durch die Arbeitsweise eines Compiler ist die Anwendung solcher "Speizalinstruktionen" nicht immer möglich. Der Grund warum Assemblerprogramme in der Regel erheblich kleiner sind ist vor allem die Tatsache, das sie nur das und in der Form implementieren, was und wie es auch gebraucht wird. PF 19.12.2007

Zu ".. um ein Vielfaches kleiner ...": Als Assembler-Fossil mit fast 30 Jahren Programmierpraxis (Großrechner) kann ich aus eigener Erfahrung ausdrücklich bestätigen, daß Assemblerprogramme i.d.R. viel kleiner als andere sind, weil der Compiler-produzierte Overhead anderer Programmiersprachen weitestgehend fehlt. Mir geht es auch nur um sprachliche Merkwürdigkeiten wie eben dies seltsame " .. um ein Vielfaches kleiner ..." oder " ... 10 mal kleiner als xyz ....". Was heißt das denn überhaupt ? Teilmengen lassen sich m.E. nicht als Multiplikation darstellen, sondern müssen doch wohl als Anteile/Brüche (z. B. Drittel, Viertel), Dezimalbrüche oder Prozentsätze bezeichnet werden, wenn man keine logischen Beulen hinterlassen will, oder? Mir ist natürlich klar, daß nicht konkret zu sagen ist, um wieviel kleiner/kürzer ein Assemblerprogramm als z.B. ein COBOL-Programm mit gleicher Funktion ausfällt, es sei denn man macht sich die Mühe, das eigens auszutesten.

Hier muss man sehr deutlich differenzieren: Der Hauptgrund warum Kompilate erheblich größer als Assemblerroutinen sind, ist, das eine unbestimmbare Anzahl von Bibliotheksfunktionen hinzu gelinkt wird. Wenn ein Hello World in Assembler kein 100 Byte auf den Speicher bringt, eine popelige C Applikation jedoch nicht unter 5 Kilobyte für die gleiche Funktionalität zu haben ist, dann bedeutet dies nun einmal nicht, das auch die gesamten 5KB abgearbeitet werden. Kompilate bringen halt eine ganze Menge toten Code mit, was eigentlichj nur Balast ist, aber nicht unbedingt stören muss. Es stimmt jedoch auch, das Hochsprachenbibliotheken zwangsläufig alle möglichen Fälle abzudecken, was zu zusätzlich, abbearbeiteten Code führt. Ich Programmiere seit rund 25 Jahren in Assembler - wenn auch seit 15 Jahren nicht mehr Schwerpunktmässig. die Zeit ist einfach vorbei, Java, C# und C++ ermöglichen eine schnellere, fehlerfreiere Entwicklung von Software. Dennoch hatte ich vor einem Jahre einen Auftrag eines Kunden, der eine Datenübertragungsmodul entwickelt haben wollte. Er beauftrage es zweimal - einmal an mich als Assembler-Lösung und einmal an einen internen Mitarbeiter als C/C++ Lösung. Bei gleicher Funktionalität standen den 190KB der C-Lösung magere 9 KB meiner Assemblerlösung gegenüber - und der C-Programmierer beherrschte sein Metier! Nachdem meine Lösung seine um den Faktor 9 schlug, ging es darum zusammen mit ihm zu ergründen, wo bei C/C++ die Zeit hängenbleibt. Ich habe mit meinen Kenntnissen dann auch noch einmal seine Lösung ind C nachgebaut - und meine war langsamer, so dass zwischen meinem C-Programm und meiner Assemblerlösung der Faktor 11 lag. Nach einiger Zeit der gemeinsamen, anfangs ratlosen Forschung mit Befehls- und Laufzeitzählung, die zu keinem wirklichen Ergebnis führten, hatten wir dennoch die Lösung: "Komm her - dein Programm ist jetzt nur noch 20% schneller" meinte er. Er hatte einfach die Caches ausgeschaltet. Bedingt durch die Codeaufteilung des Compilates kam es beim Kompilat zur rund 7-8 mal mehr "Cache-Misses". In schönster Regelmässigkeit hat Code seines eigenen Programms sich selbst verdrängt, während es bei der Assemblerlösung nur nach Taskwechseln zu Verdrängungen durch anderen Code kam. Meine Assemblerlösung lief auf meinem alten Pentium II mit 400 MHz einen Tick schneller als seine ebenfalls flinke C/C++ Lösung auf einem 3,4 GHz Pentium 4 - trotz hoher CPU-Leistung und einem 8 mal schnelleren Bus. --80.129.245.196 21:16, 31. Mär. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:07, 5. Feb. 2015 (CET)

Weiterleitung "assembley language"

weitergeleitet von assembley language?? ich weiß ehrlich gesagt nicht wie man das ändert, schön wäre wenn jemand den rechtschreibfehler entfernen würde. --91.221.59.21 11:23, 16. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 (Diskussion) 13:07, 5. Feb. 2015 (CET)

ASS = textliche Darstellung von Maschinensprache

Hallo, hier [1] liegt wohl ein Missverständnis vor, zumindest eine sehr missverständliche Formulierung. Der Leser könnte daraus schließen, mit dem ASS-Code würde Maschinencode dargestellt, d.h. M-Code existiere früher als ASS-Code. Korrekt ist dagegen, dass ASS-Code (i.d.R. 1:1) in Maschinencode umgesetzt wird. Die bisherige Formulierung ("... Befehle werden mnemotechnisch dargestellt") war korrekt - und ist eine andere Aussage als die jetzige.

Die missverständliche Aussage findet sich dann nochmal weiter unten - das macht sie aber nicht richtiger. --VÖRBY (Diskussion) 14:49, 17. Jun. 2014 (CEST)

Die Einleitung hat noch mehr Schwächen; diese zu beheben, ist aber nicht einfach. Deine Anmerkung ist mir auch aufgefallen. --arilou (Diskussion) 15:25, 17. Jun. 2014 (CEST)

Dann möchte ich wenigstens diese seltsame Formulierung revertieren. Ich würde sie sogar als TF betrachten. Oder gibt es Belege für diese Aussage? --VÖRBY (Diskussion) 19:08, 17. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:02, 1. Dez. 2016 (CET)

"zu jedem Computertyp gibt es [...] AssemblerspracheN"

Eigentlich gibt es zu jedem Computertyp immer nur EINE Assemblersprache. Allerdings können verschiedene Hersteller verschiedene "Vokabeln" (Mnemonics) verwenden: Wo MASM "mov" haben will, will Borlands Turbo-Assembler "move" und ein dritter Assembler vielleicht "copy" - aber alle übersetzen in dieselbe Maschinensprache-Bitfolge...

Aber das in der Einleitung klarzustellen, scheint mir schwierig. --arilou (Diskussion) 15:25, 17. Jun. 2014 (CEST)

Ass-Sprache: es gibt jedenfalls nur eine Maschinensprache. Ob es dann mehrere Assenblersprachen (= ASssembler) gibt, könnte m.E. schon sein. Am Einleitungssatz hätte ich eigentlich nichts auszusetzen, dort heißt es "auf die Maschinensprache zugeschnitten".

Mnemonics: Könnte man im Abschnitt Beschreibung anfügen. Machst du's? --VÖRBY (Diskussion) 19:08, 17. Jun. 2014 (CEST)

Einzahl/Mehrzahl: Ich habe das geändert: "Für unterschiedliche Computertypen ... Assemblersprachen." So bleibt bewusst offen, ob es für den einzelnen Typ nur eine oder mehrere Ass-Sprachen (und damit auch Assembler) gibt.--VÖRBY (Diskussion) 11:09, 18. Jun. 2014 (CEST)

Hab' das 'n' entfernt. Denn pro Plattform/Typ/Gerät gibts eben nur 1 Assemblersprache. (Ok, kommt ein bischen darauf an, wie man "unterschiedlich" bzgl. Assembler definiert, aber für WP:OmA ist's so verständlicher.)

--arilou (Diskussion) 10:59, 5. Feb. 2015 (CET)

"Maschinencode" gibts je Typ nur einmal. Aber für verschiedene Sprachen hast du selbst oben Beispiele angeführt. --RobTorgel 11:42, 5. Feb. 2015 (CET)

Das ist eben die Frage. Machen (geringfügig) verschiedene Mnemonics oder eine Vertauschung der Operanden-Reihenfolge schon eine andere Assemblersprache aus? Früher nannte man das einen "Dialekt" derselben Sprache. Z.B. waren Microsoft Pascal und Turbo Pascal verschiedene Dialekte, aber beide die Sprache "Pascal".

Wie gesagt, das kommt auf die genaue Definition von "unterschiedlich" an. Ich persönlich denke, dass wenn man Quellcode eines Dialekts 1:1 in Quellcode eines anderen umsetzen kann, (und beide auch noch weitgehend dieselben Mnemonics verwenden) eigentlich beide nur eine Sprache beschreiben.

(Außerdem ist es so der WP:OmA deutlicher zu erklären, dass Assembler eben genau "die Maschinen-spezifische Sprache" ist. Davon kann's für eine Maschine eigentlich nicht "mehrere verschiedene" geben.

--arilou (Diskussion) 11:59, 5. Feb. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:01, 1. Dez. 2016 (CET)

Qualität

• Abgesehen davon, daß "Assembler Programmformular" kein Deutsch ist, kann ich nicht erkennen, welchen Informationsgewinn ein vierzig Jahre altes Formular aus der DDR im Zusammenhang mit Assembler-Sprachen bietet.
• einfache arithmetische Operationen (mit Gleitkommaprozessoren auch anspruchsvolle) Was sind denn "anspruchsvolle" arithmetische Operationen?
• einfache Kontrolle des Programmflusses, einfache logische Operationen. Was heißt "einfach" in dem Zusammenhang?
• höhere Arithmetik wie Sinus-, Kosinus- und Wurzelberechnung Sinus und Cosinus sind transzendente Funktionen und damit keine "höhere Arithmetik", die Wurzelfunktion ist eine algebraische Funktion.
• Dies gilt heute praktisch nur noch, wenn wegen Massenproduktion möglichst günstige und damit minimale Mikrocontroller verwendet werden sollen und das Programm nicht zu komplex ist. Man kann raten, was der Autor damit sagen will.
• Da Assemblerprogramme sehr hardwarenah geschrieben sind, weil die unterschiedlichen Spezifikationen der einzelnen Computerarchitekturen individuell verschiedene Befehlssätze aufweisen, kann ein Assemblerprogramm i. A. nicht auf ein anderes Computersystem übertragen werden, ohne den Quelltext anzupassen. Bitte zwei Sätze daraus machen. So ist es kaum lesbar.
• ... fast immer deutlich länger ... "Fast immer deutlich" besagt gar nicht. Manchmal ja, manchmal nein, manchmal deutlich, manchmal nicht, oder was?
• heruntergebrochen Das ist Jargon.
• ... da Hochsprachencompiler in einigen Situationen ineffizienten Code generieren.[3][4] ... meint jemand. Was heißt hier "ineffizient"?
• Beispielsweise sind im Bereich des wissenschaftlichen Rechnens die schnellsten Varianten mathematischer Bibliotheken wie BLAS[5][6] oder bei architekturabhängigen Funktionen wie der C-Standardfunktion memcpy[7][8] weiterhin die mit Assembler-Code optimierten. Das ist kein Deutsch.
• Eine private Homepage ist keine belastbare Qualle und daher nicht einer Enzyklopädie würdig.

Ein Informatiker möchte den Artikel bitte in Ordnung bringen. (nicht signierter Beitrag von 91.66.63.86 (Diskussion) 16:45, 22. Jun. 2015 (CEST))

Offenbar weißt du ja Bescheid. Wieso machst du es nicht selbst ? --RobTorgel 16:55, 22. Jun. 2015 (CEST)

zu 1): Auf das "Formular-Bild" wird im Fließtext nicht eingegangen, und es ist auch eigentlich nicht wirklich Assembler-spezifisch - es gehört eher in einen Artikel Lochkarte o.ä. ~ für's erste hab' ich's mal auskommentiert.

zu 2): Hm, "höhere Arithmetik" ist eigentlich noch nicht 'Gleitkomma', sondern (Ganzzahl-)Befehle, die durch (mehrere) einfache nachgebaut werden könnten. Im Artikel geändert.

zu 3): Beispiele für "einfach" hinzugefügt.

zu 4): Danke, war ein echter Fehler. "Höhere Arithmetik" ist noch nicht "Gleitkomma" - Punkte getrennt und mit Beispiel(en) versehen.

Zum Rest komme ich später (wenn ich's nicht vergesse...)

--arilou (Diskussion) 10:08, 23. Jun. 2015 (CEST)

zu 5): umformuliert, jetzt muss hoffentlich niemand mehr raten.

zu 6): Jo, langen Satz in zweie geteilt.

zu 7): Also ich finde die Formulierung "fast immer deutlich länger" gut verständlich. Es gibt Ausnahmen, dass Assembler-Quelltext nur wenig länger oder gar kürzer ist, aber diese Ausnahmen sind selten (eigentlich nur bei einfach(st)en Programmen).

zu 8): Jargon? Lässt sich umformulieren.

zu 9): etwas umformuliert, so ist's klarer.

zu 10): 'das ist kein Deutsch' - imo ein grammatikalisch korrekter Satz:
Beispielsweise sind [...] die schnellsten Varianten [...] weiterhin die mit Assembler-Code optimierten.
(Auch wenn's mit 'nem Relativsatz am Ende einfacher zu lesen und zu verstehen wäre...)

zu 11): Eine belastbare Qualle kenn' ich auch keine ;-) Scherz lass nach - um welche Quelle geht's denn genau?

--arilou (Diskussion) 15:54, 23. Jun. 2015 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 08:51, 1. Dez. 2016 (CET)