Hallo Besucher, der Thread wurde 55k mal aufgerufen und enthält 642 Antworten

letzter Beitrag von EgonOlsen71 am

Heute so compiliert...

    Noch etwas unschönes bei 99% aller Decompiler. Die überflüssige Vermüllung des Decompilates mit CMD-Kommands. Natürlich funktioniert es so, aber der P-Code, falls neu compiliert, wird massiv länger.


    Originalcode

    ----------------------

    10 PRINT#4,SR$;


    Mit 8 versichenen decompiler decompiliert

    ----------------------------------------------------

    922 CMD4,;

    8924 PRINT SR$;

    8926 PRINT#4,;


    Mein Decompiler

    --------------------

    8922 PRINT#4,SR$;

    Zitat von Stephan Scheuer

    Ich habe nun eine Testzeile compiliert, um allen Vermutungen in Gewissheit zu wandeln. Und man siehe, es werde sehrwohl Klammer mi P-Code gesetzt.



    Nichts für ungut, vielleicht ist's auch schon zu spät für mich, aber was soll denn da die Aussage sein? Du hast zwei unterschiedliche Programme compiliert und unterschiedlichen P-Code bekommen. Klar.


    Wenn, dann müsstest Du schauen, ob z.B. a=(2*2)+5 versus a=2*2+5 den gleichen P-Code erzeugt oder nicht. Und selbst wenn in dem Beispiel unterschiedlicher P-Code rauskommt, heißt das eigentlich noch nichts Definitives.


    Hast Du den UPN-Artikel gelesen?

    Es ging nur darum, ob im P-Code bei einer Berechnung mit Klammern eine veränderung auftritt. Dass das zwei unterschiedliche Programme sind, ist gewollt.


    ....Hast Du den UPN-Artikel gelesen?....

    Ja, aber erst nachdem ich das obrige gepostet hatte.


    10 X 05 BZ

    BA C0 B5 C1 = "X=10:BZ=5"


    X 02 BZ * - AY

    80 B2 81 09 08 C2 = "AY=X-2*BZ"


    X 02 - BZ * AY

    80 B2 08 81 09 C2 = "AY=(X-2)*BZ"


    Ohne das jetzt weiter zu testen, denke ich dass BlondMammuth recht hat. Ich sollte meine Behauptungen sorgfältiger durchdenken, bevor ich etwas poste.:schande:

    Das bedeutet eigentlich, dass fast alle Decompiler die Klammern nicht so ganz nach P-Code Anweisung setzten. Ob das ein Bug ist oder nach dem Motto, viel hilft viel, weiß ich nicht.

    Wobei das hier unten an Klammern ungeheuerlich ist. Damit könnte ich eine Jahresladung Wäsche aufhängen. Eigentlich benötigt man für unten aufgeführtes Decompilat keine einzige Klammer.


    8232 c7=(((((ki+j1)+i4)+ql)+rh)+hr)

    8244 ie=((((((((((((((((po+ex)+a)+la)+e)+le)+v)+h)+q)+ll)+bi)+qu)+ks)+sk)+kd)+qk)+kq)

    8296 kl=(((((((((lk+jk)+d)+dl)+dr)+ia)+jj)+kk)+k1)+k4)

    8327 ik=(((((((((((((((dt+i1)+i2)+i3)+lj)+k2)+k3)+al)+ak)+om)+rj)+gt)+vi)+pz)+zp)+rc)

    8376 c5$=((((((((((((c4$+c3$)+c2$)+c1$)+c0$)+jr$)+rj$)+gt$)+a$)+e$)+v$)+h$)+ex$)

    8416 j$=((((((((jj$+tl$)+tr$)+vi$)+pz$)+ib$)+z$)+zz$)+hi$)



    Achja, hier eine FOR...NEXT Schleife mit Austro-Comp und Austrospeed. Man sieht, dass die Austrospeed-Version ein Byte mehr enthält und unterscheidet sich in zwei Werten.


    FOR I=0 TO 10000 : NEXT


    Austro-Comp-E1

    B0 C0 A7 27 10 80 11 13


    Austrospeed-1E/Blitz

    B0 C0 A7 27 10 A0 00 11 13


    B0 = 00

    27 10 = 10000

    11 = FOR

    13 = NEXT


    Code
    1. hier nochmal den p-code und die basic-übersetzung genau darüber
    3. 10 X 05 BZ
    4. BA C0 B5 C1 = "X=10:BZ=5"
    6. X 02 BZ * - AY
    7. 80 B2 81 09 08 C2 = "AY=X-2*BZ"
    9. X 02 - BZ * AY
    10. 80 B2 08 81 09 C2 = "AY=(X-2)*BZ"
    Zitat von 1570

    aber was soll denn da die Aussage sein?

    Du solltest die Geschichte genauer lesen. Es ging darum, dass so ziemlich alle Austro-Decompiler einen Klammerwust liefern. Und Stephan Scheuer hat das Ganze vice versa getestet.

    Zitat von Stephan Scheuer

    Ich sollte meine Behauptungen sorgfältiger durchdenken, bevor ich etwas poste.

    Jein. Manchmal ist ein nicht komplett durchdachtes Problem eine Ansatzmöglichkeit, weiter zu kommen - möglicherweise auch mit einem anderen Ergebnis als das, mit dem man am Wahrscheinlichsten gerechnet hätte.

    Aber was Decompiler liefern, hat nur mittelbar mit der Struktur oder "Qualität" ihres Inputs zu tun. Falls Austro/Blitz intern UPN benutzen sollte, müssen Ausdrücke wie im Wikipedia-Artikel beschrieben mit einem kleinen Algorithmus umgeformt werden. Ob und wie gut und mit wievielen Klammer ein Decompiler das dann macht, hat eben mit dem P-Code oder dem Compiler wenig bis nichts zu tun.

    Heute mal mein C*BASE BBS Main Program mit Austro E1-J kompiliert -> Ergebnis: das Overlay File (also ohne Runtime Code) braucht 2 Blocks mehr auf der Diskette als die Blitz Version (102 Blocks zu 100 Blocks). Hmmm das hätte ich nicht erwartet, das der Unterschied so groß ist.

    Genau das habe ich gemacht. Der Austro Compiler bietet von selbst ja die Option nicht an, das File ohne R/T zu speichern.

    Also habe ich vom kompletten File den "Rest" ab $1784 bis Code Ende gespeichert.

    Plum's Blitz bietet ja direkt das Speichern als Module an. Da ist das Overlay File dann ab $1f93


    Ich hatte gehofft, durch den frei werdenden Speicherplatz einen Teil vom Z-Modem Protokoll Code unterzubringen. Aber so wird das wieder knapp :(

    Naja, das mittels Montor ab $1784 abzuspeichern ist kein Overlay. Du hast ja für jede Datei noch die Variablen-Tabelle am Ende, die bei Overlay nur bei der ersten Datei vorhanden ist, soweit ich das noch weiß.

    OK, dann richte mal mit dem WinVice ein Dualdrive ein und nutze den Austro-Comp E3. Vielleicht hat das mehr Erfolg. Zudem sind bei der E3-Version diverse Bilddarstellungsfehler gefixt.

    Achja, der P-Code Offset beginnt beim E3 ab $17A1

    Zitat von Stephan Scheuer

    dann richte mal mit dem WinVice ein Dualdrive ein

    Die sind alle grau d.h. deaktiviert, obwohl die Vice ROMs z.b. DOS4040 vorgegeben sind. Muss da noch was anderes eingestellt werden ?

    Ok das mit dem Dual Drive war mir jetzt zu blöd. Habe das File wieder mit Single Drive inkl. R/T Code erstellen lassen.

    Ergebnis: mit R/T Code $0801 - $7c44

    Ohne R/T Code $17a1 - $7c44 sind auch wieder 102 Blocks auf der Diskette.

    Original BASIC Quelldatei ist übrigens 160 Blocks lang.

    Frage an die Freunde von Blitz!: Gibt es die Runtime als (halbwegs) kommentierten Quelltext? Oder weiß jemand zufällig, wie Blitz mit der Ausgabe von Floats umgeht?


    Hintergrund der Frage ist dieser: Gibt man eine Kommazahl über die ROM-Routinen aus, dann ist das Prinzip: Umwandeln in String, Ausgabe des Strings. Das macht BASIC so, dass machen auch viele Compiler so.

    Blitz macht das wohl auch so. Aber offenbar nur, wenn es wirklich eine Kommazahl ist. Ist die Zahl zwar technisch eine Kommazahl aber sie enthält gerade keine Nachkommastellen, kommt offenbar eine andere Art der Ausgabe zum Zuge. Kann man hiermit testen:



    Der erste Teil läuft in Blitz etwas mehr als doppelt so schnell ab wie der zweite. Im Interpreter nehmen die sich aber nichts. Der zweite ist im Interpreter zwar etwas langsamer, weil mehr ausgegeben wird, aber das ist unwichtig. Das ändert sich auch nicht, wenn man mit a vorher noch herumrechnet...in dem Moment, wo bei der Ausgabe keine Nachkommastellen da sind, ist die Ausgabe schneller. Sind welche da, ist sie wieder "normal", d.h. langsam.

    Liegt die Zahl außerhalb des Bereichs von -32768 und 32767, dann ist auch Blitz wieder langsam.


    Das sieht mir also so aus:


    1. Blitz erkennt, dass die Zahl zwischen -32768 und 32767 liegt...
    2. ...und er erkennt, dass für die Ausgabe kein Komma nötig ist.
    3. ...
    4. ...wenn beides so ist, dann nimmt er eine schnellere Ausgaberoutine


    Es ist trivial zu erkennen, ob eine Kommazahl zwischen -32768 und 32767 liegt...ich habe für MOSpeed mal getestet, was passiert, wenn man die Ausgabe nur auf Basis dieser Entscheidung splittet und dann kommt das erwartete dabei raus, nämlich das die Ausgabe von Zahlen zwischen -32768 und 32767 sehr viel flotter ist. Mein Problem dabei ist: Ich habe keine Ahnung, wie ich den 2. Punkt effizient erkennen soll!? Wenn ich mir das Float-Format des 64ers so anschaue, sehe ich keinen Ansatzpunkt, um schnell zu bestimmen, ob da ein Komma vorkommen wird oder nicht. Meine einzige Idee wäre, die Zahl mittels INT() zu wandeln und zu schauen, ob sie dann identisch ist. Das würde zwar im Falle von (ja) immer noch was bringen, aber den (nein)-Fall verlangsamen.


    Daher wüsste ich gerne, was Blitz da macht...vielleicht gibt es irgendeine Magie, die ich einfach nicht fühle...

    Zitat von EgonOlsen71

    1. Blitz erkennt, dass die Zahl zwischen -32768 und 32767 liegt...
    2. ...und er erkennt, dass für die Ausgabe kein Komma nötig ist.


    Zitat von EgonOlsen71

    Mein Problem dabei ist: Ich habe keine Ahnung, wie ich den 2. Punkt effizient erkennen soll!? Wenn ich mir das Float-Format des 64ers so anschaue, sehe ich keinen Ansatzpunkt, um schnell zu bestimmen, ob da ein Komma vorkommen wird oder nicht.

    Wenn man weiß, dass die Zahl im genannten Intervall liegt, sind für den Exponenten doch nur noch 16 Werte möglich. Dann muss man "nur noch" sicherstellen, dass entsprechend viele Bits am Ende der Mantisse auf Null stehen. Bit-Gefummel dauert am 6502 leider immer etwas länger, aber mit einer Tabelle von 16 Bytes sollte man das effizient hinbekommen: Man muss ja für jeden der 16 möglichen Exponentenwerte nur speichern, wieviele Mantissenbytes auf Null sein müssen, sowie eine Bitmaske für das Mantissenbyte, welches "den Dezimalpunkt enthält". Oder habe ich das Problem nicht verstanden?

    Zitat von Mac Bacon

    Wenn man weiß, dass die Zahl im genannten Intervall liegt, sind für den Exponenten doch nur noch 16 Werte möglich. Dann muss man "nur noch" sicherstellen, dass entsprechend viele Bits am Ende der Mantisse auf Null stehen.

    Ja, wenn das mal so einfach wäre...;) Beispiel:


    Code
    1. 8425.0 : [142, 131, 164, 0, 0, 0]
    2. 8425.25 : [142, 131, 165, 0, 0, 0]
    3. 8425.5 : [142, 131, 166, 0, 0, 0]
    4. 8425.75 : [142, 131, 167, 0, 0, 0]
    5. 8426.0 : [142, 131, 168, 0, 0, 0]

    ...auf was soll man da testen?


    Edit: Obwohl...könnte gehen...aber will ich das machen? Ich kann mir nicht vorstellen, dass Blitz das so macht...

    Zitat von Mac Bacon

    Wenn man weiß, dass die Zahl im genannten Intervall liegt, sind für den Exponenten doch nur noch 16 Werte möglich. Dann muss man "nur noch" sicherstellen, dass entsprechend viele Bits am Ende der Mantisse auf Null stehen.

    Funzt! Schön, dass wir drüber gesprochen haben...:D Würde mich dennoch mal interessieren, ob Blitz das auch so macht...irgendwie glaube ich das nicht...weiß auch nicht, wieso...