|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > BlitzBasic Decompiler? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
31.01.2014, 15:34 Uhr cgutjahr Posts: 2783 [Administrator] |
Gibt es einen Decompiler für Blitz Basic? Mir ist nichts bekannt, aber vielleicht hat ja der Wanderer noch drei oder fünf halbfertige Projekte zu Hause herumliegen  [ - Antworten - Zitieren - Direktlink - ] |
|
31.01.2014, 16:24 Uhr Blackbird Posts: 634 Nutzer |
Glaube ich nicht das da einer rumfliegt... Was meinst du mit Decompiler überhaupt ? Das das Exe wieder zurück in Blitzbasic2 Source verwandelt wird ? Das gibts meines bescheidenen Wissens nicht, du kannst aber einen Disassembler (z.B Adis) nehmen und die Exe wieder in asm wandeln... So hat Bernd Rösch damals (tm) AmiBlitz2 gemacht... Für was brauchst du sowas wenn ich fragen darf ? -- regards Blackbird PerfectPaint : supportOS4@amiforce.de HP: http://perfectpaint.amiforce.de/ Have also a look at my personal Website: http://www.blackbird-net.de [ - Antworten - Zitieren - Direktlink - ] |
|
31.01.2014, 20:17 Uhr huepper Posts: 481 Nutzer |
Ich vermute mal, daß er sich den Programmcode von einem in Basic geschriebenen Programm mal anschauen möchte. ASM geht ja dann immer, aber wieder in den ursprünglichen Code ist m.E. nicht so einfach, wenn überhaupt möglich. -- Signatur ? hmm wo hab ich sie nur wieder ? [ - Antworten - Zitieren - Direktlink - ] |
|
31.01.2014, 20:29 Uhr inq Posts: 445 Nutzer |
Ein Compiler erzeugt gemeinhin Maschinensprache. Demzufolge ließe sich höchstens etwas dem nahe liegendes erzeugen: ASM. Bei Blitz-Exes könnte man noch die dazugelinkten Libs erkennen; das setzt aber etwas Kenntnis und eine Datenbank derselben voraus-oder/und die DBG-Informationen. sehr viel höher als ASM kommt man aber sicher nicht. Allerdings wäre ein aus dem ASM neu assembliertes Exe wohl deutlich kleiner als das Original.  -- Config: A1200/30/50/FPU/SCSI/64MB, WinUAE/40/xx/xxMB, EUAE/40/25/xxMB, CDTV, CD32/SX32MK2/HD - AOS3.5 [ Dieser Beitrag wurde von inq am 31.01.2014 um 20:30 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
31.01.2014, 21:30 Uhr Blackbird Posts: 634 Nutzer |
letztes oder sogar vorletztes Jahr hatten wir mal ein paar Versuche gemacht Ein Exe in AmiBlitz3 erzeugt mit Debuginfos... Dann durch Adis gejagd... Den ASMsource hab ich dann versucht durch das PPCto68k von Coyote Flux zu zwängen um ppcasm zu bekommen... Hat aber nicht so toll funktioniert, und dann hat ich keinen Bock mehr das näher zu verfolgen, wäre eh nur Warpup geworden... -- regards Blackbird [ - Antworten - Zitieren - Direktlink - ] |
|
31.01.2014, 21:57 Uhr cgutjahr Posts: 2783 [Administrator] |
Korrekt, ich würde gerne den Source-Code eines einfachen BlitzBasic-Spiels, den der Autor verloren hat, wieder "gewinnen". Einen Decompiler gibt es also offenbar nicht, schade. Wundert mich allerdings, dass die Idee auf so viel Verwunderung stößt. Natürlich muss es irgendwo eine Grenze geben, ab der die verwendete Sprache oder der generierte Code so komplex sind, dass eine Wiederherstellung der Sourcen an Grenzen stößt. Aber ich bin einfach davon ausgegangen, das Sprachen wie AMOS oder BlitzBasic noch in die Kategorie "ersetze Befehl X durch Assembler Konstrukt Y" gehören... [ - Antworten - Zitieren - Direktlink - ] |
|
31.01.2014, 22:05 Uhr Der_Wanderer Posts: 1229 Nutzer |
Nein, gibt es nicht. Der Compilvorgang ist eine Einwegfunktion. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
31.01.2014, 23:51 Uhr inq Posts: 445 Nutzer |
Zitat: Was für ein überflüssiger Ansatz, also mal ehrlich. Ich würde ja mit'nem 86k Assembler beginnen..... [ - Antworten - Zitieren - Direktlink - ] |
|
31.01.2014, 23:59 Uhr inq Posts: 445 Nutzer |
Zitat:(Noch) nicht für BB, nein. Wenn es nur ein einfaches Spiel ist, kann man es doch auch neu schreiben, oder? Zitat:Ja, so in etwa ist es auch, zumindest ungefähr. Im Prinzip werden beim Compiler zig Unterfunktionen aneinandergelinkt und über main ansprechbar gemacht. Die Unterfunktionen/Subroutinen sind aber selbst in ASM, also als Maschinensprache assembliert und dann zu Unterbibliotheken zusammenkompiliert. Demzufolge könnte man anhand der zugelinkten Libs zumindest einen Teil der Funktionalität Decompilieren; im Allgemeinen funktioniert das jedoch nicht. [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2014, 00:26 Uhr Der_Wanderer Posts: 1229 Nutzer |
Amiblitz2/3 hat auch PPC inline Assembler, fyi. Wie gesagt, Decompiler funktioniert nicht weil nicht nur Macros aneinandergepappt werden. Man kann natürlich herausfinden, welche BlitzLibs eingelinkt wurden, da die immer komplett reingelinkt werden. Das kann ich aber auch vom bloßen Anschauen des Spiels schon sagen... und hilft nicht wirklich weiter. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 01.02.2014 um 00:28 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2014, 08:26 Uhr Blackbird Posts: 634 Nutzer |
@inq: Da AmiBlitz per Compiler nur 68k exe ausspuckt, hätte das sehr wohl Sinn gemacht. Man hätte am ende wenn alles klappt ein natives PPC-exe erhalten... einen 86k Assembler kenn ich nicht und wird es auch nicht geben... Klar kann man in AmiBlitz auch PPC-inline programmieren (wenn mans kann) Aber alte Programme wo teils auch noch der Source fehlt in was Natives außer 68k zu bringen war eine reizvolle Aussicht damals (tm) Erzähl doch mal wie du das so machen würdest... -- regards Blackbird [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2014, 11:39 Uhr inq Posts: 445 Nutzer |
Zitat: Na, dahabe ich mal einen Zahlendreher, und schon versteht mich keiner mehr.  Ich meine natürlich 68k-Assembler. Dann ist dir die Vorgehensweise aber schon klar, oder? Dissassemblieren mit den Debug-Infos, alles freiräumen, was nicht Niet-und-Nagelfest ist und danach wieder Reassemblieren.Somit hättest du schon mal sauber(re)en ASM-Code, den du nach PPC-ASM wandeln könntest. [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2014, 12:57 Uhr _PAB_ Posts: 3016 Nutzer |
@inq: 68k nach PPC Assembler zu konvertieren ist - rein logisch betrachtet - eine absolut machbare Aufgabe. Im Prinzip muss man nur die 68k-Befehle in PPC-Befehle übersetzen (was auch bedeutet, die Registerzuordnung anzupassen, aber auch das ist automatisiert machbar). Komplexere 68k-Befehler, die es auf dem (RISC-)PPC nicht gibt, müssten durch längere PPC-Codeblöcke ersetzt werden. Dabei verschieben sich natürlich alle Sprungmarken, die sich nach der Ersetzungstelle befinden um einen konstanten Offset. Mit einer gründlichen Analyse des 68k-Codes sollte aber auch das automatisiert machbar sein. Einen solchen Wandler zu programmieren ist halt nur eine recht komplexe Aufgabe, die viel Geduld und gute Projektplanung erfordert. Aber vom Prinzip her implementiert ein 68k-JIT-Compiler eine ähnliche Idee... [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2014, 13:09 Uhr Blackbird Posts: 634 Nutzer |
@inq: Schon klar...wir wollten das eben mal ausprobieren. Die Idee hatte damals bernd undich hatte Zeit Die genauen Gründe weis ich jetzt auch nicht mehr, aber entweder hatte das was mit Adis oder ira zu tun weil das bis dato die einzigen weiterentwickelten Disassembler sind die Quelloffen (?) sind... @_PAB_ Für Windows gibt es einen 68k zu PPC Konverter, was der kostet und was er taugt weis ich allerdings nicht. Ich gehe auch davon aus das man dann immer noch selbst Hand anlegen muß weil so ein Konverter auch nicht zaubern kann... -- regards Blackbird [ Dieser Beitrag wurde von Blackbird am 01.02.2014 um 13:10 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.02.2014, 19:50 Uhr Der_Wanderer Posts: 1229 Nutzer |
Hm, was hat ein offline Konverter für Vorteile gegenüber einem JIT Konverter? Offensichtlich hat man mehr Zeit für Optimierungen. Fraglich ist aber ob da viel zu holen ist. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 14:46 Uhr Holger Posts: 8116 Nutzer |
Zitat:Kein Wunder, dass das nicht besonders gut funktioniert hat. Ich hätte ja 68ktoPPC probiert Zitat:Warum sollte das so sein? Zitat:Muss er ja gar nicht. Wenn die Übersetzung 68k→PPC von einem JIT on-the-fly gestemmt werden kann, sollte es wohl auch möglich sein, das ganze offline auf Assembler-Basis zu machen. Die Frage ist nur, wozu. Der JIT macht doch seine Arbeit ganz gut, so weit ich weiß. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 15:04 Uhr Thore Posts: 2266 Nutzer |
Die Größe vom Binary sagt gar nichts über die Geschwindigkeit aus, der Algorithmus, Anzahl Takte und Taktung ist entscheidend Und ob ein Binary größer oder kleiner wird hat viele Faktoren. Der JIT ist sicher gut, und da schon schneller als ein echter 680x0 Prozessor. Daher ist eine PPC Umsetzung nicht _nötig_ auch wenn sie einen Tick schneller wäre. Und ja, wenn ein JIT die Umsetzung kann, dann kann auch ein offline compiler das gleiche, allerdings mit Abstriche (Offset-Anpassungen, Selbstmodifizierten Code erkennen etc pp, wo ein JIT einfach den Block neu compiliert...) Eine zweite Recompiliermöglichkeit ist Bin-Src->Src-Bin, also ein 4 Wege Recompiler. Von 68k-code nach 68k-Asm-Text, dann nach ppc-Asm-Text und diesen dann wieder assemblieren. Das mag erst doof klingen, aber auf dem zweiten Blick merkt man, daß hier die komplexen Offset-Berechnungen entfallen, wenn mit Labels gearbeitet wird. Bisschen OT aber in dem Zusammenhang auch interessant was MAME mit verschiedenen Prozessortypen macht. Es generiert einen eigenen Opcode und dieser wird dann interpretiert. So bleibt der Interpreter stets gleich, wobei nur der Programmcode nach (sie nennen es) UML Code konvertiert wird. [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 17:01 Uhr inq Posts: 445 Nutzer |
Zitat: Weil BB2 bei der Kompilierung immer die jeweilige Befehlsbibliothek an das EXE linkt, auch wenn man nur einige wenige Befehle daraus braucht. Beispiel: ich benutze (aus welchen Gründen auch immer) die Funktion Chr$(), dann wird dafür die ganze StringFunc.lib dazugelinkt. Beim neuerlichen Assemblieren würdest du die ganzen toten Sunbroutinen aber sicher rausoptimieren, die Einsprungoffsets in die notwendigen sind ja dann schon drin. Ebenso Strukturen/Data-Bereiche, die für die benutzten Funktionen nicht notwendig wären. Beispiel2: Bild: http://imageshack.com/a/img577/4131/5awo.png hello world in BB2: (ohne Assembler) code:Für "Print" wird die printlib.obj gelinkt.;hello world 1 text$="Hello World!" Print text$ End code:Für "PutStr_" werden nur die LVOs/Structuren für die ROM-Library (DOS o.ä.) gelinkt.;hello world 2 text$="Hello World!" PutStr_ &text$ End [ Dieser Beitrag wurde von inq am 04.02.2014 um 17:15 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 18:30 Uhr Blackbird Posts: 634 Nutzer |
@inq: Das ist bei BB2 der Fall, bei Ab2/3 werden die nicht benötigten/unbenutzten Befehle per Functionsoptimizer "wegoptimiert" -- regards Blackbird [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 18:49 Uhr inq Posts: 445 Nutzer |
Zitat: Öhm, nein! ? Bild: http://imageshack.com/a/img208/492/8aai.png Die Falschfarben sind nicht meine Schuld! Ich habe natürlich "kleinstes .... exec" usw. und make smallest Code und ohne debugger... Probier mal selbst. -- Config: A1200/30/50/FPU/SCSI/64MB, WinUAE/40/xx/xxMB, EUAE/40/25/xxMB, CDTV, CD32/SX32MK2/HD - AOS3.5 [ Dieser Beitrag wurde von inq am 04.02.2014 um 18:50 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 19:03 Uhr Blackbird Posts: 634 Nutzer |
@inq: Welche Version ist das ? Das exe wurde mehrmals compiliert ? Schickes flottes Lila  Edit: Jo, bekomme die selbe Größe beim Exe mit Ab3 3.6 (6,928kb) -- regards Blackbird [ Dieser Beitrag wurde von Blackbird am 04.02.2014 um 19:09 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 20:24 Uhr inq Posts: 445 Nutzer |
Hier das helloworld2 mal als disassembliert:code: *Edit2: Bullsh*t [ Dieser Beitrag wurde von inq am 04.02.2014 um 20:31 Uhr geändert. ] [ Dieser Beitrag wurde von inq am 04.02.2014 um 22:44 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 20:48 Uhr inq Posts: 445 Nutzer |
mit ein paar kleinen Änderungen kompiliert das schon mal unter BB2. Allerdings stoppt der Debugger hart bei Label_0025 . Das ist ja wohl "Lea dosname(pc)... openlibrary... hm. mal schauen *Edit: gefixt. Jetzt bekomme ich einen Stop beim ersten Allocmem_ Aufruf (18 Bytes). Bild: http://imageshack.com/a/img811/2167/ou62.png [ Dieser Beitrag wurde von inq am 04.02.2014 um 21:58 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 22:09 Uhr Thore Posts: 2266 Nutzer |
Ist ABSEXECBASE definiert? Normal ist das die Adresse $4. Edit: Ach ja da oben ist ja der Source. Okay ist definiert [ Dieser Beitrag wurde von Thore am 04.02.2014 um 22:10 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.02.2014, 22:14 Uhr inq Posts: 445 Nutzer |
Im Registerwindow vom Debugger siehst du bei a6 auch $4 drinne stehen. bytes angefordert sind $18 (d0). was ist eigentlich normalerweise in a0 beim nach Programmstart? Weil er das gleich auf den stack schiebt. Das ist jetzt natürlich doppelt seltsam, weil Blitz2 jetzt seinen eigenen Startup-Code nochmal draufpappt...  [ Dieser Beitrag wurde von inq am 04.02.2014 um 22:48 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
05.02.2014, 01:09 Uhr Der_Wanderer Posts: 1229 Nutzer |
Zitat:Um etwas Licht ins Dunkel zu bringen: Nein, nur Funktionen werden wegoptimiert, also nicht benutzter Basic Code. BlitzLibs werden nach wie vor im ganzen dazugelinked. Das Hello World mit OS Funktionen ist kleiner, weil das lediglich Stubs sind für die OS Funktionen, ohne zusätzliche Funktionalität. Wenn man so coded braucht man aber kein Basic ;-) Wenn man die PrintLib von Basic dazu linkt, ist das logischerweise größer. Ich glaube aber nicht, dass ein Disassemlber das wegoptimieren kann. Sobald Addressen berechnet werden, weis ja niemand ob der Code erreichbar ist oder nicht. Das kann man eigentlich nur in Hochspreachen sicher wissen. Und zu guter letzt, wen juckt das eigentlich? War die Frage nicht nach einem Decompiler weil der Source verloren gegangen war? Wie gesagt, diese Frage kann man mit "Nein, das geht nicht und wird auch nicht (zufriedenstellend) gehen." beantworten. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 05.02.2014 um 01:17 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
05.02.2014, 17:09 Uhr inq Posts: 445 Nutzer |
Zitat: Naja, aber man kann stundenlang philosophieren oder sich das Chaos mal am simpelsten Programm, das man sich vorstellen kann, praktisch ausprobieren. Wie wir erfahren haben, ist der Init/Finit-Code von BB2 offenbar deutlich größer, als die eigentlich darzustellende Funktion, im o.g. Beispiel. Damit ist zumindest klar, daß ein mittelgroßes Programm/Spiel ungleich mehr Aufwand erfordert. Da kann man es dann besser gleich neuschreiben. Gruß [ - Antworten - Zitieren - Direktlink - ] |
|
05.02.2014, 20:43 Uhr Holger Posts: 8116 Nutzer |
Zitat:Würde ich das? Dazu müsste ich ja erst mal den Assembler-Code durchforsten und unbenutzte Funktionen identifizieren. Deine Aussage „Allerdings wäre ein aus dem ASM neu assembliertes Exe wohl deutlich kleiner als das Original.“ erweckt dagegen den Eindruck als würde das automatisch passieren, nur weil ich disassembliert und wieder assembliert habe. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
05.02.2014, 20:47 Uhr Holger Posts: 8116 Nutzer |
Zitat:Natürlich nicht. Ist ja schließlich nicht dessen Aufgabe. Weder Assembler noch Disassembler werden das tun. Dazu bräuchte es entweder ein eigenes Werkzeug oder Handarbeit. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
06.02.2014, 02:43 Uhr Der_Wanderer Posts: 1229 Nutzer |
Naja, wie gesagt kann der Assembler oder ein anderes Tool gar nicht wissen welche Code Stellen unbenutzt sind, es sei denn es gibt nur konstante Sprünge und keine (Sprung-)Adresse wird an externe Libraries rausgegeben. Ist auch nicht notwendig. Natürlich wird durch das Dazulinken einer ganzen BlitzLib ein Mini-Hello World verhältnismäßig groß gegenüber ASM. Aber das Sinn beim Optimieren ist nicht ein Mini Program noch kleiner zu machen, sondern ein großes Program klein zu halten. Sobald das Program komplexer wird sinkt der Anteil des BlitzLib Codes relativ zum eigenen Code, und man wird vermutlich auch mehr Funktionen als nur "Print" benutzen. Da die BlitzLibs relativ fein granular sind, ist das vertretbar, denke ich. Es wird ja nicht eine Mega Runtime dazu gelinked, sondern diese ist in ca. 250 kleine Module zerteilt, von denen selectiv gelinkt wird. -- -- Author of NTUI, AIDE, A/A++, HD-Rec, MacroWave, Sweeper, Samplemanager, ArTKanoid, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ImageConverter, ScreenCam, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > BlitzBasic Decompiler? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|
