[ - Antworten - Zitieren - Direktlink - ]

code:

---

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

{

/* hier kommt dein Code hin */

}

---

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 */

}

---

code:

---

backfillhook.h_Entry = (APTR)backfillentry;

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

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

---

Zitat:

---

code:

---

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

---

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

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

---

Zitat:

---

Ist TRAP_LIB nicht nur für Libraryfunktionen?

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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
	    }

---

[ - Antworten - Zitieren - Direktlink - ]

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.
		 */

---

---

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
	    }

---

---

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

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

---

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
}

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

Zitat:

---

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

---

[ - Antworten - Zitieren - Direktlink - ]