Ich bin nicht sicher, warum damals beim
DEC auf Assembler gesetzt wurde. Ich vermute aber mal, es ging ebenfalls um Performancevorteile.
Genau, Performance spielt eine große Rolle bei Crpyto Anwendungen. Sowohl im Sinne der Geschwindigkeit, als auch im Bezug auf sparsame Nutzung von Resourcen.
Wie viel schneller läuft Assemblercode heute noch im Vergleich zu PurePascal auf modernen Prozessoren?
Das kann man pauschal nicht sagen. Der Delphi Compiler optimiert allerdings derart schlecht, dass man eigentlich gar nicht von Optimierung sprechen kann (im Vergleich zu modernen C/C++ Compilern). Oft sieht man auch total unsinnige Konstrukte, wie
direkt gefolgt von einer Zuweisung wie beispielsweise
Warum zum Teufel wird hier vorher das Register nochmal genullt, obwohl es eine Instruction später sowieso komplett überschrieben wird?
Für "normale"
GUI oder Service Anwendungen ist dieser unnötige und schlecht optimierte Code sicherlich nicht relevant, aber wenn es um Algorithmen geht, welche im Zweifelsfalle auch mal eine riesige Anzahl von Iterationen beinhalten, kann man mit Assembler definitiv eine Menge optimieren. Wenn der Code dann noch intelligent, abhängig von den CPU Features, moderne Instruction Sets, wie AVX oder AESNI verwendet, kann das schon einen erheblichen Unterschied machen.
Wie viel Wartbarkeit und Portierbarkeit verliert man durch Assembler? Und am Ende muss man Vor- und Nachteile eben abwägen.
Wartbarkeit ist meiner Meinung nach hier kein großes Problem, da die Crypto Algorithmen sich nicht mehr ändern, nachdem sie einmal standartisiert wurden. Portierbarkeit ist sicherlich ein Argument gegen inline Assembly, wobei es hier eher eine Frage des initial zu leistenden Arbeitsaufwands ist. Ich würde erstmal komplett alles in PurePascal implementieren und später, wo nötig, per IFDEFs entsprechende Assembler Optimierungen für x86 und x86-64 nachrüsten.