amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Shared Library für WarpOS [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

28.09.2004, 10:04 Uhr

gni
Posts: 1106
Nutzer 		Hallo!

Ich möchte ein Shared Library for WarpOS mit _VBCC_ erzeugen. AFAIK hat StormC irgendeine Ünterstützung dafür. Wie genau sieht die aus? Was wird gemacht? Sorgt StormC automatisch dafür, das man die PPC-Funktionen direkt (also ohne die 68k Gates) von einem WOS-Programm aus aufrufen kann?
FWIW, es geht um eine WarpOS Version von mpega_libmad (7th release).

[ - Antworten - Zitieren - Direktlink - ]
28.09.2004, 10:26 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Hallo!

Ich möchte ein Shared Library for WarpOS mit _VBCC_ erzeugen. AFAIK hat StormC irgendeine Ünterstützung dafür. Wie genau sieht die aus? Was wird gemacht? Sorgt StormC automatisch dafür, das man die PPC-Funktionen direkt (also ohne die 68k Gates) von einem WOS-Programm aus aufrufen kann?
FWIW, es geht um eine WarpOS Version von mpega_libmad (7th release).

Hihi, damit hatte ich mich auch beschäftigt, war aber zu faul, das weiter zu machen (müßte noch was entrümpelt werden);)

Also, bei StormC erzeugt StormLink die 68K-Stubs, also ohne Gates gehts nicht (war das jetzt Blasphemie? ;) .

Ich kann Dir ja mal meine Sourcen zuschicken, da kannst Du Dir anschauen, welche Stubs der StormLink erzeugt. Läßt mir Deine Mail-Adresse zukommen, dann schick ich Dir die Sourcen sofort.

Grüße


Wolfgang

[ - Antworten - Zitieren - Direktlink - ]
28.09.2004, 11:02 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zitat:
gni:
FWIW, es geht um eine WarpOS Version von mpega_libmad (7th release).
Hihi, damit hatte ich mich auch beschäftigt, war aber zu faul, das weiter zu machen (müßte noch was entrümpelt werden);)
Meine Version der Quellen ist bereits stark geändert. Eventuell könnte StormC daraus was funktionierendes bauen. Was ich verschwiegen habe ist, daß ich bereits eine funktionierende WOS Version habe... Ich bin nur nicht sicher, das die Library sich wie die vorige Version der 6th Release verhält (wenn man die Library vom PPC aus benutzt).
Zitat:
Also, bei StormC erzeugt StormLink die 68K-Stubs, also ohne Gates gehts nicht (war das jetzt Blasphemie? ;).
Welche Stubs meinst Du? Init/Open/Close/Expunge und den ROMtag? Die Stubs für die eignen Funktionen muß man ja selber machen (zumindest wird das bei mpega_libmad so gemacht).
Zitat:
Ich kann Dir ja mal meine Sourcen zuschicken, da kannst Du Dir anschauen, welche Stubs der StormLink erzeugt.
Bietet StormC nun Unterstützung (wie auch immer das aussehen tut) um die PPC-Funktionen vom PPC aus direkt aufzurufen? Oder muß man sowas wenn man das will "selber" machen?
Zitat:
Läßt mir Deine Mail-Adresse zukommen, dann schick ich Dir die Sourcen sofort.
Per Briefsymbol im Benutzerprofil solltest Du mir eine Mail schreiben können :)

[ - Antworten - Zitieren - Direktlink - ]
28.09.2004, 11:44 Uhr

whose
Posts: 2156
Nutzer 		Hast Post!

Ich hoffe, das Zeugs ist lesbar angekommen. Ist der Source zur Stub bzw. dem Wrapper für WRAP_MPEGA_decode_frame().

Für den Einsprung via 68K wird ne Stub angelegt, für den Einsprung via PPC ein Wrapper. Ist ziemlich simpel gestrickt das Ganze.

Grüße


Wolfgang

[ - Antworten - Zitieren - Direktlink - ]
28.09.2004, 13:26 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Ich hoffe, das Zeugs ist lesbar angekommen.
Jetzt ja.
Zitat:
Ist der Source zur Stub bzw. dem Wrapper für WRAP_MPEGA_decode_frame().

Für den Einsprung via 68K wird ne Stub angelegt, für den Einsprung via PPC ein Wrapper. Ist ziemlich simpel gestrickt das Ganze.
Woher weiss StormC welcher der Funktionen die öffentlichen Libraryfuntionen sind? Benutzt der Linker/IDE das .fd File?
So ganz habe ich das Prinzip der Stubs noch nicht durchschaut. Wozu ist das gut im 68k Gate:

static void (*PPCData__WRAP_MPEGA_decode_frame)(void) = _PPCStub__WRAP_MPEGA_decode_frame;

Und dann heisst das Gate auch noch _genau_ wie die PPC-Funktion. AFAICT, benutzt die WOS Version von mpega_libmad diese Stubs _nicht_. Alle öffentlichen Funktionen haben ihr Gate in library_init.c.

Wie würde man denn von PPC-Code(!) die PPC-Funktionen der Library aufrufen?


[ Dieser Beitrag wurde von gni am 28.09.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]
28.09.2004, 13:48 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:

So ganz habe ich das Prinzip der Stubs noch nicht durchschaut. Wozu ist das gut im 68k Gate:

static void (*PPCData__WRAP_MPEGA_decode_frame)(void) = _PPCStub__WRAP_MPEGA_decode_frame;

Pointer auf die PPCStub-Funktion ;)

Zitat:
Und dann heisst das Gate auch noch _genau_ wie die PPC-Funktion. AFAICT, benutzt die WOS Version von mpega_libmad diese Stubs _nicht_. Alle öffentlichen Funktionen haben ihr Gate in library_init.c.

Wie würde man denn von PPC-Code(!) die PPC-Funktionen der Library aufrufen?


[ Dieser Beitrag wurde von gni am 28.09.2004 editiert. ]


Also, die PPC-Funktion ist _PPCStub__WRAP_MPEGA_decode_frame. Genau dieser Aufruf (der vom Linker extern aufgelöst wird) wird vom 68K-Gate benutzt (siehe oben im Quelltext). Die wird auch benutzt, wenn Du das für PPC compilierst. Der Aufruf aus PPC-Code heraus lautet dann genau so, wie bisher, intern wird aber die _PPCStub_-Funktion benutzt. Daran kommst Du leider nicht vorbei, wenn Du mixed binaries erzeugst.

Kompilierst Du _nur_ für PPC, benötigst Du manchmal die Gate-Funktionen für 68K, wenn der Aufruf aus 68K-Code heraus erfolgt, ansonsten nicht. Keine Wrapper oder Stubs für die PPC-Funktionen.

Ich muß jetzt leider Zur Arbeit, aber ich schick Dir heut abend per Mail mal das Ganze Projekt inkl. Hauptprojekt, dann kannst Dir das genauer anschauen.

Grüße


Wolfgang

[ - Antworten - Zitieren - Direktlink - ]
28.09.2004, 14:26 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zitat:
gni:
static void (*PPCData__WRAP_MPEGA_decode_frame)(void) = _PPCStub__WRAP_MPEGA_decode_frame;
Pointer auf die PPCStub-Funktion ;)
Und wozu brauch ich den? Warum kann ich _PPC_Stub nicht direkt verwenden?
Zitat:
Also, die PPC-Funktion ist _PPCStub__WRAP_MPEGA_decode_frame. Genau dieser Aufruf (der vom Linker extern aufgelöst wird) wird vom 68K-Gate benutzt (siehe oben im Quelltext). Die wird auch benutzt, wenn Du das für PPC compilierst.
Wenn immer die generierten Stubs verwendet werden, warum gibst dann in den LIB_MPEGA Funktionen RunPPC Aufrufe für WarpOS, die IMHO auch verwendet werden? Wenn die generierten Gates verwendet werden, brauchts bei den WRAP-Funktionen kein __saveds, da das schon beim _PPCStub gemacht wurde.
Zitat:
Der Aufruf aus PPC-Code heraus lautet dann genau so, wie bisher, intern wird aber die _PPCStub_-Funktion benutzt. Daran kommst Du leider nicht vorbei, wenn Du mixed binaries erzeugst.
Ich glaube Du verstehst mich nicht. Das ganze ist eine Library und ich möchte jetzt von einem WOS-Programm die Library nutzen _ohne_ das ich durch das 68k-Gate muß. Also wie genau rufe ich jetzt von einem PPC Programm die PPC-Libraryfunktion auf? Geht das überhaupt?

[ - Antworten - Zitieren - Direktlink - ]
28.09.2004, 23:36 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:
Und wozu brauch ich den? Warum kann ich _PPC_Stub nicht direkt verwenden?

Du kannst Dir die Gate-Funktionen auch ohne weiteres selber basteln, kannst dann aber nicht mehr ganz so einfach zwischen 68K- und PPC-Compiler wechseln.

Zitat:
Wenn immer die generierten Stubs verwendet werden, warum gibst dann in den LIB_MPEGA Funktionen RunPPC Aufrufe für WarpOS, die IMHO auch verwendet werden? Wenn die generierten Gates verwendet werden, brauchts bei den WRAP-Funktionen kein __saveds, da das schon beim _PPCStub gemacht wurde.

Stimmt. Allerdings sind diese RunPPC-Aufrufe "selbstgebastelte" Gates und tun meines Wissens nicht mit dem StormC.

Zitat:
Ich glaube Du verstehst mich nicht. Das ganze ist eine Library und ich möchte jetzt von einem WOS-Programm die Library nutzen _ohne_ das ich durch das 68k-Gate muß. Also wie genau rufe ich jetzt von einem PPC Programm die PPC-Libraryfunktion auf? Geht das überhaupt?

Hast Recht, das hatte ich wirklich nicht so aufgefaßt.

Soweit ich weiß, kann man nur über die 68K-Einsprünge Funktionen einer shared library aufrufen, das bedeutet, auch aus PPC-Programmen heraus muß man über die 68K-Gates die Funktion der Library aufrufen, unabhängig davon, ob der Code der Funktion 68K oder PPC ist. Das war ja auch das große Problem, von wegen n Haufen Zeit mit den Context-Switches verplempern usw.

Innerhalb der Library hingegen kannst Du ohne Umweg über Gates aus einer PPC-Funktion eine andere PPC-Funktion aufrufen. So hatte ich das verstanden.

Grüße


Wolfgang

[ - Antworten - Zitieren - Direktlink - ]
29.09.2004, 12:30 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Zitat:
gni:
Und wozu brauch ich den? Warum kann ich _PPC_Stub nicht direkt verwenden?
Du kannst Dir die Gate-Funktionen auch ohne weiteres selber basteln, kannst dann aber nicht mehr ganz so einfach zwischen 68K- und PPC-Compiler wechseln.
Ich kenne StormC nicht :-) Wechseln des Compilers macht aber aber nicht an allen Stellen Sinn. Bestimmter Code muß _68k_ sein. Das war aber nicht die Frage: Mich wunderte, das die generierte Gate-Funktion eine lokale statische Variable enthält, die auf die eigentliche PPC-Funktion verweisst. Es muß einen Grund für deren Existenz geben, denn man kann die PPC-Funktion ja direkt anpsrechen....
Zitat:
Allerdings sind diese RunPPC-Aufrufe "selbstgebastelte" Gates und tun meines Wissens nicht mit dem StormC.
Das wäre ja überraschend wenn diese RunPPC-Aufrufe nicht mit StormC funktionieren würden, denn die WOS_version von mpega_libmad wurde bisher mit StormC V4 gebaut :-) StormC V4 == StormGCC, richtig?
Zitat:
Soweit ich weiß, kann man nur über die 68K-Einsprünge Funktionen einer shared library aufrufen, das bedeutet, auch aus PPC-Programmen heraus muß man über die 68K-Gates die Funktion der Library aufrufen, unabhängig davon, ob der Code der Funktion 68K oder PPC ist. Das war ja auch das große Problem, von wegen n Haufen Zeit mit den Context-Switches verplempern usw.
Also braucht man bei WOS-Libraries immer separate Einsprünge in der Librarybasis für echte PPC-Funktionen, die vom PPC aus aufgerufen werden. Darum müßte man sich aber selber kümmern und Storm hilft da nicht wirklich? Eventuell hatte die WOS-Bibliothek des 6th Release ja nur ein 68k-Interface (und ich mache mir grundlos Gedanken ;-)?
Zitat:
Innerhalb der Library hingegen kannst Du ohne Umweg über Gates aus einer PPC-Funktion eine andere PPC-Funktion aufrufen. So hatte ich das verstanden.
Das versteht sich von selbst ;-) Mir ging es ja auch um PPC-Programme die die (PPC-) Shared-Library benutzen.

[ - Antworten - Zitieren - Direktlink - ]
29.09.2004, 13:08 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von gni:

Ich kenne StormC nicht :-) Wechseln des Compilers macht aber aber nicht an allen Stellen Sinn. Bestimmter Code muß _68k_ sein. Das war aber nicht die Frage: Mich wunderte, das die generierte Gate-Funktion eine lokale statische Variable enthält, die auf die eigentliche PPC-Funktion verweisst. Es muß einen Grund für deren Existenz geben, denn man kann die PPC-Funktion ja direkt anpsrechen....

Die lokale Variable innerhalb der Gate-Funktion ist nur für die Gate-Funktion selbst interessant. Da werden die Funktionsparameter umhergeschoben und die PPC-Wrapper-Funktion auferufen, mehr passiert da nicht. Ist ähnlich wie die Gates, die Du schon im Source der MPEGALibmad drinhast.

Zitat:
Zitat:
Allerdings sind diese RunPPC-Aufrufe "selbstgebastelte" Gates und tun meines Wissens nicht mit dem StormC.
Das wäre ja überraschend wenn diese RunPPC-Aufrufe nicht mit StormC funktionieren würden, denn die WOS_version von mpega_libmad wurde bisher mit StormC V4 gebaut :-) StormC V4 == StormGCC, richtig?

Das habe ich auch gelesen ;) Allerdings compiliert die nicht auf dem StormC4, habe ich bereits probiert. Sieht mir auch mehr so aus, als hätte man da versucht, PUP und WOS zu mischen. Keine Ahnung, was der vorherige Maintainer da für Tricks benutzt hat, damit das lief. Bei mir tuts das jedenfalls nicht, daher hab ich damit begonnen, mit der herkömmlichen Methode zu arbeiten. Und die compiliert wenigstens ;)

Zitat:
Also braucht man bei WOS-Libraries immer separate Einsprünge in der Librarybasis für echte PPC-Funktionen, die vom PPC aus aufgerufen werden. Darum müßte man sich aber selber kümmern und Storm hilft da nicht wirklich? Eventuell hatte die WOS-Bibliothek des 6th Release ja nur ein 68k-Interface (und ich mache mir grundlos Gedanken ;-)?

Das verstehe ich jetzt wieder nicht so ganz. Eine echte "WOS-Library" im Sinne einer shared library gibts ja nicht. Es gibt nur shared libraries in Form eines mixed oder fat binary, wo eben neben 68K-Funktionen auch PPC-Funktionen enthalten sind, die man _nur_ über die 68K-Gates erreichen kann, auch von PPC-Programmen aus. Im Grunde das Gleiche wie bei PUP. Zumindest sehe ich bei dem, was ich über AOS shared libraries weiß auch keine andere Möglichkeit, in die Lib Funktionen direkt von einem PPC-Programm aus einzuspringen. Außer, man bastelt sich selbst ein "WOS shared library Framework". Meinst Du das?

Wär des einfacher gewesen, hätten wir das Heckmeck mit den Context Switches wohl nie gehabt *seufz*

Zitat:
Das versteht sich von selbst ;-) Mir ging es ja auch um PPC-Programme die die (PPC-) Shared-Library benutzen.

Das wiederum hab ich nu verstanden ;)

Grüße


[ - Antworten - Zitieren - Direktlink - ]
29.09.2004, 14:47 Uhr

gni
Posts: 1106
Nutzer
Zitat:
whose:
Die lokale Variable innerhalb der Gate-Funktion ist nur für die Gate-Funktion selbst interessant.
Wofür brauche ich die nun? :-)
Zitat:
Zitat:
Das wäre ja überraschend wenn diese RunPPC-Aufrufe nicht mit StormC funktionieren würden, denn die WOS_version von mpega_libmad wurde bisher mit StormC V4 gebaut :-) StormC V4 == StormGCC, richtig?
Das habe ich auch gelesen ;) Allerdings compiliert die nicht auf dem StormC4, habe ich bereits probiert.
Du meinst Du kannst nicht linken, oder? Mit BUILD_WARPUP sollte sich library_init.c mit dem 68k(!) Compiler übersetzen lassen. Und wir reden über StormGCC, right?
Zitat:
Sieht mir auch mehr so aus, als hätte man da versucht, PUP und WOS zu mischen.
Nein, das täuscht. Das ganze sieht deshalb so chaotisch aus, weil es soviele BUILD_ Tests in library_init.c gibt.
Zitat:
Keine Ahnung, was der vorherige Maintainer da für Tricks benutzt hat, damit das lief. Bei mir tuts das jedenfalls nicht, daher hab ich damit begonnen, mit der herkömmlichen Methode zu arbeiten. Und die compiliert wenigstens ;)
Aber läuft bei Dir totzdem nicht ;-) Bei mir funktioniert es mit eigenen RunPPC-Calls.
Zitat:
Zitat:
Also braucht man bei WOS-Libraries immer separate Einsprünge in der Librarybasis für echte PPC-Funktionen, die vom PPC aus aufgerufen werden. Darum müßte man sich aber selber kümmern und Storm hilft da nicht wirklich? Eventuell hatte die WOS-Bibliothek des 6th Release ja nur ein 68k-Interface (und ich mache mir grundlos Gedanken ;-)?
Das verstehe ich jetzt wieder nicht so ganz. Eine echte "WOS-Library" im Sinne einer shared library gibts ja nicht.
Doch gibt es ;) (Auch) bei PowerUp ist es möglich die PPC-Libraryfunktionen direkt vom PPC-Programm aufzurufen. Allerdings ist das ganze nicht SetFunction kompatibel.
Zitat:
Es gibt nur shared libraries in Form eines mixed oder fat binary, wo eben neben 68K-Funktionen auch PPC-Funktionen enthalten sind, die man nur über die 68K-Gates erreichen kann, auch von PPC-Programmen aus.
Ist für Dich auch ein Mixed-Binary eine Library, bei der die 68k Funktionen nur an den PPC weiterreichen (sprich ohne PPC gehts nicht)?
Zitat:
Im Grunde das Gleiche wie bei PUP. Zumindest sehe ich bei dem, was ich über AOS shared libraries weiß auch keine andere Möglichkeit, in die Lib Funktionen direkt von einem PPC-Programm aus einzuspringen.
Man kann nicht relativ zur Basis einspringen, aber man kann sich ja die Zieladresse aus dem jmp in der Basis holen und dann den Aufruf per Funktionszeiger machen.
Zitat:
Außer, man bastelt sich selbst ein "WOS shared library Framework".
Was soll das sein?
Zitat:
Wär des einfacher gewesen, hätten wir das Heckmeck mit den Context Switches wohl nie gehabt *seufz*
Die kann man nicht vermeiden, wenn man 68k Libraries verwendet (und die meisten Libraries sind ja 68k)
Zitat:
Zitat:
Mir ging es ja auch um PPC-Programme die die (PPC-) Shared-Library benutzen.
Das wiederum hab ich nu verstanden ;)
Gut! :-)


[ Dieser Beitrag wurde von gni am 29.09.2004 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Shared Library für WarpOS [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.