Erste Assembler-Gehversuche

[Thorsten Otto]

Wenn das NVDI Dinge irgendwo doppet so schnell macht, wie EmuTOS, dann liegt es auf jeden Fall nicht an der Routine in vdi_line.c, die ich mir da gegriffen habe.

Auch die line-Routine ist in NVDI sicherlich schneller als in EmuTOS/TOS. Das liegt aber im wesentlichen daran, daß NVDI für sehr viele spezielle Fälle (insbesondere die die auch vom AES benutzt werden), spezielle Routinen benutzt, die entsprechend optimiert sind. Auch gibt es für jede Bit-Tiefe (1/2/4/8 plane etc) eigene Routinen in den jeweiligen Treibern. Sowas kann man in EmuTOS schon aus Platz-Gründen nicht implementieren.

Vermutlich könnte mit Assembler schon ein bisschen rausholen, aber vermutlich nur in Grössenordnungen die sich lediglich mit einem Benchmark messen lassen, und beim täglichen Gebrauch kaum auffallen, und das ganze auch nur mit erheblichem Aufwand.

Aber das soll dich nicht davon abhalten es weiterhin zu versuchen Wenn nichts anderes, kann man dabei auch eine Menge lernen

[czietz]

Zum Thema NVDI: NVDI macht auch einige "dreckige" Annahmen, wie z.B., dass gewissen Variablen in den ersten 32 kiB RAM stehen und somit über den xxx.W-Adressierungsmodus erreichbar sind. Wir mussten einmal EmuTOS deswegen anpassen.


Zum Thema kluge Compiler: Ein Beispiel. Divisionen sind sehr langsame Operationen (selbst auf modernen CPUs). Programmierer versuchen sie zu vermeiden. Aber nehmen wir an, eine Division durch drei sei nun einmal nötig:

Code: [Auswählen]

uint16_t divide_by_three(uint16_t a)
{
    uint16_t res;
    res = a / 3;
    return res;
}

Bestimmt 95% der Programmierer würden, wenn sie das händisch in Assembler formulieren müssten, in den sauren Apfel beißen und halt notgedrungen ein "DIVU.W #3,Dx" hinschreiben. Was gcc daraus macht, überrascht vielleicht den einen oder anderen: https://tinyurl.com/2cz88ktv

Auf einem 68000 braucht der naive Weg (mit DIVU) 136 Zyklen, gccs Code (obwohl mehrere Instruktionen) nur 76 Zyklen. Demnach gut 40% schneller.

[mfro]

... und wer wissen will wie (und warum) das funktioniert:

https://gmplib.org/~tege/divcnst-pldi94.pdf

[Mado]

Hilfääääää! 

@thh Naja, weiter versuchen – erstmal nicht. Ich könnte Loop-Unrolling machen und dann die Loop austauschen gegen eine Tabelle von Move-Anweisungen, in die ich dann ab der richtigen Anzahl Anweisungen rein springe etc, das hat aber wieder Nachteile in der Code-Größe und skaliert auch nicht auf immer größere Displays... Der Code ist schon gut so. Dann lad ich mir für sowas halt NVDI (Deines).

Ach ja, den Code vereinfacht für nur ST-High hatte ich in C schon mal, hat aber kaum was gebracht, da die Verwaltung der Planes kaum Laufzeit braucht. War irgendwie 3-4% schneller. Dafür lohnt es sich nicht.

[simonsunnyboy]

... und wer wissen will wie (und warum) das funktioniert:

https://gmplib.org/~tege/divcnst-pldi94.pdf

Echt interessant, nach dem heutigem Tag verdau ich das aber eher nicht.
Muss ich irgendwann mal in Ruhe lesen.