Parameterübergabe an Assemblerfuktionen?

[DualCoreCpu]

Zitat von TRomano:

Sorgen machen musst Du dir nur, wenn Du ein 64bit-Kompilat ersteellen willst. Da ist die Reihenfolge der Parameter nämlich eine andere ...

Ok, danke für den Hinweis.

Damit werd ich mich später beschäftigen. Jetzt erst mal 32Bit.

[Mavarik]

Nur aus reiner Neugier...

Was gibt es heute noch, dass man in ASM programmieren "muss"...

[Neutral General]

Zitat von Mavarik:

Nur aus reiner Neugier...

Was gibt es heute noch, dass man in ASM programmieren "muss"...

Zumindest mal Teile von Bootloadern/Betriebssystemen
Ansonsten kann je nach Situation SSE hilfreich sein, was der Compiler nicht automatisch hinbekommt.

[SMO]

Zitat von Mavarik:

Was gibt es heute noch, dass man in ASM programmieren "muss"...

Jede Menge, wenn man an Leistung interessiert ist. Der Delphi-Compiler optimiert leider nicht gut genug.
Natürlich sollte man aufpassen, keine "premature optimization" durchzuführen. Aber wenn man eine rechenintensive Anwendung hat, kann es sich lohnen, mit einem Profiler nach den Engstellen zu suchen und diese in Assembly zu schreiben (mit SSE und allem Pipapo).
FL Studio zum Beispiel benutzt Delphi und jede Menge Inline Assembly für Audiosignalverarbeitung.

Außerdem geht manches in Assembly schlicht einfacher. Konvertierung zwischen Big- und Little-Endian zum Beispiel. Für 16 Bit Werte gibt's in Delphi immerhin noch die intrinsische Funktion "Swap". Für 32 Bit muss man sich selbst etwas basteln, aus shl/shr, and, or. In Intel Assembly gibt's dafür einen dedizierten Befehl: bswap. Ich warte schon seit Jahren, dass Delphi das auch mal als intrinsische Funktion zur Verfügung stellt (Swap32 oder so). Aber das wird wohl nichts mehr; und wenn ich in der Hilfe zu Swap (siehe oben) lese "Die Prozedur dient lediglich der Abwärtskompatibilität", kann ich nur den Kopf schütteln...

[BUG]

Das ist etwas was mit dem GCC super funktioniert. Ge-inlinte Funtionen mit eingebettetem Assembler, wobei man Angaben zu Eingabe- und Ausgabe-Registern machen kann, sogar ohne sich auf spezifische Register festzulegen
Dank der besser spezifizierten AMD64/x64-ABI sollte es in Zukunft nur einfacher werden, Aufrufe zu implementieren.

Zitat von SMO:

Natürlich sollte man aufpassen, keine "premature optimization" durchzuführen.

Für das Backend macht es imho Sinn, die Zielarchitektur zu kennen bevor man mit dem Design loslegt. Das Anforderungen des Problems sollte bekannt sein, die Fähigkeiten der Hardware sollten bekannt sein. Damit kann man dann von vornherein sinnvolle Abstraktionen festlegen, die man dann später auch Optimieren kann. Als Anwendungsprogrammierer bekommt man das in Form von Bibliotheken serviert und muss das dann sinnvoll einsetzten; das Wissen über die Zielplattform sollte an der Stelle schon wegabstrahiert sein.
Die beiden Hüte kann sich natürlich auch ein und die selbe Person aufhaben.

[DualCoreCpu]

Zitat von Mavarik:

Nur aus reiner Neugier...

Was gibt es heute noch, dass man in ASM programmieren "muss"...

Schnelle Grafikroutinen für PC Spiele. Mathematische Funktionen für lanwierige Berechnungen. Es sei denn letzere werden schon auf Operatorebene passend optimiert.

Ich beschäftige mich gerade mit Ati Grain Gerometry http://www.antigrain.com.

Graeme Geldenhuys, der Macher des fpGUI Prokektes hat zur fpGUI die Pascal Version dieser Bibliothek dazu gepackt. Und bei einem Demo bin ich von der Darstellungsgeschewindigkeit regelrecht enttäuscht. Da könnte sich Assembelerprogrammierung noch lohnen.

Ansonsten Neugier, sehen wie die CPU unsere Programme verarbeitet.

Und natürlich die Compilerhersteller müssen wissen, welcher Code für das Hochsprachenkonstrukt erzeugt werden muss. Auch heute noch, es gibt ständig Compilererweiterungen.

[Zacherl]

Zitat von DualCoreCpu:

Und bei einem Demo bin ich von der Darstellungsgeschewindigkeit regelrecht enttäuscht. Da könnte sich Assembelerprogrammierung noch lohnen.

Puh. Also um noch schnelleren Code zu schreiben als die heutigen hochoptimierten Compiler, musst du wohl vorher 20 Jahre bei Intel in der CPU Entwicklung gearbeitet haben Gut, Delphi generierter Code ist leider so ziemlich gar nicht optimiert (im Gegenteil findet man ziemlich oft sogar sinnlose Instruction/Abfolgen), aber wenn du MSVC oder CLang Kompilate (in Lib- oder Dll Form) verwendest, werden die zu 99% immer performanter sein als dein eigener Assembler Code.

[Mavarik]

OMG Danke für die vielen Antworten...

Das war nicht die Frage...

Natürlich gibt es genug was man in ASM besser machen kann...

Systemnahe Programmierung sowieso... Aber in Zeiten von: Mein Code soll auf 32bit/64Bit Intel, ARM 32Bit/64Bit laufen,
stellt sich kaum noch die Frage... Weil einfach zu aufwendig...

Wie hieß es früher? Besser gut C programmieren als schlecht ASM... Wer programmiert schon "multicore" ich würde sagen vor TPL 5% der Delphi-Programmierer... Da sehe ich mehr Möglichkeiten als wenige % mit ASM raus zu holen...

Aber jeder wie er mag...

[TRomano]

Ich bin da voll bei @Mavarick, wenn es um Multi-platform geht. Leider ist der Windows-Teil des Delphi-Compilers nicht gerade optimierend ...
Wenn ich nur daran denke, wenn man mal größere Array´s aufsummieren muss, dann lohnt sich geschicktere Pascal-Programmierung (siehe pipelines) oder eben Assembler mit SSE- oder AVX-Erweiterungen. Das wird wohl noch eine Weile so bleiben, oder soll der Delphi-Windows-Compiler auch ersetzt werden ?