Warum gibt es für die AMD64 Architektur keine neue Aufrufkonvention ähnlich der FastCall Aufrufkonvention?
-
Die AMD64 Architektur hat im 64 Bit Modus ja 8 zusätzliche Allzweckregister.
Register R8 bis R15
Warum benutzt man die nicht zur Parameterübergabe als Aufrufkonvention für die Parameterübergabe, ähnliche der FastCall Aufrufkonvention.
Damit könnte man den Funktionsaufruf doch drastisch beschleunigen.
Sogar dann, wenn man 8 Parameter übergibt.Darum geht des:
http://de.wikipedia.org/wiki/Aufrufkonvention
-
Wird doch teilweise so gemacht: http://www.osronline.com/DDKx/kmarch/64bitamd_39nr.htm
-
1. fastcalls koennen code auch langsammer machen, z.b. wenn es mehrere kaskaden mit fastcalls gibt in denen die parameter in anderer reihenfolge sind. dann muss die cpu sowas oft ueber den speicher vertauschen. (die wahrscheinlichkeit steigt wenn es mehr register gibt).
2. haben die CPUs spezielle optimierungen die fuer die parameteruebergabe uber den stack optimiert sind. stack push ist ja sowas wie
*StackPointer++=value0;
*StackPointer++=value1;
*StackPointer++=value2;
... und das problem ist dann, dass auf die berechnung der neuen addresse gewartet werden muss bis der naechste wert geschrieben wird bis dann wieder eine neue addresse ansteht.
neue CPUs haben dafuer schon eine art localen stackframe auf den daten geschoben werden bevor die neue addresse bekannt ist und beim sprung wird dann in einem rutsch alles rausgeschrieben (bzw cachen manche sogar einen stackframe komplett, falls er innerhalb von ein paar registern ist).
3. falls eine funktion wirklich vom aufruf her zeitkritisch ist, dann wird sie inlined, das ist sehr viel besser als fastcalls.weil
- code kann kleiner werden
- jump instruktionen erspart man sich
- gibt keinen cachemiss im code-cache
- compiler koennen scope spezifische optimierungen durchfuehren.natuerlich gibt es auch viele moegliche stellen an denen es was bringen wuerde, z.b. ueber API grenzen hinweg aufrufen usw.
aber ich hab dir trotzdem mal ein paar moegliche gruende aufgeschrieben
-
rapso schrieb:
2. haben die CPUs spezielle optimierungen die fuer die parameteruebergabe uber den stack optimiert sind. stack push ist ja sowas wie
*StackPointer++=value0;
*StackPointer++=value1;
*StackPointer++=value2;
... und das problem ist dann, dass auf die berechnung der neuen addresse gewartet werden muss bis der naechste wert geschrieben wird bis dann wieder eine neue addresse ansteht.
neue CPUs haben dafuer schon eine art localen stackframe auf den daten geschoben werden bevor die neue addresse bekannt ist und beim sprung wird dann in einem rutsch alles rausgeschrieben (bzw cachen manche sogar einen stackframe komplett, falls er innerhalb von ein paar registern ist).
3. falls eine funktion wirklich vom aufruf her zeitkritisch ist, dann wird sie inlined, das ist sehr viel besser als fastcalls.weil
- code kann kleiner werden
- jump instruktionen erspart man sich
- gibt keinen cachemiss im code-cache
- compiler koennen scope spezifische optimierungen durchfuehren.natuerlich gibt es auch viele moegliche stellen an denen es was bringen wuerde, z.b. ueber API grenzen hinweg aufrufen usw.
aber ich hab dir trotzdem mal ein paar moegliche gruende aufgeschriebenDas mit 2 und 3 wußte ich nicht, danke für die Tipps.