CxCustum unter MorphOS - amiga-news.de Forum

amiga-news.de Forum > Programmierung > CxCustum unter MorphOS

[ - Search - New posts - Register - Login - ]

-1-

[ - Post reply - ]

2006-04-07, 14:03 h

gni
Posts: 1106
User

Kann mir jemand sagen wie ein "Gate mit Emulation trap" aussieht? Sowas braucht man für eine CxCustom() Funktion.

Danke.

[ - Answer - Quote - Direct link - ]

2006-04-07, 14:40 h

thomas
Posts: 7718
User

Ok, das Beispiel hat jetzt nichts mit Commodities zu tun, aber generell sieht ein "Emulation Trap" wie folgt aus:

wenn du in einem 68k-Programm sowas schreibst:

code:

__saveds ULONG backfillentry (__reg("a0") struct Hook *hook,__reg("a2") struct RastPort *rp,__reg("a1") struct BackFillMsg *m)

{

/* hier kommt dein Code hin */

}

Dann mußt du das bei MorphOS etwa so machen:

code:

ULONG backfillfunct (void);

struct EmulLibEntry backfillentry[] = {{TRAP_LIB, 0, (void *)backfillfunct}};

ULONG backfillfunct (void)

{
struct Hook *hook     = (void *)REG_A0;
struct RastPort *rp   = (void *)REG_A2;
struct BackFillMsg *m = (void *)REG_A1;

/* hier kommt dein Code hin */

}

Als Einsprungpunkt dient in beiden Fällen "backfillentry", also im MorphOS-Fall nicht die eigentliche Routine, sondern der 68k-Trap:

code:

backfillhook.h_Entry = (APTR)backfillentry;

Das muß so sein, weil Hooks immer als 68k-Routine aufgerufen werden, und wenn du keine 68k-Routine hast, muß du halt ein stück Pseudo-68k-Code einfügen, das aus dem Emulator rausspringt in deine PPC-Routine.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Answer - Quote - Direct link - ]

2006-04-07, 15:03 h

gni
Posts: 1106
User

Zitat:
thomas:
Ok, das Beispiel hat jetzt nichts mit Commodities zu tun,

Das wäre aber wichtig, denn CxCustom Funktionen sind "anders". Die bekommen ihre Argumente über den Stack (__stdargs).

Zitat:

code:

struct EmulLibEntry backfillentry[] = {{TRAP_LIB, 0, (void *)backfillfunct}};

Ist TRAP_LIB nicht nur für Libraryfunktionen?

Zitat:
Als Einsprungpunkt dient in beiden Fällen "backfillentry", also im MorphOS-Fall nicht die eigentliche Routine, sondern der 68k-Trap:
code:
backfillhook.h_Entry = (APTR)backfillentry;
Das muß so sein, weil Hooks immer als 68k-Routine aufgerufen werden, und wenn du keine 68k-Routine hast, muß du halt ein stück Pseudo-68k-Code einfügen, das aus dem Emulator rausspringt in deine PPC-Routine.

Soll das heissen, unter bestimmten Umständen wird 68k Code erwartet und wenn es PPC-Code sein soll, muß man mit einem TRAP arbeiten? Dann ist backfillentry vermutlich richtig, nur das die Argumente "normal" übergeben werden.

[ - Answer - Quote - Direct link - ]

2006-04-07, 16:00 h

thomas
Posts: 7718
User

Zitat:
Das wäre aber wichtig, denn CxCustom Funktionen sind "anders". Die bekommen ihre Argumente über den Stack

Ups. Wußte gar nicht, daß es sowas im AmigaOS gibt.

Naja, ich habe jetzt nicht die ganze Dokumentation durchgelesen, ob das erwähnt wird, wie man sowas am besten macht (das wäre dann deine Aufgabe), aber mein erster Ansatz wäre, aus REG_A7 den Stack-Pointer zu holen und dann aus SP[-3] das erste Argument und aus SP[-2] das zweite. In SP[-1] müßte die Rücksprungadresse drinstehen.

Zitat:
Ist TRAP_LIB nicht nur für Libraryfunktionen?

TRAP_LIB ist eine Pseudo-68k-Instruktion, die die dahinter im Speicher stehende Adresse als PPC-Routine anspringt. Das kannst du überall benutzen, wo 68k-Code zum Zuge kommt.

Zitat:
Soll das heissen, unter bestimmten Umständen wird 68k Code erwartet und wenn es PPC-Code sein soll, muß man mit einem TRAP arbeiten? Dann ist backfillentry vermutlich richtig, nur das die Argumente "normal" übergeben werden.

Natürlich. Sonst würden viele 68k-Programme nicht mehr laufen. Anders als OS4 merkt sich MorphOS nicht, in welchem Speicherbereich 68k-Code liegt und wo PPC-Code. Deshalb muß es bei Rückrufen (Hooks etc.) davon ausgehen, daß es sich um 68k-Code handelt.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Answer - Quote - Direct link - ]

2006-04-07, 21:29 h

Georg
Posts: 107
User

@gni:

Wenn MOS commodities.library noch so ist wie unter AROS:

code:

if (co->co_Ext.co_CustomExt->cext_Action)
	    {
		/* The autodocs suggest the arguments should be passed on the stack.
		 * But they were also in a0/a1 and some things seem to rely on that.
		 * Let's also pass CxBase in a6 just in case.
		 */
#ifdef __MORPHOS__
		REG_A7 -= 8;
		*(CxMsg**)REG_A7 = msg;
		*(CxObj**)(REG_A7 + 4) = co;
#endif
		AROS_UFC3(void, co->co_Ext.co_CustomExt->cext_Action,
		      AROS_UFCA(CxMsg*, msg, A0),
		      AROS_UFCA(CxObj*, co, A1),
		      AROS_UFCA(struct CommoditiesBase *, CxBase, A6));
#ifdef __MORPHOS__
		REG_A7 += 8;
#endif
	    }

Dann ist TRAP_LIB vermutlich richtig und die Funktion bekommt msg in REG_A0 und co in REG_A1. Das mit dem Stack (REG_A7) funktioniert wahrscheinlich nur für 68k Code.

[ - Answer - Quote - Direct link - ]

2006-04-08, 12:02 h

gni
Posts: 1106
User

Zitat:

Georg:
Wenn MOS commodities.library noch so ist wie unter AROS:

code:

if (co->co_Ext.co_CustomExt->cext_Action)
	    {
		/* The autodocs suggest the arguments should be passed on the stack.
		 * But they were also in a0/a1 and some things seem to rely on that.
		 * Let's also pass CxBase in a6 just in case.
		 */

Guck an, das mit a0/a1 wußte ich nicht...

Zitat:

code:

#ifdef __MORPHOS__
		REG_A7 -= 8;
		*(CxMsg**)REG_A7 = msg;
		*(CxObj**)(REG_A7 + 4) = co;
#endif
		AROS_UFC3(void, co->co_Ext.co_CustomExt->cext_Action,
		      AROS_UFCA(CxMsg*, msg, A0),
		      AROS_UFCA(CxObj*, co, A1),
		      AROS_UFCA(struct CommoditiesBase *, CxBase, A6));
#ifdef __MORPHOS__
		REG_A7 += 8;
#endif
	    }

Dann hoffe ich mal, das sich das nicht geändert hat :-)

Zitat:
Dann ist TRAP_LIB vermutlich richtig und die Funktion bekommt msg in REG_A0 und co in REG_A1. Das mit dem Stack (REG_A7) funktioniert wahrscheinlich nur für 68k Code.

Ich hätte jetzt vermutet, das MOS in diesem Fall für PPC-Funktionen die Argumente entsprechend dem SYSV V.4 ABI übergibt, dh. in r3/r4. Wenns auch in a0/a1 ist, dann muß zumindest das funktionieren.

Vielen Dank für diese (hoffentlich :-) hilfreichen Hinweise.

[ - Answer - Quote - Direct link - ]

2006-04-08, 20:26 h

Georg
Posts: 107
User

Zitat:
Original von gni:
Ich hätte jetzt vermutet, das MOS in diesem Fall für PPC-Funktionen die Argumente entsprechend dem SYSV V.4 ABI übergibt, dh. in r3/r4. Wenns auch in a0/a1 ist, dann muß zumindest das funktionieren.

In den ursprünglichen AROS Sourcen war das ein normaler C Funktionsaufruf, wie in den Docs beschrieben. Die Änderung während dem MOS Port bedeutet wohl, daß für MOS Native die Regeln geändert wurden und die Parameter immer in A0/A1 übergeben werden. War ja auch irgendwie inkonsistent, daß sonst überall für callbacks Register benutzt werden, bei CxCustom aber nicht.

[ - Answer - Quote - Direct link - ]

2006-04-09, 13:36 h

Holger
Posts: 8116
User

Zitat:
Original von Georg:
In den ursprünglichen AROS Sourcen war das ein normaler C Funktionsaufruf, wie in den Docs beschrieben. Die Änderung während dem MOS Port bedeutet wohl, daß für MOS Native die Regeln geändert wurden und die Parameter immer in A0/A1 übergeben werden. War ja auch irgendwie inkonsistent, daß sonst überall für callbacks Register benutzt werden, bei CxCustom aber nicht.

Könnte daran liegen, daß ein ppc C-Stack ein anderes Layout als ein 68k C-Stack besitzt. Für Aros, daß immer nur auf einem Prozessor laufen soll, dürfte das keine Rolle spielen.
Oder es hat noch niemand getestet, ob es z.B. auf x86 in der Form überhaupt läuft. CxCustom wird imho sehr selten benutzt und so viel Software gibt es für Aros denn doch nicht.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

2006-04-09, 14:44 h

Georg
Posts: 107
User

Zitat:
Original von Holger:
Oder es hat noch niemand getestet, ob es z.B. auf x86 in der Form überhaupt läuft.

Doch, das tut es definitiv. Zumindest in AROS x86 (bei AROS PPC werden sich libcalls usw. wohl noch ändern wenn man 68k Kompatibilität einbauen will. Z. B. in dem man das ganze so wie in MOS macht, mit traps usw.)

Denn da werden diese ganzen AROS_UF#?, AROS_L#? macros praktisch in normale C Funktionsaufruf Konvention verwandelt. Genau so als ob man diese Makros erst gar nicht verwenden würde.

UF steht übrigens für User Function. Ein callback sozusagen.

Die 3 steht für ne Funktion mit 3 Parametern.

Das A (AROS_UFCA) bedeutet Argument.

Das C bedeutet Call, also Aufruf. Es gibt noch Varianten mit P (AROS_UFP...) für Prototype und H (AROS_UFH) für (Funktions)Header.

Ne Hook Funktion sieht dann z. B. so aus

code:

AROS_UFH3(ULONG, MeineHookFunction,
  AROS_UFHA(struct Hook *, hook, A0),
  AROS_UFHA(Object *, obj, A2),
  AROS_UFHA(APTR, msg, A1))
{
  AROS_USERFUNC_INIT

  /* code */

  AROS_USERFUNC_EXIT
}

Für Code der in MOS auf AROS basiert haben die MOS Coder diese Makros angepaßt. Dadurch reicht solcher Code aus, um auch die TRAP_LIB Sache darin zu verstecken. Lustigerweise wurden diese Makros aber auch in einigen Apps benutzt die eigentlich MOS only sind. Da mögen einige wohl die MOS eigenen Makros nicht so sehr (?? NATDECL ??).

[ - Answer - Quote - Direct link - ]

2006-04-10, 11:15 h

gni
Posts: 1106
User

Zitat:
Georg:

Zitat:
gni:
Ich hätte jetzt vermutet, das MOS in diesem Fall für PPC-Funktionen die Argumente entsprechend dem SYSV V.4 ABI übergibt, dh. in r3/r4. Wenns auch in a0/a1 ist, dann muß zumindest das funktionieren.
In den ursprünglichen AROS Sourcen war das ein normaler C Funktionsaufruf, wie in den Docs beschrieben. Die Änderung während dem MOS Port bedeutet wohl, daß für MOS Native die Regeln geändert wurden und die Parameter immer in A0/A1 übergeben werden.

Wenn ich die Argumente aus a0/a1 nehme, dann funktioniert es unter MOS. Das war zu erwarten. Allerdings denke ich nicht, das das so "korrekt" ist. Alle Beispiele die zu finden sind, erwarten ihre Argumente entsprechend dem C ABI des Systems. Das die Argumente auch in a0/a1 zu finden sind, ist wohl nur "Zufall". Der (68k-)Stub, der die CxCustom-Funktion aufruft, benutzt diese Register, um die Parameter auf den Stack zu schieben. Ich denke nicht, das man das als gegeben hinnehmen darf.

Zitat:
War ja auch irgendwie inkonsistent, daß sonst überall für callbacks Register benutzt werden, bei CxCustom aber nicht.

Das ist schon richtig, aber so war es immer. Vermutlich wollte man kompatibel mit pre-OS Versionen der Bibliothek bleiben. Die älteste Version der commodities.library (Version 4.4) die ich kenne, ist auf FishDisk 87. Der dort verwendete Stub ist dem in der aktuellen 68k-Lib sehr ähnlich.

[ - Answer - Quote - Direct link - ]

-1-

[ - Post reply - ]

amiga-news.de Forum > Programmierung > CxCustum unter MorphOS

[ - Search - New posts - Register - Login - ]