Heute so compiliert...

@Larry

Du hats Recht. Kann einem P-Code kein Token zugwiesen werden, wird ein REM gefolgt von dem Wert in entsprechender Adresse geschrieben.

15036 p0$=p0$+chr$(143)+str$(ch)+"/"+str$(sk):goto15057

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$;

Quote from 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.

Code

1. 10 x=10:bz=5
2. 20 ay=x-2*bz
3. ------------
4. .:1fa1 15 ba c0 b5 c1 80 b2 81 .Z.UA.R.
5. .:1fa9 09 08 c2 4f 58 00 00 00 ..Box...
6. .:1fb1 00 00 00 42 5a 00 00 00 ...bz...
7. .:1fb9 00 00 41 59 00 00 00 00 ..ay....
8. .:1fc1 00
11. 10 x=10:bz=5
12. 20 ay=(x-2)*bz
13. --------------
14. .:1fa1 15 ba c0 b5 c1 80 b2 08 .Z.UA.R.
15. .:1fa9 81 09 c2 4f 58 00 00 00 ..Box...
16. .:1fb1 00 00 00 42 5a 00 00 00 ...bz...
17. .:1fb9 00 00 41 59 00 00 00 00 ..ay....
18. .:1fc1 00

Display More

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.

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

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.

Das ist sehr merkwürdig. Compiliere mal ohne Overlay und entferne die Runtime dann von den Dateien, die diese nicht Benötigen.

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

Quote from 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 ?

Du muss den IEC-Bus aktivieren. Ansonsten mal das WinVice-Manual zu Rate ziehen. Ich hatte ein Dualdrive noch nie eingerichtet.

Du kanns auch die E3-Version decompilieren und das Drive 8-1 auf Drive 9 umcoden.

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.

160->102 Blocks ist doch ein guter Schnitt.