Software > Coding

Erste Assembler-Gehversuche

<< < (4/5) > >>

mfro:

--- Zitat von: Mado am Di 28.06.2022, 07:10:32 ---
--- Zitat von: mfro am Mo 27.06.2022, 19:12:48 ---
--- Code: ---lea        -12(sp),sp
--- Ende Code ---
macht effektiv dasselbe mit zwei Words.

--- Ende Zitat ---
Das ist dann der nächste Schritt: Zu wissen, welcher Code schnell läuft und welcher langsam. Danke.

--- Ende Zitat ---

Was Schnelligkeit angeht, ist es für ColdFire (fast) wurscht (beim 060 dürfte das genauso sein). lea und sub brauchen beide genau einen Taktzyklus (vorausgesetzt, der Instruction-Cache ist gefüllt und es tritt kein Pipeline-Stall auf).
Allerdings ist natürlich bei 3-Wort-Befehlen der Cache "schneller leer" als bei zweien und die Wahrscheinlichkeit eines unaligned access ist höher (dann gibt's u.U. "Straftakte").
 

Mado:
Oje. Ich habe eine komplette Routine aus dem EmuTOS-ROM in Assembler implementiert, vom Algorithmus der C-Implementierung folgend. Aber ich bin nicht schneller, als der C-Compiler mit Optimierung und einer kleinen Loop, die auch im C-Original als Inline-Assembler eingebettet ist. Frust - und viel gelernt.

Ich glaube, ich habe so ungefähr jeden Fehler gemacht, den man als Assembler-Anfänger machen kann. Aber immerhin habe ich meine Routine komplett zum Laufen gebracht. :-)

Ich habe:
- WORD-Arrays nur BYTEweise indiziert und damit nette kleine Address Errors provoziert,
- Ich habe mit MOVEM weniger Register gesichert, als ich brauchte und mich über komische Abstürze gewundert,
- Ich habe Register aus versehen doppelt verwendet
- Ich habe Schleifen von C nach Assembler falsch umgesetzt, C-For-Schleifen prüfen am Anfang!
- Ich habe vorzeichenbehaftete Zahlen so behandelt, wie welche ohne
- ... und vermutlich noch viele Sachen mehr, die ich schon wieder vergessen habe

Ich habe aber auch massiv viel gelernt. Letzte Woche hatte ich eine berufliche Fahrt nach Köln und habe mir während der Fahrt komplett "ATARI ST – Programmieren in Maschinensprache", das schwarze Buch vom SYBEX-Verlag, reingetan. Dafür, dass ich gerade erst anfange, bin ich eigentlich ganz zufrieden mit mir.

Was ich auch gelernt habe: Bis auf einige Mikro-Optimierungen, die man auch in C einbetten kann, lohnt sich bei den heutigen Compilern eine Programmierung in Assembler offenbar kaum noch, außer, man will hardware-nahe Interfaces machen, oder sowas.

goetz @ 3rz:

--- Zitat von: Mado am Fr 01.07.2022, 08:13:48 ---Was ich auch gelernt habe: Bis auf einige Mikro-Optimierungen, die man auch in C einbetten kann, lohnt sich bei den heutigen Compilern eine Programmierung in Assembler offenbar kaum noch,

--- Ende Zitat ---

Ganz so weit würde ich nicht gehen, aber es ist definitiv ein ganz anderer Unterschied zwischen heutigen Compilern und denen von 1986, und handgestricktem Assembler.

czietz:
Ich bin auch schon reingefallen mit Optimierungsversuchen, die das Gegenteil bewirkt haben. Was ich in einem Vierteljahrhundert Programmierung gelernt habe:

Ganz schlecht: C-Code angucken, denken "das kann keinen guten Code ergeben" und umständlicher hinschreiben. Compiler ‒ jedenfalls moderne ‒ sind gut im Optimieren, insbesondere, wenn man den Code eben nicht vorab händisch versucht zu verbessern.

Schon besser: Compiler-Output angucken und denken "was soll denn das?". Ja, vielleicht ist eine spezifische Stelle suboptimal übersetzt. Aber wenn diese Stelle nicht in einem "heißen" Teil des Codes ist, lohnt es die Mühe dennoch nicht, sie in (Inline-)Assembler umzuschreiben.

Tipp: Hatari hat auch einen Profiler. Zumindest für die ST/68000-Emulation ist er zyklusexakt. Damit kannst Du Dir z.B. eine VDI-Funktion vornehmen und sehen, welche Codestellen "heiß" sind.

Mado:
Ich hatte gedacht, wenn ich soweit es geht alles in Registern unterbringe, anstatt immer auf Speicherstellen im Stack-Frame zuzugreifen, dann müsste es richtig schnell werden. Aber offensichtlich macht der Compiler genau das gleiche bei entsprechenden Optimierungsoptionen, -fomit-frame-pointer etc ...

Und das mit dem "heißen Teil" ist wohl ganz wichtig.

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.

Was ich auch gespürt habe ist, dass C-Code wirklich wesentlich übersichtlicher ist, als Assembler. Ich glaube nicht, dass es nur Gewohnheit ist.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete