Alte Software neu compilieren

[Count]

Es kann sich durchaus lohnen, alte Software, von der der C-Source vorliegt, mit einem modernen Compiler neu zu compilieren. Der Optimizer kann da noch einiges an Geschwindigkeit rausholen und kompakteren Code erzeugen.

Ich habe das letztes Wochenende mal mit Ballerburg gemacht und der Grafikaufbau ist etwa doppelt so schnell. Ich habe m68k-atari-mint-gcc Version 4.6.4 genommen und konnte von der Geschwindigkeit her keinen Unterschied zwischen den Optimierungen -Os, -O2 und -O3 feststellen.

Mit einer schlanken Library wird das PRG auch deutlich kleiner:
Original: 73.410 Bytes
gcc mit -O2: 61.310 Bytes
gcc mit -Os: 53.069 Bytes

Bei Ballerburg muss man allerdings noch etwas Hand anlegen, um den (K&R-) Quellcode Mintlib-kompatibel zu bekommen. Insbesondere der Zugriff auf die OBJECT-Strukturen muss überarbeitet werden. Das wird zwar klaglos übersetzt, aber es führt regelmäßig zu zwei Bomben, weil hier mit int-Pointern und Offsets hantiert wird, was scheinbar mit Lattice C funktioniert hat. Void-Pointer gab es ja erst mit ANSI-C.

Alles in allem ist der Aufwand aber überschaubar.

[Petari]

Schöne Idee  Natürlich, wir brauchen nicht zu haben Angst von zuviel Zeit verbringen mit dieses.
Quellen sind nicht erreichbar für 99% von SW .

[Thorsten Otto]

konnte von der Geschwindigkeit her keinen Unterschied zwischen den Optimierungen -Os, -O2 und -O3 feststellen.

-O3 hat sich auch schon bei anderen Tests als wenig sinnvoll heraus gestellt. Wenn überhaupt, erzielt man damit Geschwindigkeits-Unterschiede von 1-2%, dafür wird das Programm i.d.R. deutlich länger.
Ausserdem steigt damit die Wahrscheinlichkeit, daß der Compiler fehlerhaften Code erzeugt, insbesondere bei alten Sourcen die nicht darauf vorbereitet sind und dubiose Konstrukte benutzen.

was scheinbar mit Lattice C funktioniert hat. Void-Pointer gab es ja erst mit ANSI-C.

Ob Lattice jetzt komplette ANSI war weiss ich nicht genau, aber Prototypen und Void-Pointer sollte es können. Wobei Void-Pointer jetzt nicht wirklich bei Address-Manipulation helfen

[Count]

Die Ballerburg-Sourcen sind von Oktober 1989. Selbst wenn Lattice C den damals brandneuen ANSI-Standard unterstützt hat, Eckhard Kruse hat eindeutig K&R programmiert.

Ein kleines Schmankerl am Rande:

Die Geschwindigkeit der Kanonenkugel nimmt mit höherer CPU-Taktfrequenz zu, weil das eine einfache for()-Schleife ist. Bei 16 MHz ist es noch in Ordnung, aber in Steem mit 128 MHz sieht man gar nichts mehr vom Schuss, abgesehen von den Schäden durch den Einschlag.

Leider macht evnt_timer(1) das ganze viel zu langsam, weil das AES beim Aufruf noch diverse anderere Sachen macht. Aber der Timer C hilft:

Code: [Auswählen]

clock_t clk = clock();
do {} while (clk == clock());
am Ende der Schleife schafft ab 16 MHz eine gleichmäßige Geschwindigkeit, die dem Original auf 8 MHz-Rechnern sehr nahe kommt. Leider ist es dann bei 8 MHz eine Bremse.

Aber man kann ja zu Beginn des Programms prüfen, wie schnell der Prozessor ist:

Code: [Auswählen]

clock_t clk = clock();
clock_t clk2;
for (register int i = 0; i < 1000; ++i) {
   clk2 = clock();
}
bremse = (clk2 - clk < 20); // unter 20 -> Schusskurve muss gebremst werden
liefert bei 8 MHz zuverlässig Werte für clk2-clk von 25 oder 26. Ab 16 MHz liegen die Werte bei 16 und darunter. So lässt sich der Zugriff auf den Timer C auf Situationen beschränken, wo die Differenz der Messung unter 20 liegt:

Code: [Auswählen]

if (bremse) {
    clock_t clk = clock();
    do {} while (clk == clock());
}

[mfro]

Mit einer schlanken Library ...

... darf ich fragen: welche?

[Count]

Basiert auf deiner. 

[mfro]

Basiert auf deiner. 

... das wollt' ich hören, danke

Fehlerbehebungen und Erweiterungen sind übrigens jederzeit willkommen.