PureBoard

Verfasst: **11.02.2005 16:38**

So, mir war langweilig, deshalb hab ich ein kleines Plugin für jaPBe gemacht

Achtung: Diese Angaben sind veraltet, bitte immer den letzten Post anschauen!

http://mypage.bluewin.ch/remimeier/webs ... mierer.zip
KEINE Garantie auf totale Perfektion (d.h. es kann Bugs enthalten)

Dieses kleine Plugin optimiert den AsmOutput auf folgende Probleme:
- x=x (unnütz, ich weiss...)
- a-1 (jep, mit DEC)
- c - a / d (teilweise)
- a=b%2
- a%2

Das Plugin muss in den Unterordner Plugins von jaPBe kopiert werden. Es erzeugt dann bei Aufruf eine Optimiert.exe im Compilers\ Verzeichnis von PB. Dabei ist folgendes zu beachten:
- Sourcecode muss abgespeichert sein
- Sourcecode darf keine IncludeFiles besitzen (d.h. Cutterplugin benutzen!)
- Der Ordner der Exe wird dann PB\Compilers\ sein! (wegen Include* Zeugs)
- Es werden keine Fehlermeldungen des Compilers angezeigt (ausser man ist Superman und kann beim kurzen aufblitzen des cmd was sehen

)

Hier ein kleiner Testcode (natürlich ein unrealistisch optimales Beispiel

):

Code: Alles auswählen

a = 5
b = 6
c = 7
d = 3
#N = 99999999

Delay(1000)

time1 = ElapsedMilliseconds()
For z = 1 To #N
  a = a
  b - 1
  c - a / d
  c = a % 2
  c = c % 2
Next
time1 = ElapsedMilliseconds() - time1

time2 = ElapsedMilliseconds()
For z = 1 To #N
  !DEC [v_b] 
  
  !MOV    Ebx,dword [v_c] 
  !MOV    Eax,dword [v_a] 
  !MOV    Edi,dword [v_d] 
  !CDQ 
  !IDIV   Edi 
  !SUB    Ebx,Eax 
  !MOV    dword [v_c],Ebx 
  
  !MOV    Eax,dword [v_a] 
  !AND    Eax,1 
  !MOV    dword [v_c],Eax 
  
  !AND    dword[v_c], 1 
Next
time2 = ElapsedMilliseconds() - time2

MessageRequester("", Str(time1)+" "+Str(time2))

Meine Resultate:
Ohne Optimierer:
7453ms(PB) gegen 2453ms(ASM)

Mit Optimierer:
2578ms gegen 2500ms

Viel Spass

remi

PS: War nur n Zeitvertreib, deshalb nicht zu viel erwarten!

Verfasst: **12.02.2005 23:25**

Ist aber ein guter Ansatz. DEreinbau in den PB-Compiler wäre IMHO durchaus wünschenswert. Das Argument für ein fertiges Programm ist nicht, wie schnell man es kompiliert hat (weil der Compiler nicht optimiert),sondert wie gut/hoch es optimiert ist.

Verfasst: **12.02.2005 23:56**

wobei optimiert immer zweischneidig ist.

Man kann auf zwei arten Optimieren (jetzt kommen blöde beispiele, aber der sinn sollte verdeutlicht werden):

Auf Dateigröße:

Code: Alles auswählen

dim a(2)
For i=0 to 2
   a(i)=x:x=(x+1)*2
next

Und auf geschwindigkeit

Code: Alles auswählen

dim a(2)
a(0)=0
a(1)=2
a(2)=6

(denkt euch anstatt der a(2) mal a(100), dann sieht man es gut, aber ich bin jetzt ein bischen Schreibfaul.

Beide Codes machen absolut das gleiche. Aber Code 1 ist dank schleifen und Variable X langsamer, dafür ist Code 2 wesentlich größer (vorallen bei großen werten).

Verfasst: **13.02.2005 01:28**

Die Optimierungen von remi_meier werden die Dateigröße, so wie ich das sehe, nicht vergrößern, sonder bügeln paar Unreinheiten von PB aus.
Und selbst wenn die Größe ein bischen ansteigt, wer achtet heute noch darauf ob die Exe 10 KB oder 100 KB groß ist?

Verfasst: **13.02.2005 01:38**

Also bei meinen Optimierungen wird die Grösse und der Speed besser. Diese Optimierungen sind nicht sehr intelligent, es wird einfach nach einem bestimmten Muster gesucht, z.B.:
; MOV Ebx,dword [v_x]
; MOV Edi,dword [v_y]
; PUSH dword [v_z]
; MOV Eax,Edi
; POP Edi

und dann mit den gleichen Parametern in
; MOV ebx,dword [v_x]
; MOV Eax,dword [v_y]
; Mov Edi,dword [v_z]
gekürzt und hier somit auch beschleunigt...
Es ist wie gesagt sehr beschränkt auf ein paar spezifische Situationen. Wenn ich mal wieder ein bisschen Langeweile hab, werd ich mich vielleicht mal an einen "intelligenten" Optimierer machen, der dann auch 'unbekannte' Situationen erkennt und optimiert.

greetz
remi

Verfasst: **13.02.2005 11:01**

Hmm, ich frage mich gerade, warum sowas gemacht wurde. Kann es sein, das bestimmte Prozessortypen (vor Pentium bzw) nicht mit der Optimierung laufen?

Nur intressehalber.

Verfasst: **13.02.2005 14:01**

Wenn ich dich richtig verstehe fragst du, wieso folgendes gemacht wurde?
; MOV Ebx,dword [v_x]
; MOV Edi,dword [v_y]
; PUSH dword [v_z]
; MOV Eax,Edi
; POP Edi
Das liegt ganz einfach am Berechnungsalgorithmus von PB, ich weiss auch nicht, wie der aussieht, aber nach meiner Kenntnis läuft die Optimierung überall..
Es könnte zwar sein, dass eine illegale MOV Operation durch meine Optimierungen zustande kommen kann (wie gesagt, war nur n Zeitvertreib), was zwar eher unwahrscheinlich ist...

greetz
remi

Verfasst: **13.02.2005 15:35**

Ich habe Fred zumindest mal auf diesen Thread hingewiesen, ob er sich daraus etwas für PB nützliches erschließen kann, muss er selber entscheiden...

Verfasst: **13.02.2005 16:07**

remi_meier hat geschrieben:Es könnte zwar sein, dass eine illegale MOV Operation durch meine Optimierungen zustande kommen kann (wie gesagt, war nur n Zeitvertreib), was zwar eher unwahrscheinlich ist...

Mit Assemblerprogrammierung (PC) kenn ich mich nicht so aus, deshalb die Frage. Denkbar wäre es bzw. das der Code so nicht mehr auf einen Pentium 1 läuft.

Generell finde ich es schade, das PB ein bischen zu sehr auf abwärtskompatiblität setzt. Die Codes laufen ja ohne Problem auf einen 486, heute kaum noch nötig.

Für die Compileroptions wäre es schön, eine Option zu setzen, so das aktuellere CPU-Befehle unterstützt werden. Meiner Meinung nach kann man sehr wohl die Unterstützung bis einschließlich Pentium2 langsam vergessen...

Verfasst: **13.02.2005 16:21**

GPI hat geschrieben:Für die Compileroptions wäre es schön, eine Option zu setzen, so das aktuellere CPU-Befehle unterstützt werden. Meiner Meinung nach kann man sehr wohl die Unterstützung bis einschließlich Pentium2 langsam vergessen...

Das sehe ich anders, für mich ist es wichtig, dass mein (fiktiver)
selbstprogrammierter Server auch auf meiner kleinen 486er Linux-Box
läuft.

Aber eine Compileroption wäre schon nett, aber das ist wahrscheinlich
wieder zu viel verlangt

PureBoard

Compiler-Optimierungen