Allerdings ist es auch möglich, im Assembler total langsame Codes zu erstellen. Dann ist jede Hochsprache schneller
Da liegt das Problem. Selbst wirklich optimalen Code zu schreiben, ist manchmal gar nicht so einfach.
Allerdings ist es auch möglich, im Assembler total langsame Codes zu erstellen. Dann ist jede Hochsprache schneller
Da liegt das Problem. Selbst wirklich optimalen Code zu schreiben, ist manchmal gar nicht so einfach.
Keine Ahnung, ob ich das als Widerspruch in sich selbst sehen muss, aber das ist es.
Das geht. Assembler ist das mit den Mnemonics, also immer noch menschenlesbarer Quellcode, der dann in Maschinensprache, also Nullen und Einsen kompiliert wird. Bei Wikipedia sieht man in der Grafik Hexadezimalcode, das ist aber nur eine andere Schreibweise für Binärcode, man könnte ihn auch dezimal darstellen.
Der C-Kompiler kann sein Kompilat allerdings optimieren, und zwar besser als der Mensch seinen Assemblercode. Daher ist es möglich, dass der von C erzeugte Maschinencode sogar schneller ist als der aus handgeschriebenem Assemblercode erzeugte. Denn wie Volkmar schrieb kann man in Assembler auch schlechten Code erstellen.
Assembler:
jmp = $e9 = 233 = 11101001
Was auch immer du eingibst, kann so oder so gelesen werden.
Schlechten Code kann man mit allem machen, einige schaffen das sogar in ihrer Muttersprache.
Nur nochmal zur Erklärung:
Assembler wird nicht kompiliert. Wer dir sowas erzählt hat, naja, ich weiss auch nicht.
Du kannst in Assembler einmal "Hallo Welt" auf den Bildschirm schreiben und einmal mit C, auch gerne ++, auch gerne "optimiert", der Code der Hochsprache, da würde ich wetten, ist "definitiv" grösser und damit langsamer, wenn man sich bewusst macht, das jedes Schalterchen im Prozessor erstmal abgelaufen werden muss.
Lass uns einfach mal danach fragen, welche Hochsprache am schnellsten ist, aber auch da ist dir ausgiebig und genügend Auskunft gegeben worden.
EDIT:
Im übrigen ist die MNemonic sowas wie die "cda"-Datei auf deiner neuen Metallica CD.
Es gibt sie nicht! Sie wird nur angezeigt, um dir irgendwas anzuzeigen.
Du siehst Programmierung etwas zu simpel. Ein Programm läuft unter Windows nicht für sich alleine, sondern ruft laufend Code des Betriebssystems auf (aus den DLLs im System32 Ordner zum Beispiel), der wiederum Rückmeldungen liefert, die ausgewertet werden. Das ist fast die ganze Programmierung unter Windows. Was du unter Windows so siehst, wäre sonst gar nicht möglich.
Um ein sinnvolles Ergebnis zu erhalten, musst du immer mehrere Funktionen miteinander verknüpfen. Dabei kannst du auf ganz unterschiedlichen Wegen zum gleichen Ergebnis kommen.
Zu einem Vernünftigen Ergebnis innerhalb der API zu kommen, ist dabei das größte Detektivspiel überhaupt.
Unter ASM ist das nicht anders, als unter jeder anderen Sprache auch.
Im übrigen ist die MNemonic sowas wie die "cda"-Datei auf deiner neuen Metallica CD.
Es gibt sie nicht! Sie wird nur angezeigt, um dir irgendwas anzuzeigen.
Das stimmt so nicht ganz. Die Mnemonic-Datei ist definitiv da. So wird der Code geschrieben und so wird er abgespeichert. Erst dann wird er übersetzt. Und das geht beileibe nicht so einfach 1:1. Dein schönes Beispiel JMP hat 3 Zeichen, der OP-Code dazu aber nicht. Er muß aber als Parameter noch die Zieladresse haben. Und die kann erst ermittelt werden, nachdem der Code übersetzt ist. Zudem gibt es verschiedene Sprungcodierungen, kurz und lang, absolut und relativ und die haben verschiedene mögliche Sprungdistanzen. Nach der fertigen Übersetzung paßt dann möglicherweise was nicht und es muß ein weiterer Übersetzerlauf folgen. Der Code enthält auch Marken und Variablen, deren reale Adressen erst nach der Übersetzung feststehen. Nur, weil ein Programm das freundlicherweise mit einem einzigen Aufruf macht, heißt das nicht, das es das alles nicht gibt.
Gruß Volkmar
Assembler wird nicht kompiliert. Wer dir sowas erzählt hat, naja, ich weiss auch nicht.
Ob das kompiliert oder übersetzt wird, Assembler und Maschinensprache ist nicht das Gleiche, wie du offenbar angenommen hattest.
Du siehst Programmierung etwas zu simpel.
Meinst du jetzt mich? Ich denke schon, dass ich ungefähr durchblicke. Deswegen bin ich auch zu XProfan gekommen. Weil das meiner Meinung nach die einfachste Sprache überhaupt ist, in der du ein Windowsprogramm erstellen kannst. Da geht das in einer Stunde. Truetype, einige Bildformate usw. bereits integriert. Und viel Schrott der dich woanders Stunden und Tage kostet fällt einfach weg.
Trotzdem fände ich es einfach mal interessant eine realistische Übersicht über die Geschwindigkeit von allen Programmiersprachen zu haben. Ich weiß gar nicht warum ihr euch so krampfhaft dagegen sträubt. Ich will gar nicht eure heilige Kuh rösten. Nur eine klitzekleine Übersicht, das sollte doch drin sein.
Meinst du jetzt mich?
Nein, dich nicht.
Trotzdem fände ich es einfach mal interessant eine realistische Übersicht über die Geschwindigkeit von allen Programmiersprachen zu haben.
Eine realistische Übersicht wird das gar nicht werden. Wenn du List hast, kannst du den Code aber gerne mal in XProfan oder sonst eine andere Sprache übersetzen. Mit dem Ergebnis wirst du aber nicht viel anfangen können.
Eine realistische Übersicht wird das gar nicht werden. Wenn du List hast, kannst du den Code aber gerne mal in XProfan oder sonst eine andere Sprache übersetzen. Mit dem Ergebnis wirst du aber nicht viel anfangen können.
Du meinst das Programm aus dem Link anfangs? Nein, das ist zu einseitig. Da werden doch nur ein paar Stringfunktionen getestet. Darum schneidet wohl auch Perl so gut ab.
Ein Testprogramm wie ich es mir vorstelle sollte eine repräsentative Auswahl der gängigsten Funktionen enthalten. Könnte auch windowsorientiert sein. Textmodus benutzt doch heute kaum einer mehr. Und relativ einfach gehalten im Hinblick auf leichte konvertierbarkeit in alle Sprachen. So ein Programm könntet auch gerne ihr erstellen.
Ich könnte ja den ganzen Test allein machen. Doch ich habe keine Webseite, nur wenige Compiler installiert und kenne auch nur ein paar Sprachen gut genug. Darum meine ich, das wäre ein Projekt für die ganze Community.
Wie gesagt - da fehlt mir das Interesse, weil es wichtigere Sachen bei der Auswahl der Programmiersprache gibt. Es soll zum Beispiel Leute geben, die mit Autoit Programme zum Suchen nach Viren schreiben, die dann weltweit genutzt werden. Warum man gerade das nicht tun sollte, auch wenn das gut und schnell und ohne viel Wissen geht, sollte man viel eher klären.
Mich würde auch sehr interessieren, welche Programmiersprache für welche Art von Codes oder bzw. für welche Art von Programmen am besten geeignet ist. Da gibt es wirklich riesige Unterschiede.
Mich würde auch interessieren, was man mit einer bestimmten Programmiersprache besser gar nicht erst versuchen sollte, auch wenn das oberflächlich betrachtet funktioniert.
Sehr interessant wäre auch, in was vom Betriebssystem und der Programmierung ich bei der Nutzung von bestimmten Programmiersprachen nur erschwert Einblick erhalte.
Was mit bestimmten Programmiersprachen nur schwer verständlich ist und was gar nicht erst geht, interessiert mich da natürlich auch.
Global geantwortet, du kannst in jeder Sprache alles machen. Nur eben in unterschiedlicher Ausführungsgeschwindigkeit und Erstellungszeit. Dabei sind die Sprachen unterschiedlich "geschwätzig" wie du hier bei der Sprache Shakespeare sehen kannst:
https://de.wikipedia.org/wiki/Liste_von…rammen/Sonstige
https://de.wikipedia.org/wiki/Liste_von…rammiersprachen
https://de.wikipedia.org/wiki/Liste_von…ammen/Assembler
Die schnellste und beste Sprache ist sowieso C. Mit Codeblocks, MinGW und GCC steht einem kostenlos die ganze große Welt der Programmierung offen. Eine schier unübersehbare Zahl von Libraries wartet darauf von einem eingebunden zu werden.
Die größte Spaßbremse sitzt vor dem Monitor. Es ist der Benutzer, der von dieser Flut von Code schier überwältigt wird. Und dann keimt der Wunsch auf eine einfache und überschaubare Sprache zu haben. Und er kommt zu XProfan³.
Global geantwortet, du kannst in jeder Sprache alles machen.
Genau das stimmt auf jeden Fall nicht. Versuche zum Beispiel mit XProfan mal einen komplett funktionsfähigen Dienst zu proggen.
Versuche dann auch mal als Anfänger in Autoit eine Systemanwendung für bestimmte Bereiche zu schreiben. Mach das gleiche dann mal als Anfänger in C.
Entwickele dann mal mit PureBasic Code im nativen undokumentierten API-Bereich und mach das dann mit einer anderen Sprache.
Schreibe mal mit Autoit eine Antivirenanwendung und pass dann mal auf, was ich und vielleicht auch viele Virenprogger mit deiner Anwendung am Ende machen.
Entwickele mal mit XProfan umfangreichen API Code und mach das gleich mal mit PureBasic.
Es gibt da riesen Unterschiede. Was 10ms schneller läuft, ist komplett unwichtig. Worauf es ankommt sind ganz andere Sachen.
Assembler und Maschinensprache ist nicht das Gleiche, wie du offenbar angenommen hattest.
Ich denke schon.
Wenn ich in Assembler schreibe, und die Datei in einem Hexeditor ausführen lasse, funktioniert es trotzdem.
Ob ich nun im Disassembler "jmp $0000" schreibe oder im Hexeditor "e9 00 00", macht für die Ausführung keinen Unterschied, es ergibt für das jeweilige Programm dies oder das... lediglich wie es präsentiert wird. Ob ich im Interpreter "run" drücke, oder es speichere und die exe doppelklicke, macht als solches keinen Unterschied. Wie gesagt, wenn mir einer nahelegen kann, das die Mnemonics anderen Binärcode erzeugt, bin ich geneigt, mich gerne einzulesen. Daran glauben würde mir trotzdem schwer fallen.
Auch ASM ist erst mal "lesbarer Code" (Befehl jmp), der wiederum in Zahlen umgesetzt werden muss (e9 hexadezimal = dezimal 233).
Dein schönes Beispiel JMP hat 3 Zeichen, der OP-Code dazu aber nicht.
Also scheinbar verstehen mich manche hier nicht, mit Absicht oder aus welchem Grund auf immer.
Ob ich den Op-Code schreibe oder den E9 macht für den Prozessor keinen anderen Befehl.
Das JMP geht nicht direkt zum Prozessor sondern der dafür bezogene OpCode. Wie ich mit dem Beispiel der CDA-Datei andeuten wollte. Es gibt auf Audio-CDs keine Dateien, auch keine CDA-Datei. Diese wird nur angezeigt als Mittler für die Menge der Tracks der CD. Ob ich nun "10 Tracks" oder "Track1" - "Track10.CDA" angezeigt bekomme, macht die CD nicht leerer oder voller.
Natürlich ist die Mnemonic ein Mittel dem User Dinge "lesbar" zu machen, schreibe ich JMP, CMP, LD oder sonstwas, schreibe ich eigentlich nicht "JMP, CMP, LD" sondern E9, 38, 8D (LEA).
Was ich damit andeuten will, wenn ich einen hexeditor nehme und die OpCodes eintrage, dieses Speichere und es mit einem Disassembler lade, habe ich Mnemonics. Es wird da nichts geändert. Sollte jedenfalls nicht so sein.
Ich meld mich ab. Werd mal ein paar OpCodes durch die 8 Kerne jagen.
Wenn du dir aber Assembler als Programmiersprache ansiehst, wird auch das natürlich kompiliert. Schau dir eine EXE an - da gibt es den PE Header zum Beispiel, nicht nur den Code.
Die Assembler Sprache MASM32 besitzt auch noch andere Befehle, wie zum Beispiel Invoke.
Also scheinbar verstehen mich manche hier nicht, mit Absicht oder aus welchem Grund auf immer.
Es sieht eher so aus, als wenn Du es nicht verstehen willst.
JMP MeinZiel
lautet die komplette Zeile in Mnemonics. JMP alleine bringt nämlich garnichts, da weiß der Prozessor überhaupt nicht, wo er hin springen soll. Und der Parameter hinter JMP kann erst ermittelt werden, wenn der Code vollständig übersetzt ist. Die Adresse ist höchst selten so lang wie der Markenname. Natürlich kann man einen einzelnen Befehl mit Parameter direkt eingeben und hat dann den Parameter auch wirklich vorliegen. Nur in einem richtigen Programm können die Parameter erst ermittelt werden, weil die realen Adressen bekannt sind. Gleiches gilt zum Beispiel auch für das von AHT angesprochene INVOKE.
Was Du mit Deiner Vorgehensweise erreichst, sind zwar auch ablauffähige Codes im Modell Tini, also COM-Dateien. Und selbst da nur kleinste Spielereien. Erstelle doch einfach mal ein richtiges Progrämmchen, zum Beispiel das Eingeben, Bearbeiten und Speichern einer Textzeile.
Gruß Volkmar
Ich denke schon.
Volkmar, AHT, Wikipedia und ich nicht.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!