Diskussion:Compiler

Grösse von kompilierten Programmen

Ich hatte in Erinnerung ein kompiliertes Programm wir in der Regel eigentlich kleiner als der Orginal-Programm, weil der Compiler es ja auch optimiert.--Jodigi 19:43, 24. Mai 2008 (CEST)

Es geht hier ja speziell um BASIC V2 und das liegt im Speicher und auf Diskette in "tokenisierter" Form vor, d.h. jeder Befehl belegt nur ein Byte. Die meisten Befehle und Funktionen werden durch den Aufruf einer Prozedur in den Laufzeitroutinen des BASIC-Compilers übersetzt, d.h. aus einem Byte werden drei Bytes für den JSR-Befehl. Plus Code der eventuelle Argumente übergibt. Die Laufzeitroutinen kommen dann auch noch dazu. --BlackJack 21:30, 24. Mai 2008 (CEST)

Die Größe des Kompilats hängt sowohl vom Inhalt des Basic-Source-Codes als auch vom verwendeten Compiler ab. Ein Basic-Programm nur aus REM Zeilen wird logischerweise sehr kurz, weil REM nicht mitkompiliert wird. Theoretisch müsste man aus 100 und mehr Blocks voller REM-Zeilen ein 1 Block langes Kompilat herstellen können. Einige Erfahrungen mit der Kompilatgröße habe ich in der Tabelle zum Artikel mal grob festgehalten. Ein und derselbe Basic-Code von 82 Blocks ergibt z.B. bei Skyle's Blitz 84 und bei Basic Boss über 130 Blocks. Dafür sind bei Blitz die Möglichkeiten sehr limitiert, ich habe den Verdacht, dass auch die Performance nicht so stark verbessert/beschleunigt wird wie beim Boss, weil bei Blitz womöglich schlichtweg weniger passiert/verändert wird beim Kompilieren. Aber weil Blitz so gut wie nicht dokumentiert ist und ich noch nichts gemessen habe, ist das erstmal nur eine vage Vermutung. Interessant wäre auch mal, die mit verschiedenen Compilern erstellten Kompilate eines Basic-Codes durch ein und denselben Packer/Cruncher zu jagen wie z.B. Exomizer und dann nochmals zu vergleichen. --TheRyk 01:07, 4. Mai 2011 (CEST)

Man muss auch noch bedenken, dass die compilierten Programme im Grunde eigenständig ablaufen können bzw. sich nicht auf das Vorhandensein des BASIC-Interpreters stützen (sollten/müssen). D.h. in Form von (internen) Bibliotheken bzw. einem Laufzeitsystem, müssten ja im Extremfall die BASIC-Kommandos quasi ausprogrammiert im Compilat enthalten sein. Inwieweit hier aber doch noch Verflechtungen mit dem Interpreter vorhanden sind, weiß ich konkret für die bekannten Compiler nicht (denkbar wäre es ja, gewisse Routinen von Basic 2.0 zu verwenden, wie z.B. die Fließkomma/Floatingpoint-Arithmetik-Routinen - sowas wird mit dem Compilieren üblicherweise auch nicht schneller). Schließlich ist das ROM dafür ohnehin immer da.
Bei gewissen Compilern hege ich ohnehin den Verdacht, dass die "nur" den Interpreter, der die Basic-Zeilen abarbeitet, insofern ersetzen, dass die zeitintensive lineare Suche von Sprungzielen bei GOTO udn GOSUB, sowie das lineare Suchen nach Variablen "wegoptimieren" und vielleicht da oder dort Variablen durch "echte" Integer-Verarbeitung ersetzen (soweit den Eindruck, den ich zumindest mit dem BASIC 64 Compiler gemacht habe) ... --JohannKlasek 13:45, 4. Mai 2011 (CEST)

Ich weiß auf Anhieb nur, dass man beim Sprung aus Assembler in ein Blitz-Kompilat vorher tunlichst eine reset-artige Abfolge von KERNAL-Interrupts aufrufen sollte, was ich vom Boss so nicht kenne. Wenn also der Boss dafür sorgt, dass das Kompilat ohne Basic-Interpreter auskommt, würde das erklären, weshalb Boss-Kompilate so groß und Blitz-Kompilate so klein sind. --TheRyk 01:18, 5. Mai 2011 (CEST)

Verbot des Dekompilierens

Der Satz „Außerdem kann die Lizenz einer zu bearbeitenden Software verbieten, sie zu dekompilieren.“ ist nicht ganz zutreffend beziehungsweise irreführend. Also natürlich kann in der Lizenz stehen das es verboten ist, aber so ein Verbot ist nicht uneingeschränkt bindend. Es gibt da beispielsweise §69e im Urheberrecht der es zu Zwecken der „Interoperabilität“ mit anderen Programmen erlaubt. Wenn man also beispielsweise eine Anwendung dekompiliert um das Dateiformat zu verstehen um einen Konverter zu schreiben, oder ein Spiel um die Level-Daten zu verstehen um einen Level-Editor zu schreiben, dann ist das legal (solange die Informationen nicht schon anderweitig vorliegen). Und „reverse engineering“ als Oberbegriff wird in vielen Ländern auch zu bestimmten Zwecken erlaubt, auch wenn im Lizenzvertrag etwas anderes steht. --BlackJack (Diskussion) 12:33, 30. Sep. 2015 (CEST)

Kannst Du es ohne irgendwelche Ausschweifungen etwas entschärfen? Oder wenn es sich nicht verhindern lässt, muss es ggf. in einem seperaten Absatz genauer erklärt werden. --Jodigi (Diskussion) 17:58, 3. Okt. 2015 (CEST)

Ich vermute mal nicht, dass ein "Leveleditor" unter die "Interoperabilität"-Klausel fällt. Schließlich gibt es nichts womit du interoperieren kannst, der Editor ist nur dazu da, das Spiel selbst zu verändern/anzupassen. Das Beispiel mit dem Konverter passt da schon eher, wenn's um allgemeine Datenbanken, Grafiken oder Texte oder so geht. --Darkstar (Diskussion) 13:14, 6. Okt. 2015 (CEST)