Parameterübergabe an Assemblerfuktionen?

[DualCoreCpu]

Hallo,

ich weiß, das eine Assemblerfunktion ihre Parameter in folgender Weise übernimmt:

Von links nach rechts

1. Parameter in EAX
2. Parameter in EDX
3. Parameter in ECX

Alle weiteren Variablen kommen auf den Stack.

So weit so gut. Das mag stimmen wenn die Länge der Parameter auch 32 Bit ist:

Delphi-Quellcode:

function myasmfunc(a: longint, b: longint): Longint; assemler;

Ist das aber auch so, wenn diese Parameter a und b nur 16 Bit groß sind oder gar nur Bytes?

Beim Rückgabewert einer Funktion tritt das gleiche Problem auf. Aber dort wäre, wenn das Funktionsergebnis in EAX zurückgegeben wird EAX halt bei kleineren Datenfeldern nur zum Teil fefüllt.

Aber kann ich wirklich sicher sein, das auch Bytes und 16 Bit Integers konsequent in den 3 Registern zurückgegeben werden, im Zewifelsfall eben nur zum Teil gefüllt?

[BerndS]

lässt sich mit einem einfachen Programm leicht überprüfen.

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

function Test(B: Byte; W: Word; I: Integer): LongInt;
begin
  Result := B + W + I;
end;

begin
  try
    writeln(Test(5, 50000, 1000000));
    { TODO -oUser -cConsole Main : Code hier einfügen }
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

CPU-Ansicht:

Code:

Project1.dpr.17: writeln(Test(5, 50000, 1000000));
0041C4B0 B940420F00       mov ecx,$000f4240
0041C4B5 66BA50C3         mov dx,$c350
0041C4B9 B005             mov al,$05
0041C4BB E814D5FFFF       call Test

[DualCoreCpu]

Danke @BerndS.

Dann brauch ich mir diesbezüglich keine Sorgen zu machen. :)

[TRomano]

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

[DualCoreCpu]

Zitat:

Zitat von TRomano (Beitrag 1319974)

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. :thumb:

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:

Zitat von Mavarik (Beitrag 1320112)

Nur aus reiner Neugier...

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

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

[SMO]

Zitat:

Zitat von Mavarik (Beitrag 1320112)

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 :thumb:
Dank der besser spezifizierten AMD64/x64-ABI sollte es in Zukunft nur einfacher werden, Aufrufe zu implementieren.

Zitat:

Zitat von SMO (Beitrag 1320125)

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:

Zitat von Mavarik (Beitrag 1320112)

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:

Zitat von DualCoreCpu (Beitrag 1320140)

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 :-D 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 ?