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

amiga-news.de Forum > Programmierung > Wie erstellt man eine Library in C? [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- [ - Beitrag schreiben - ]

10.07.2006, 19:00 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von tboeckel:
Lies diesen Satz noch mal mit ganz viel Verstand von vorne bis hinten durch. Da steht nichts davon drin, daß man die mathieeesing#? und die mathieeedoub#? nicht gleichzeittig verwenden darf.

Glaubst Du nicht, daß ich in der Lage bin, den Satz in der original-Dokumentation nachzulesen, wo auch die andere Eigenheit beschrieben wird?
Zitat:
Der alte Trick, daß das Hauptprogramm alle Bibliotheken öffnet und alle weiteren Subtasks munter dieselben Basisadressen verwenden, klappt nämlich genau bei sämtlichen math#?.library NICHT. Das ist hier mit shared among tasks gemeint.
Wie Du vielleicht siehst, geht es hier um Library-Programmierung. Und in einer Library hat man keinen Einfluß darauf, was der Aufrufer noch so alles macht. Wenn Du Dir die Dokumentation mal durchliest, auch bzgl. dessen, was in diesem kleinen Zitat nicht erwähnt wurde, z.B. über das Verhalten bei mehrmaligen Öffnen und eben der Sache mit dem Mischen von single- und double precision, dann wird Dir vielleicht auch klar, das damit das Benutzen der math-libs aus einer Bibliothek unmöglich geworden ist.

Woher soll Bibliothek a wissen, ob eine Bibliothek b, vom gleichen Task geöffnet, eine andere math-Bibliothek öffnet?
Zitat:
Ich meine dieses Verhalten wäre bereits unter OS1.3 so gewesen, wo so langsam die ersten Turbokarten mit FPU in Mode kamen. Spätestens ab OS2.x war es dann dokumentiert, daß ein OpenLibrary("mathieeesingbas.library",0) eine task-spezifische Basisadresse liefert.
Das meinst Du... Ich habe gerade testweise auf meinem System von mehreren Tasks die math-libs öffnen lassen, und alle bekommen dieselbe Basisadresse.
Zitat:
Dieses Verhalten ist bereits auf der Developer-CD 1.1 von 1996 in den AmigaMails vol 1 dokumentiert, und die sind von 1990!
In den Dokumentationen der Bibliotheken steht, wie gesagt, bis AOS3.5 nichts dazu. Und die "AmigaMails" durchforsten zu müssen, um so etwas zu erfahren, kann man nicht Dokumentation nennen. Abgesehen davon, daß selbst Commodore im Vorwort zum Archiv sagt, daß man nicht alles, was da drin steht, für bare Münze nehmen sollte.

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

[ - Antworten - Zitieren - Direktlink - ]

10.07.2006, 19:17 Uhr

malte2
Posts: 148
Nutzer
@Holger:

tboeckel hat Recht, daß ist schon seit Ewigkeiten so. Ausnahme sind die Mathelibs von Drittanbietern und selbst bei den Originallibs hängt diese von der Konfiguration des Rechners ab. Und wenn Du was gegen OS3.9 hast so behalt doch deine Flames bitte für dich, daß gehört nicht in dieses Forum.

[ Dieser Beitrag wurde von malte2 am 10.07.2006 um 19:21 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

10.07.2006, 19:28 Uhr

Holger
Posts: 8116
Nutzer
@malte2:
Du kannst es drehen und wenden, wie Du willst, es stand nicht in der Dokumentation und auch in den erwähnte AmigaMails war nichts davon zu finden.

Ein Verhalten, das vielleicht bei ein paar Entwicklern hinter vorgehaltener Hand weitererzählt wird, ist keine Spezifikation.

Abgesehen davon, mag es vielleicht sogar so sein, daß irgendwer mal gesagt hat, daß die Library-Base nicht zwischen tasks weitergereicht werden darf. Trotzdem stehen in der aktuellen Fassung der Dokumentation plötzlich Dinge wie, daß man nicht mathieeesing... und mathieeedoub... gleichzeitig verwenden kann, weil es sonst Probleme gibt, sprich, die Berechnung in der falschen Genauigkeit durchgeführt werden könnte.

Ist das auch schon immer so gewesen?

Und daß man NULL zurückbekommen könnte, wenn man die Bibliothek ein zweites Mal öffnet (eine Katastrophe für einen Library-Entwickler, der nicht wissen kann, ob der Aufrufer die Bibliothek schon einmal geöffnet hat)...

Ist das auch schon immer so gewesen?

Und wenn das alles schon immer so war, daß math-libs innerhalb einer Bibliothek aufgrund dieser Einschränkungen praktisch nicht verwendet werden können, wieso hat es eine Woche gedauert, bis es jemanden aufgefallen ist?

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

[ - Antworten - Zitieren - Direktlink - ]

10.07.2006, 22:05 Uhr

tboeckel
Posts: 124
Nutzer
Zitat:
Original von Holger:
Wie Du vielleicht siehst, geht es hier um Library-Programmierung. Und in einer Library hat man keinen Einfluß darauf, was der Aufrufer noch so alles macht. Wenn Du Dir die Dokumentation mal durchliest, auch bzgl. dessen, was in diesem kleinen Zitat nicht erwähnt wurde, z.B. über das Verhalten bei mehrmaligen Öffnen und eben der Sache mit dem Mischen von single- und double precision, dann wird Dir vielleicht auch klar, das damit das Benutzen der math-libs aus einer Bibliothek unmöglich geworden ist.


Es ist das gute Recht von OpenLibrary() NULL zurückzuliefen, selbst wenn die gleich Bibliothek vorher bereits erfolgreich geöffnet wurde. Und wenn sich single und double precision gegenseitig ausschließen und dies von libOpen() der Mathe-Bibliotheken nicht korrekt erkannt wird, dann ist das ein Fehler der Bibliotheken.

Zitat:
Woher soll Bibliothek a wissen, ob eine Bibliothek b, vom gleichen Task geöffnet, eine andere math-Bibliothek öffnet?

Sie kann es nicht wissen. Aber dann darf ein Task auch nicht gleichzeitig beide Bibliothekstypen öffnen dürfen. Da fehlt dann halt eine entsprechende Abfrage, die das Öffnen scheitern läßt. Das wäre eine ganz legale Technik.

Zitat:
Das meinst Du... Ich habe gerade testweise auf meinem System von mehreren Tasks die math-libs öffnen lassen, und alle bekommen dieselbe Basisadresse.

Task-spezifische Basisadressen sind eine Möglichkeit. Aber wer sagt, denn daß die Mathe-Bibliotheken nicht noch einen anderen Weg benutzen, um verschiedene Tasks unterscheiden zu können. Sofern das überhaupt unter allen Umständen nötig ist. Wie gesagt, OpenLibrary() darf eine task-spezifische Adresse liefern, es muß aber nicht.

Zitat:
In den Dokumentationen der Bibliotheken steht, wie gesagt, bis AOS3.5 nichts dazu. Und die "AmigaMails" durchforsten zu müssen, um so etwas zu erfahren, kann man nicht Dokumentation nennen. Abgesehen davon, daß selbst Commodore im Vorwort zum Archiv sagt, daß man nicht alles, was da drin steht, für bare Münze nehmen sollte.

Hat denn überhaupt jemand behauptet, daß die Autodocs die Bibel sind, und daß alles, was da nicht drin steht, auch nicht sein darf? Auch die Autodocs sind nicht fehlerfrei und geben teilweise sehr unorthodoxe Beispiele mit auf den Weg. Die Dinger wurden seit Jahren nicht gepflegt. Es fehlen halt Erklärungen für Dinge, die man besser wissen sollte. Das OS4-SDK enthält teilweise sehr stark modernisierte Autodocs, welche dann auch eben solche Sachen endlich mal klarstellen. Aber es muß auch Leute geben, die so etwas dokumentieren. Das wurde halt jahrelang versäumt. Typische C=-Politik!


[ - Antworten - Zitieren - Direktlink - ]

10.07.2006, 22:07 Uhr

tboeckel
Posts: 124
Nutzer
Zitat:
Original von Holger:
Ein Verhalten, das vielleicht bei ein paar Entwicklern hinter vorgehaltener Hand weitererzählt wird, ist keine Spezifikation.

Abgesehen davon, mag es vielleicht sogar so sein, daß irgendwer mal gesagt hat, daß die Library-Base nicht zwischen tasks weitergereicht werden darf. Trotzdem stehen in der aktuellen Fassung der Dokumentation plötzlich Dinge wie, daß man nicht mathieeesing... und mathieeedoub... gleichzeitig verwenden kann, weil es sonst Probleme gibt, sprich, die Berechnung in der falschen Genauigkeit durchgeführt werden könnte.


Es steht auch nirgendwo, daß es erlaubt ist. Heißt das jetzt, daß beides falsch oder beides richtig ist?

Es gibt einen guten Grund, warum man das Ergebnis von OpenLibrary() und vergleichbaren Funktionen immer prüfen sollte. Nichts und niemand in einem Multitasking-System garantiert einem, daß immer alles korrekt funktioniert. Es gibt nur beschränkte Resourcen, und die müssen sich alle teilen. Es gibt mehr Gründe als nur die reine Abwesenheit einer Bibliothek, warum OpenLibrary() fehlschlagen kann. Der unmögliche Mix aus mathieeesing#? und mathieeedoub#? gehört nun mal dazu.

Zitat:
Und daß man NULL zurückbekommen könnte, wenn man die Bibliothek ein zweites Mal öffnet (eine Katastrophe für einen Library-Entwickler, der nicht wissen kann, ob der Aufrufer die Bibliothek schon einmal geöffnet hat)...

OpenLibrary() darf definitiv NULL zurückgeben, wenn es meint, daß eine Bibliothek (warum auch immer) nicht geöffnet werden konnte. Man erhält zwar keine weiteren Informationen, warum das Öffnen nicht geklappt hat, aber man darf auch nicht davon ausgehen, daß man jede Bibliothek unter allen Umständen mehr als 1x erfolgreich öfnnen kann.

Zitat:
Ist das auch schon immer so gewesen?

Zumindest so lange wie ich unter AmigaOS programmiere, und das sind mittlerweile knapp 20 Jahre.

Zitat:
Und wenn das alles schon immer so war, daß math-libs innerhalb einer Bibliothek aufgrund dieser Einschränkungen praktisch nicht verwendet werden können, wieso hat es eine Woche gedauert, bis es jemanden aufgefallen ist?

Vielleicht weil die Verwendung dieser Bibliotheken mittlerweile etwas ins Hintertreffen geraten ist? Kaum jemand benutzt noch einen nackten 68020 oder gar 68000. Alles unter 68040, besser noch unter 68060, ist zu langsam. Und die Dinger haben eine FPU, so daß man die Mathelibs nicht mehr braucht.

[ - Antworten - Zitieren - Direktlink - ]

10.07.2006, 23:19 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von tboeckel:
Es ist das gute Recht von OpenLibrary() NULL zurückzuliefen, selbst wenn die gleich Bibliothek vorher bereits erfolgreich geöffnet wurde. Und wenn sich single und double precision gegenseitig ausschließen und dies von libOpen() der Mathe-Bibliotheken nicht korrekt erkannt wird, dann ist das ein Fehler der Bibliotheken.

Also nochmal ganz langsam: wenn eine Bibliothek eine Einschränkung, die bis dato gar nicht existierte, nicht erzwingt, sondern einfach nur funktioniert, ist es ein Fehler der Bibliothek?
Zitat:
Sie kann es nicht wissen. Aber dann darf ein Task auch nicht gleichzeitig beide Bibliothekstypen öffnen dürfen. Da fehlt dann halt eine entsprechende Abfrage, die das Öffnen scheitern läßt. Das wäre eine ganz legale Technik.
Was soll das heißen, da fehlt eine Abfrage? Vor AOS3.9 gab es diese Einschränkung, daß man sie nicht gleichzeitig benutzen dürfe, überhaupt nicht. Wieso sollten diese Bibliotheken etwas abfragen?

Zitat:
Aber wer sagt, denn daß die Mathe-Bibliotheken nicht noch einen anderen Weg benutzen, um verschiedene Tasks unterscheiden zu können.
Wer?!
Na DU:
Zitat:
http://www.amiga-news.de/forum/thread.php?id=23201&BoardID=7#231681
Spätestens ab OS2.x war es dann dokumentiert, daß ein OpenLibrary("mathieeesingbas.library",0) eine task-spezifische Basisadresse liefert.


Und nachdem Du behauptest hast, daß es so "schon ab OS2.0" dokumentiert wäre, kommt jetzt das:
Zitat:
Hat denn überhaupt jemand behauptet, daß die Autodocs die Bibel sind, und daß alles, was da nicht drin steht, auch nicht sein darf? Auch die Autodocs sind nicht fehlerfrei und geben teilweise sehr unorthodoxe Beispiele mit auf den Weg.

Eben noch war es seit OS2.0 dokumentiert, daß es so ist, jetzt kann es so sein, muß aber nicht, und kann auch mal in der Dokumentation fehlen...

Was denn nun?

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

[ - Antworten - Zitieren - Direktlink - ]

10.07.2006, 23:37 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von tboeckel:
... Es gibt mehr Gründe als nur die reine Abwesenheit einer Bibliothek, warum OpenLibrary() fehlschlagen kann. Der unmögliche Mix aus mathieeesing#? und mathieeedoub#? gehört nun mal dazu.
...
Zitat:
Ist das auch schon immer so gewesen?

Zumindest so lange wie ich unter AmigaOS programmiere, und das sind mittlerweile knapp 20 Jahre.

Aha, Du weißt das also schon seit 20 Jahren. Und wie kam dann folgendes Posting zustande?!:
Zitat:
http://www.amiga-news.de/forum/thread.php?id=23201&BoardID=7#231681
Lies diesen Satz noch mal mit ganz viel Verstand von vorne bis hinten durch. Da steht nichts davon drin, daß man die mathieeesing#? und die mathieeedoub#? nicht gleichzeittig verwenden darf.


Holla, da war das angeblich seit 20 Jahren schon immer so gewesene Faktum, daß man diese Bibliotheken nicht miteinander Mischen darf, noch eine Fehlinterpretation meinerseits, die durch "Lesen mit Verstand" zu beheben wäre.

Du erwirbst verdammt schnell eine 20-Jahre Erfahrung, in weniger als 4 Stunden, das ist beachtlich...
Entschuldige, wenn ich da nicht mithalten kann, für mich sind heute erfahrene Dinge halt neu und nicht seit zwanzig Jahren bekannt...

Zitat:
Zitat:
Und wenn das alles schon immer so war, daß math-libs innerhalb einer Bibliothek aufgrund dieser Einschränkungen praktisch nicht verwendet werden können, wieso hat es eine Woche gedauert, bis es jemanden aufgefallen ist?
Vielleicht weil die Verwendung dieser Bibliotheken mittlerweile etwas ins Hintertreffen geraten ist? Kaum jemand benutzt noch einen nackten 68020 oder gar 68000. Alles unter 68040, besser noch unter 68060, ist zu langsam. Und die Dinger haben eine FPU, so daß man die Mathelibs nicht mehr braucht.

Lustigerweise entstehen diese jetzt dokumentierten Einschränkungen aber erst durch die Verwendung der realen FPU. FP-Code, der die Operationen per Integer-Unit nachbildet, hat diese ganzen Einschränkungen gar nicht erst.

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

[ - Antworten - Zitieren - Direktlink - ]

10.07.2006, 23:46 Uhr

Holger
Posts: 8116
Nutzer
Mal wieder konstruktiv werden...
@Micha1701:
Wie Du jetzt erfahren hast, unterliegen die math-Bibliotheken erheblichen Einschränkungen in der Verwendung. Also am Besten ist es, wenn es für Dich nicht übermäßig kompliziert werden soll, wenn Du ausschließlich FPU-Versionen, also einmal für 68881 und einmal für 68040 erzeugst. Dann solltest Du natürlich auch nicht die mieee.lib benutzen, sondern die jeweils richtige fpu-Version., m881 und m040.

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

[ - Antworten - Zitieren - Direktlink - ]

11.07.2006, 07:19 Uhr

Micha1701
Posts: 938
Nutzer
OK, ich werd mal versuchen eine andere lib zu verwenden um die Math.libs zu umgehen.

Aber mal abgesehen von meinem Problem, kann es doch gar nicht sein, daß sich die MathSing und MathDoub Libraries gegenseitig ausschließen. Immerhin hat z.B. die DoubTrans library die Funktion ein double in ein float umzuwandeln. Und was soll man schon mit einem float, wenn man es nicht mit der MathSing Library bearbeiten kann?

In vbcc will z.B. die IEEE.lib sowieso alle 4 Math Libraries öffnen. Wie auch sonst soll die Lib float und double Operationen anbieten?
--
:boing: Micha :boing:

http://www.Silicon-Wizards.com

[ - Antworten - Zitieren - Direktlink - ]

11.07.2006, 09:09 Uhr

tboeckel
Posts: 124
Nutzer
Zitat:
Original von Holger:
Zitat:
... Es gibt mehr Gründe als nur die reine Abwesenheit einer Bibliothek, warum OpenLibrary() fehlschlagen kann. Der unmögliche Mix aus mathieeesing#? und mathieeedoub#? gehört nun mal dazu.
...
Zitat:
Ist das auch schon immer so gewesen?

Zumindest so lange wie ich unter AmigaOS programmiere, und das sind mittlerweile knapp 20 Jahre.

Aha, Du weißt das also schon seit 20 Jahren. Und wie kam dann folgendes Posting zustande?!:
Zitat:
http://www.amiga-news.de/forum/thread.php?id=23201&BoardID=7#231681
Lies diesen Satz noch mal mit ganz viel Verstand von vorne bis hinten durch. Da steht nichts davon drin, daß man die mathieeesing#? und die mathieeedoub#? nicht gleichzeittig verwenden darf.



Die 20 Jahren bezogen sich auf das erlaubte Fehlschlagen von OpenLibrary(). Das war schon immer so. Ich hätte wohl besser noch ein "scheinbar" in dem darauf folgenden Satz schreiben sollen.

Außerdem bezog sich meine Antwort auf das Verwenden der gleichen Basisadresse in unterschiedlichen Tasks. Bis dahin war nie von einem gewollten Mix aus single und double precision die Rede.

[ - Antworten - Zitieren - Direktlink - ]

11.07.2006, 09:38 Uhr

tboeckel
Posts: 124
Nutzer
Zitat:
Also nochmal ganz langsam: wenn eine Bibliothek eine Einschränkung, die bis dato gar nicht existierte, nicht erzwingt, sondern einfach nur funktioniert, ist es ein Fehler der Bibliothek?

Ob sie existierte oder nicht kann ich nicht sagen. Diese Beschränkung war wohl nur den C=-Entwicklern wirklich klar, bzw sie sind davon ausgegangen, daß niemand auf die Idee kommt single und double precision zu mischen. Ich wußte bislang auch nur, daß die Basisadressen nicht von unterschiedlichen Tasks benutzt werden dürfen.

Nur, wenn sich Bibliothek A und B gegenseitig ausschließen (warum auch immer), aber weder A noch B prüfen, ob der jeweils andere Part aktiv ist, und trotzdem "so in etwa" funktionieren, dann ist das definitv ein Fehler, weil ein normaler Benutzer zunächst nicht unbedingt etwas davon bemerkt. Und auf der Seite des Entwicklers sind solche Fehler zu weilen unmöglich nachzuvollziehen, weil sie in diesem Fall sehr stark vom verwendeten Prozessor abhängen.

Bei den Mathebibliotheken mag man als Ausrede anbringen, daß ja nur die Rundung falsch wird, aber selbst das kann unvorhersehbare Folgen haben, weswegen so etwas von Anfang an verhindert werden sollte.

Zitat:
Zitat:
Sie kann es nicht wissen. Aber dann darf ein Task auch nicht gleichzeitig beide Bibliothekstypen öffnen dürfen. Da fehlt dann halt eine entsprechende Abfrage, die das Öffnen scheitern läßt. Das wäre eine ganz legale Technik.
Was soll das heißen, da fehlt eine Abfrage? Vor AOS3.9 gab es diese Einschränkung, daß man sie nicht gleichzeitig benutzen dürfe, überhaupt nicht. Wieso sollten diese Bibliotheken etwas abfragen?

Weil sie sich gegenseitig ausschließen, zumindest dann, wenn sie auf einem Prozessor mit FPU und im gleichen Task verwendet werden. Diese Eigenschaft ist mir allerdings auch erst seit dieser Diskussion bekannt. Bislang wußte ich nur von der task-bezogenen Benutzung.

Zitat:
Zitat:
Aber wer sagt, denn daß die Mathe-Bibliotheken nicht noch einen anderen Weg benutzen, um verschiedene Tasks unterscheiden zu können.
Wer?!
Na DU:
Zitat:
http://www.amiga-news.de/forum/thread.php?id=23201&BoardID=7#231681
Spätestens ab OS2.x war es dann dokumentiert, daß ein OpenLibrary("mathieeesingbas.library",0) eine task-spezifische Basisadresse liefert.



Wo ist der Widerspruch? Es ist die Aufgabe der Mathbibliotheken verschiedene Tasks unterscheiden zu können. Wie sie das machen, braucht niemanden zu interessieren. Hauptsache ist sie machen es korrekt. Ich gebe aber zu, daß ich den Autodocs und der gesamten weiteren Dokumentation auf den Developer-CDs eine Aussage unterstellt habe, die es lange nicht bzw nie so richtig gegeben hat. Mein Fehler.

Zitat:
Und nachdem Du behauptest hast, daß es so "schon ab OS2.0" dokumentiert wäre, kommt jetzt das:
Zitat:
Hat denn überhaupt jemand behauptet, daß die Autodocs die Bibel sind, und daß alles, was da nicht drin steht, auch nicht sein darf? Auch die Autodocs sind nicht fehlerfrei und geben teilweise sehr unorthodoxe Beispiele mit auf den Weg.

Eben noch war es seit OS2.0 dokumentiert, daß es so ist, jetzt kann es so sein, muß aber nicht, und kann auch mal in der Dokumentation fehlen...

Was denn nun?


Ok, ich gebe zu, daß es nicht in den Autodocs dokumentiert ist. Das wurde erst mit OS3.9/OS4 nachgeholt. Es ist auch nicht in den Autodocs dokumentiert, daß eine Basisadresse nicht von >= 2 Tasks gleichzeitig benutzt werden darf. Das steht nur in einigen wenigen Beispielprogrammen in einer Randnotiz. Ich habe diese Information irgenwann in den letzten Jahren aufgeschnappt und sie seit dem verinnerlicht. Die Tatsache, daß es nicht explizit dokumentiert ist, ist mir auch erst jetzt aufgefallen. Es ist halt irgendwie "allgemein bekannt", daß manche Bibliotheken nur task-gebunden benutzt werden dürfen. Wenn man dieses "Wissen" hat, dann kontrolliert man es nicht jedes Mal, sondern benutzt es einfach. Mein Fehler.

[ - Antworten - Zitieren - Direktlink - ]

11.07.2006, 12:29 Uhr

Gazelle
Posts: 151
Nutzer
Um auf Deine Frage zurückzukommen:
Zitat:
Original von Micha1701:
Wie muß ein Funktionsaufruf in der SFD Datei deklariert werden, damit man nicht mit einem Array aus TagItems sondern mit einer variabel langen Liste aus TagItems aufrufen kann? Also daraus statt einem amicall ein tagcall entsteht?


Soweit mir bekannt, programmiert man in der Library selbst nur die Version mit "struct TagItem *tags".

Im SFD definiert man dann einen Alias mittels:

FOO FunctionA(struct BAR* bar, struct TagItem * tags) (a0,a1)
==varargs
FOO Function(struct BAR* bar, Tag tags, ...) (a0,a1)


Mittels FDpragma (oder ähnlichem) lässt man dann die entsprechenden pragmas/clib/inlines und Konsorten für den jeweiligen Compiler erzeugen.

hth, Bernd

[ - Antworten - Zitieren - Direktlink - ]

11.07.2006, 16:15 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Micha1701:
OK, ich werd mal versuchen eine andere lib zu verwenden um die Math.libs zu umgehen.

Wie gesagt, meine Empfehlung lautet, sich nur auf die FPU-Version zu konzentrieren. Die benutzt, wenn Du sie richtig erzeugst, keine math-Bibliotheken (und braucht auch keine).
Zitat:
Aber mal abgesehen von meinem Problem, kann es doch gar nicht sein, daß sich die MathSing und MathDoub Libraries gegenseitig ausschließen. Immerhin hat z.B. die DoubTrans library die Funktion ein double in ein float umzuwandeln. Und was soll man schon mit einem float, wenn man es nicht mit der MathSing Library bearbeiten kann?

In vbcc will z.B. die IEEE.lib sowieso alle 4 Math Libraries öffnen. Wie auch sonst soll die Lib float und double Operationen anbieten?


Wie schon gesagt, das Primärziel der math-Bibliotheken besteht darin, FPU-Funktionen auf nicht-FPU Rechnern zur Verfügung zu stellen. Und auf diesen dürfte es diese Probleme mit der Präzision nicht geben, weil dieser Code von keinem globalen Status abhängt.

Eigentlich ist auch für FPU-Versionen dieser Bibliotheken nicht nachzuvollziehen, warum es diese Einschränkung geben sollte. Die FPU selber rechnet eh ausschließlich mit 80Bit-Genauigkeit, zumindest auf 68k-Systemen. Und die Operationen dieser Bibliotheken sind so grundlegend, daß es gar keine Zwischenergebnisse geben dürfte, die einer Rundung unterliegen.

Die "korrekte Initialisierung der FPU", die die math-Bibliotheken pro Task durchführen müssen, ist auch nicht nachzuvollziehen. Programme, die die FPU ohne Zuhilfename externer Bibliotheken benutzen, müssen auch nichts vorher Initialisieren. Anno Commodore hatten einige Entwickler noch die Möglichkeit als externe Erweiterungen eingebundener FPUs im Hinterkopf, so etwas hat es IMHO in der Realität aber nie gegeben. Außer, wenn man den ppc als neuartige FPU in Betracht zieht, aber das wäre ja eher ein Indiz dafür, daß es diese Eigenart früher nicht gegeben hat.

Wie gesagt, diese Einschränkung findet sich in der Dokumentation erst seit AOS3.9, vorher gar nicht. Selbst zur non-shareable LibBase findet sich auch in den erwähnten anderen Quellen AmigaMail, etc. dazu nichts -- bzw. genau ein einziger Eintrag in einem Kommentar in einem source-code zum Thema DOS/Reentrant Code, allerdings ist dieser Sourcecode mit so Späßen wie self-modifying code nicht wirklich als Referenz in Sachen Amiga-Programmierung zu betrachten.

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

[ - Antworten - Zitieren - Direktlink - ]

11.07.2006, 16:52 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von tboeckel:
Ob sie existierte oder nicht kann ich nicht sagen. Diese Beschränkung war wohl nur den C=-Entwicklern wirklich klar, bzw sie sind davon ausgegangen, daß niemand auf die Idee kommt single und double precision zu mischen.

Wie Micha1701 schon richtig anmerkte, stellen die Bibliotheken von sich aus Konvertierungsfunktionen zwischen den beiden Datentypen zur Verfügung. Offensichtlich ist man sehr wohl davon ausgegangen, daß man hin und wieder beide Datentypen braucht.
Zitat:
Nur, wenn sich Bibliothek A und B gegenseitig ausschließen (warum auch immer), aber weder A noch B prüfen, ob der jeweils andere Part aktiv ist, und trotzdem "so in etwa" funktionieren, dann ist das definitv ein Fehler, weil ein normaler Benutzer zunächst nicht unbedingt etwas davon bemerkt. Und auf der Seite des Entwicklers sind solche Fehler zu weilen unmöglich nachzuvollziehen, weil sie in diesem Fall sehr stark vom verwendeten Prozessor abhängen.
Vollkommen richtig, wenn sie sich gegenseitig ausschließen, sollten sie das auch erzwingen. Mit vbcc übersetzte Programme (für andere compiler gilt das höchstwahrscheinlich auch), funktionieren dann überhaupt nicht mehr, wenn sie automatisch beide Bibliothekstypen öffnen.

Das wäre natürlich absurd, denn um nach einer Berechnung mit der ...singbas oder ...singtrans den SP Wert nach DP zu konvertieren, muß man die ...doubtrans öffnen, die die nötige Funktion enthält. Aber das würde nach der Logik dann fehlschlagen...

Zitat:
Weil sie sich gegenseitig ausschließen, zumindest dann, wenn sie auf einem Prozessor mit FPU und im gleichen Task verwendet werden. Diese Eigenschaft ist mir allerdings auch erst seit dieser Diskussion bekannt. Bislang wußte ich nur von der task-bezogenen Benutzung.
Und sie dürfte für die meisten Programmierer ziemlich neu sein...

Zitat:
Wo ist der Widerspruch? Es ist die Aufgabe der Mathbibliotheken verschiedene Tasks unterscheiden zu können. Wie sie das machen, braucht niemanden zu interessieren. Hauptsache ist sie machen es korrekt. Ich gebe aber zu, daß ich den Autodocs und der gesamten weiteren Dokumentation auf den Developer-CDs eine Aussage unterstellt habe, die es lange nicht bzw nie so richtig gegeben hat. Mein Fehler.
Wenn es die "Aufgabe der Mathbibliotheken, verschiedene Tasks unterscheiden zu können" wäre, bräuchte sich ja der Programmierer ja nicht mehr durch mehrfaches Öffnen der Bibliotheken darum zu kümmern.
Allerdings gibt es noch nicht einmal eine erkennbare Notwendigkeit für diese Bibliotheken, verschiedene Tasks zu unterscheiden.
Die Dokumentation (also die neue) spricht auch nur von einer Notwendigkeit des Durchlaufens des Initialisierungscodes, die Basisadresse bleibt sogar erklärtermaßen immer die gleiche.

Zitat:
Ok, ich gebe zu, daß es nicht in den Autodocs dokumentiert ist. Das wurde erst mit OS3.9/OS4 nachgeholt. Es ist auch nicht in den Autodocs dokumentiert, daß eine Basisadresse nicht von >= 2 Tasks gleichzeitig benutzt werden darf. Das steht nur in einigen wenigen Beispielprogrammen in einer Randnotiz. Ich habe diese Information irgenwann in den letzten Jahren aufgeschnappt und sie seit dem verinnerlicht.
Ich habe nur eine einzige Randnotiz gefunden, und zwar in einem haarsträubenden Code zum Thema DOS/Reentrant Code. Ob ich eine solche Randnotiz verinnerlicht hätte, wenn ich den Code früher gesehen hätte, weiß ich nicht...
Zitat:
Die Tatsache, daß es nicht explizit dokumentiert ist, ist mir auch erst jetzt aufgefallen. Es ist halt irgendwie "allgemein bekannt", daß manche Bibliotheken nur task-gebunden benutzt werden dürfen. Wenn man dieses "Wissen" hat, dann kontrolliert man es nicht jedes Mal, sondern benutzt es einfach. Mein Fehler.
Vergeben und vergessen. Man greift natürlich auf eine Menge Wissen aus dem Bauch heraus zu, ohne jedes Mal alles zu hinterfragen. Mir ging es hier um eine Verkomplizierung der Programmierung, die in dieser Form offensichtlich bislang nicht einmal den compiler-Entwicklern bekannt war. Und an der Stelle muß ich einfach hinterfragen, weil es nicht nur bislang nicht so dokumentiert war, sondern auch keine verständliche Notwendigkeit dahinter steht. Und wenn neue, geänderte Spezifikationen zusammen mit neuen Implementierungen auftauchen, ist das für mich ein Warnsignal. Dieses neue Verhalten dürfte, wenn es so umgesetzt wird, einige Kompatiblitätsprobleme mit sich bringen, und man kann nicht sagen, daß die Anwendungsprogrammierer Schuld seien, weil sie irgendetwas schon immer so spezifiziertes nicht beachtet hätten.

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

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 13:27 Uhr

woop
Posts: 67
Nutzer
Hallo,

ich wollte hier zu der Problematik "mathe-Bibliotheken pro Task öffnen" hinzufügen, dass das nicht daran liegt, dass man beim OpenLibrary() für jeden Task eine eigene Basisadresse kriegt (was schlimm wäre, dann wäre die Library ja mehrfach im Speicher) sondern daran, dass diese Bibliotheken unter Umständen die Task-Struktur benutzen um sich interne Daten zu merken. So stehts zumindest in den RKMs für die 1.3er Version.

Gruß,
woop

[ Dieser Beitrag wurde von woop am 12.07.2006 um 13:28 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 13:41 Uhr

grunz
Posts: 4
Nutzer
@woop:

Entschuldige, aber das ist ja nun vollkommener Unfug. Natürlich werden die Bibliotheken mehrfach im Speicher vorgehalten, das erfordert ja schon der korrekte Umgang innerhalb der Prozessverwaltung mit dem Speicher (Stichwort: Speicherschutz, wenn dir das was sagt ;-)).

Auf die RKMs würde ich mich auch nicht unbedingt berufen, ich hab jahrelang mit denen gearbeitet und weiß nur zu gut, dass da auch jede Menge falsche oder unvollständige Informationen drin stehen. Also glaub nicht alles, was du da eben schnell nachliest. Eigene Erfahrung ist da auf jeden Fall deutlich mehr wert...


[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 13:48 Uhr

woop
Posts: 67
Nutzer
@grunz

Okay, ich habe die Angelegenheit etwas vereinfacht, für den User kann es tatsächlich so aussehen als würden die Libraries mehrfach im Speicher liegen, tatsächlich wird der Code aber bidirektional gespeichert, was der Prozessverwaltung genügt.

Außerdem wurden die RKMs von Jay Miner persönlich diktiert, was da drinnen steht geschieht! Da kann sich die eigene Erfahrung nur in ein finsteres Eck verkrümeln! :sex:


[ Dieser Beitrag wurde von woop am 12.07.2006 um 13:53 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 14:05 Uhr

grunz
Posts: 4
Nutzer
örx, doppeltes posting... sry! :glow:

[ Dieser Beitrag wurde von grunz am 12.07.2006 um 14:09 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 14:07 Uhr

grunz
Posts: 4
Nutzer
Zitat:
Original von woop:
Okay, ich habe die Angelegenheit etwas vereinfacht, für den User kann es tatsächlich so aussehen als würden die Libraries mehrfach im Speicher liegen, tatsächlich wird der Code aber bidirektional gespeichert, was der Prozessverwaltung genügt.


Wie bitte? Ohne jetzt gleich persönlich werden zu wollen, aber was du da jetzt schreibst ist noch unsinniger als das, was du oben geschrieben hattest. Was soll denn bidirektional gespeichert sein? Hälst du den Speicher für eine Art Centronics-Schnittstelle? ?(

Zitat:
Außerdem wurden die RKMs von Jay Miner persönlich diktiert, was da drinnen steht geschieht! Da kann sich die eigene Erfahrung nur in ein finsteres Eck verkrümeln! :sex:

Ja, genau. Wovon träumst Du nachts? Dass die eigene Erfahrung, so man sie denn hat, mindestens genauso viel Wert ist wie eine schludrig hingeschriebene, fehler- und lückenhafte Doku -- und ich rede hier jetzt explizit von Kickstart 1-er Zeiten --, das ist ja wohl offensichtlich. Natürlich muss man das, was man da herausgefunden hat, auch dem Kontext der technischen Gegebenheiten richtig zuordnen können, und möglicherweise gelingt das dem einen besser, dem anderen schlechter... :P

Von Jay Miner wurde da gar nix diktiert... Du glaubst doch nicht im Ernst, dass der gute Mann dafür Zeit oder Lust hatte... Das ist schon eine reichliche naive Ansicht. Das wurde irgendwie zusammengeklopft und auf den Markt geworfen, fertig.

Ps. Was soll denn der Smilie? Wird das eine Anmache?

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 14:18 Uhr

Holger
Posts: 8116
Nutzer
@woop, grunz:
Habt "ihr" euch echt nur für diesen Unsinn extra hier angemeldet?

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

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 14:21 Uhr

woop
Posts: 67
Nutzer
Zitat:
Original von grunz:

Wie bitte? Ohne jetzt gleich persönlich werden zu wollen, aber was du da jetzt schreibst ist noch unsinniger als das, was du oben geschrieben hattest. Was soll denn bidirektional gespeichert sein? Hälst du den Speicher für eine Art Centronics-Schnittstelle? ?(


Tut mir leid, ich werde versuchen langsamer zu sprechen: Also bidirektional gepeichert heißt, dass man die Bits im Speicher aus mehreren Richtungen auslesen kann. Damit kann die MMU der CPU vorgaukeln ein und derselbe Speicher sei an mehreren Stellen im Adressraum vorhanden. Die Prozessverwaltung muss sich dann nur noch um die richtige Berechnung diverse Offsets kümmern und das wars.

Zitat:
Ja, genau. Wovon träumst Du nachts? Dass die eigene Erfahrung, so man sie denn hat, mindestens genauso viel Wert ist wie eine schludrig hingeschriebene, fehler- und lückenhafte Doku -- und ich rede hier jetzt explizit von Kickstart 1-er Zeiten --, das ist ja wohl offensichtlich. Natürlich muss man das, was man da herausgefunden hat, auch dem Kontext der technischen Gegebenheiten richtig zuordnen können, und möglicherweise gelingt das dem einen besser, dem anderen schlechter... :P

Von Jay Miner wurde da gar nix diktiert... Du glaubst doch nicht im Ernst, dass der gute Mann dafür Zeit oder Lust hatte... Das ist schon eine reichliche naive Ansicht. Das wurde irgendwie zusammengeklopft und auf den Markt geworfen, fertig.


Wenn es nur so geschehen wäre mit dem "auf den Markt geworfen", da kann ich dir Geschichten erzählen:
Als ich meine ersten RKMs 1874 kaufen wollte hieß es immer wieder nicht verfügbar. Ich habe mich daraufhin direkt an einen Händler in den U.S.A. gewandt, der meinte er könne mir die Bücher innerhalb weniger Monate für nur $474.399,- besorgen worauf ich dieses vermeintliche Schnäppchen sofort bei ihm bestellt habe. Achja, dieser Händler das waren noch Zeiten, wir mailen uns heute noch ab und zu und erzählen uns gegenseitig davon, eine tolle Zeit war das damals. Jedenfalls bekam er nach 8 Monaten genau ein Exemplar, welches er leider schon einem anderen Kunden versprochen hatte. Ich konnte ihn zum Glück überreden, dass er mir die Autodocs per Telefon diktiert hat.
Als wir dass dann fertig hatten, bemerkte ich leider einen Übertragungsfehler bei der Beschreibung der layers.library nicht sofort. Menschenskind was haben wir damals den Bug gesucht. Ich kriege noch heute Mails von Kollegen damals, die mir von dieser tollen Zeit damals erzählen, aber davon berichte ich, wenn wir mal mehr Zeit haben.

Gruß,
woop

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 14:24 Uhr

woop
Posts: 67
Nutzer
Zitat:
Original von Holger:
@woop, grunz:
Habt "ihr" euch echt nur für diesen Unsinn extra hier angemeldet?


Eigentlich nicht, du wirst hoffentlich zugeben müssen, dass zumindest Beitrag eins von woop thread-dienlich ist ;)

Gruß,
woop (nein, ich bin wirklich nicht grunz)

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 14:38 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von woop:
Eigentlich nicht, du wirst hoffentlich zugeben müssen, dass zumindest Beitrag eins von woop thread-dienlich ist ;)


Er deckt sich inhaltlich zumindest mit den Teilen, die in die 3.9-autodocs Einzug gehalten haben. Nur, warum in den 2.0-RKRMs davon nichts zu finden ist, bleibt unverständlich.

Kannst Du Kapitel/Seitenzahlen nennen? Vielleicht funktioniert ja nur die Stichwortsuche nicht...

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

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 14:43 Uhr

woop
Posts: 67
Nutzer
Zitat:
Original von Holger:

Er deckt sich inhaltlich zumindest mit den Teilen, die in die 3.9-autodocs Einzug gehalten haben. Nur, warum in den 2.0-RKRMs davon nichts zu finden ist, bleibt unverständlich.

Kannst Du Kapitel/Seitenzahlen nennen? Vielleicht funktioniert ja nur die Stichwortsuche nicht...


Ich habe die RKMs gerade nicht zur Hand aber das steht - meine ich - in einer Note recht zu Beginn des Kapitels über die math-Libraries in den Libraries & Devs.


Gruß,
woop

[ - Antworten - Zitieren - Direktlink - ]

12.07.2006, 14:54 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von woop:
Ich habe die RKMs gerade nicht zur Hand aber das steht - meine ich - in einer Note recht zu Beginn des Kapitels über die math-Libraries in den Libraries & Devs.


Danke, habs gefunden, lag wirklich an der Stichwortsuche.

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

[ - Antworten - Zitieren - Direktlink - ]


1 -2- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Wie erstellt man eine Library in C? [ - Suche - Neue Beiträge - Registrieren - Login - ]


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