[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Der_Wanderer:

Deinen Angaben nach zu schließen solltest Du mit C++-Code genauso glücklich werden können wie mit C-Code. Ich nehme nicht an, daß Du gcc2.7 oder was ähnlich vorsintflutliches installiert hast, oder? Mit z.B. 2.95.2 oder höher könntest Du auch "härtere" Geschichten relativ problemlos übersetzen, von daher mußt Du Dir wohl keine Sorgen machen.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

code:

---

/* free a string */
void str_free(str &string) {
  if (string) {
    free(strH(string));
    string=NULL;
  }
}

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
In dem Code sind erstmal keinerlei OS Abhängigkeiten drin.
Das einzige was ich brauche ist Datei I/O und Speicher allocieren.

---

Zitat:

---

code:

---

/* free a string */
void str_free(str &string) {
  if (string) {
    free(strH(string));
    string=NULL;
  }
}

---

Geht das unter Amiga ohne Probleme? Ich möchte auch keine rießen Makefile Orgien, damit kenne ich mich gar nicht aus. Unter Windows benutze ich Visual Studio, da wird man von sowas gottseidank verschont.

---

Zitat:

---

Am Ende soll das auf dem Amiga eine Shared Library werden. Unter Windows eine DLL.

---

Zitat:

---

GCC habe ich gcc version 2.95.3.

Wenn ich C++ nehme, dann sollte ich am besten alle source files C++ machen und nicht mischen, oder? Unter VS ist das kein Problem, aber "per Hand" wäre das wohl komplizierter zu linken(?).

---

Hängt davon ab, wie Du das compilierst. Schau Dir mal die Doku zu gcc/g++ an. Da findest Du auch einiges über das "Mischen" von Code und die Linkerproblematik.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Ich kann mich erinnern, als ich mal eine Library compiliert habe, dass es Probleme mit fopen, printf etc. gab, irgendwas mit libnix in der Commandozeile war notwendig.

---

Zitat:

---

Ist aber lange her, letztendlich hatte ich alles über AmigaOS API gemacht, aber das will ich eigentlich vermeiden.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
@whose
> So triviale Sachen gehen ohne Probleme,
Also laut Holger geht das dann wohl doch nicht ohne Probleme?

---

Erst, wenn Du das in eine Amiga shared library "verpflanzt". Aber auch hier gilt, was akl schon ausführte. Kurz gesagt: "Hängt davon ab"

Ich dachte, es ginge erst einmal primär um das Funktionieren dieses Codes an sich, ohne Spezialitäten wie "ich bastel eine Amiga shared library daraus". Dazu habe ich aber auch was gesagt Spätestens, wenn Du eine shared library/DLL daraus machen willst, wirst Du um die #ifdef/makefile-Orgien nicht herum kommen. Das geht ja schon bei Dingen los, die erst einmal gar nichts mit Deinem Code zu tun haben, Init usw.

Bei Libraries, die systemabhängig sind, gibt es eigentlich immer Probleme mit den Funktionen der C-Linker-Library, sofern diese bestimmte Voraussetzungen nicht erfüllt. Es gibt Gründe für die "Erfindung" von clib2/newlib und wie sie alle heißen...
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von akl:
@Holger:

>Die C-Funktionen sind grundsätzlich nicht für den Einsatz in einer
>Amiga-Bibliothek geeignet

Das hängt davon ab, welchen Compiler mit welcher C-Laufzeitumgebung man nutzt, welche Funktionen man davon nutzt und ob und wie man sicherstellt, dass der Code "threadsafe" bleibt.

So verallgemeinert ist die Aussage nicht richtig.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Also, darf ich nun "sprintf" oder "fopen" in einer Shared Lib benutzen oder nicht?

---

Zitat:

---

Unter Windows und Linux scheint das kein Problem zu sein. Haben dort die DLLs/SOs für jede offene Instanz eigene Addressräume, und die Funktionen müssen deshalb nicht thread-safe sein?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Also, darf ich nun "sprintf" oder "fopen" in einer Shared Lib benutzen oder nicht?
Sieht so aus, als bräuchte ich dafür eine spezielle Runtime Linkerlib.

---

Zitat:

---

Nachtrag:
Unter Windows und Linux scheint das kein Problem zu sein. Haben dort die DLLs/SOs für jede offene Instanz eigene Addressräume, und die Funktionen müssen deshalb nicht thread-safe sein? Oder ist die Amiga Implementation der C-Runtime einfach crappy?

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Hm, das wird komplizierter als ich dachte. Soll ich nun doch besser C nehmen?

---

Zitat:

---

Also wenn ich mich zusammenreise, dann komme ich mit

fopen()
fread()
fwrite()
fseek()
ftell()
fclose()
malloc()
free()

aus. Wobei Konsole Output schon hilfreich wäre, also printf().

---

Vergesse printf() ganz, ganz schnell. Ich weiß nicht warum so viele Programmierer printf() innerhalb einer Shared-Lib verwenden möchten.
1) printf() ist nicht thread-safe; es arbeitet intern mit Puffern und Variablen auf Dateiebene (global).
2) das AmigaDOS erlaubt es nicht, dass Prozesse File-Handles untereinander austauschen; jeder Prozess ist angehalten, die File-Handles per Instanz zu reservieren und wieder freizugeben.
3) printf() setzt zwingend einen Startup-Code voraus; dieser entfällt beim Schreiben einer Amiga-Shared-Lib.
4) printf() ist eine C-Funktion, unter C++ ist das Äquivalent 'cout'. (SCNR )

Wenn Du die Ausgaben nur zur Fehlersuche benötigst, verwende kprintf() (OS3, MorphOS, AROS) oder DebugPrintF() (OS4) und starte vorab Sushi oder Sashimi.

Zitat:

---

Alles andere ist rein algorithmisch und kann re-entrant oder zumindest thread-safe implementiert werden.
Wenn das nicht geht, wird es schwierig.

---

Zitat:

---

Wenn ich für diese Funktionen AmigaOS API nehmen würde, dann sollte es doch eigentlich funktionieren, oder nicht?

---

Zitat:

---

Was hat man denn in der C Runtime "verbrochen", dass es nicht mehr thread-safe ist?
Bei printf() kann ich das noch verstehen, denn da müsste man sich erst den Handle auf den stdout holen. Aber die anderen Sachen sollten doch funktionieren, oder übersehe ich da etwas?

---

Zitat:

---

Es ist stark abhängig von diesen pragmas/clib/inlines und der Link-Libs ob die printf, fopen etc richtig funktionieren.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Ok, also ich fasse zusammen:

Plain C verwenden, ohne jegliche Runtime. Also absolute Askese, das habe ich befürchtet.

Das lädt nicht gerade zum Entwickeln für den Amiga ein. Ich verstehe eigentlich gar nicht warum, steckt doch hinter einem fopen() letztendlich ein Open() der dos.library, was re-entrant ist. Irgendwo beim "einpacken" hat da doch jemand Bockmist gebaut.

---

Was hat es denn mit Amiga zu tun, daß die C-Runtimes oftmals nicht wirklich für Systementwicklung (und zu diesem Themenbereich gehören shared libraries auch) taugen und ein ziemlicher Aufwand drumherum betrieben werden muß, damit das doch "irgendwie" funktioniert?

Das Problem ist die Abhängigkeit der C-Standardfunktionen von bestimmten Kontexten des Runtime-Teils (startup code), die sich im AmigaOS halt nicht so einfach "mal eben teilen" lassen, wie schon erwähnt.

Es ist dabei ziemlich unerheblich, ob zum Schluß ein Aufruf einer OS-Funktion daraus kondensiert oder ob der Entwickler der C-Runtime wirklich alles selbst macht. Die Abhängigkeit der C-Standard-Funktionen von bestimmten Kontexten ist erst auf einer höheren Ebene gegeben, nicht zwangsläufig auf Ebene des Betriebssystems.

Kurz gesagt: AmigaOS kann nix dafür, daß C-Standardfunktionen so funktionieren, wie sie funktionieren

Du könntest aber zum Beispiel, wenn Du für Windows schon eine DLL bauen willst, für die Amiga68k-Fassung Linker-Libraries bauen, damit umgehst Du das Problem mit den vom Startup-Code abhängigen Funktionen quasi im Spaziergang. Nachteil ist halt, daß dann jedes Programm, daß Deine Funktionen nutzt, diese im Code mitschleppen muß. Wobei das für 68k-Code nicht wirklich ein Problem darstellen dürfte, da der Code oft recht klein ausfällt. Gerade bei so simplen Funktionen wie die, die Du hier gezeigt hattest. Kleiner als die Windows-Pendants dürften die Programme daher alle Male sein

Oder eben halt ein wenig #ifdef-Akrobatik und Verzicht auf printf() und Konsorten. Machbar ist das durchaus.

Davon mal ab, für OS4 z.B. hat man einen den DLLs extrem ähnlichen Mechanismus eingeführt, und irgendwo ist das ja immer noch ein bißchen Amiga...
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

@Der_Wanderer:

Es hat mich jetzt mal gerade eine Minute gekostet, um herauszufinden, dass "clib2" thread-safe ist, also das ist, wonach Du suchst. Allerdings existiert "clib2" auf Source-Forge nur für AmigaOS3/4 als Release. Wie viel Arbeit es ist diese C-Runtime Bibliothek für MorphOS/AROS anzupassen, weiß ich nicht. Anbei, nach Aussage von Illka Lehtoranta müsste "libnix" unter MorphOS thread-safe sein. Zudem ist "clib2" eine C-Bibliothek und setzt auch wieder einen Startup-Code voraus. Da ich aber irgendwo schon einmal gelesen habe, dass "clib2" innerhalb einer Amiga-Shared-Bibliothek verwendet wurde, musst Du die Dokumentation zu "clib2" lesen, um herauszufinden, welche Bedingungen dafür eingehalten werden müssen.

Werfe nicht gleich die Flinte ins Korn.

Zitat:

---

Das lädt nicht gerade zum Entwickeln für den Amiga ein. Ich verstehe eigentlich gar nicht warum, steckt doch hinter einem fopen() letztendlich ein Open() der dos.library, was re-entrant ist. Irgendwo beim "einpacken" hat da doch jemand Bockmist gebaut.

---

Ich entwickle meine Programme lieber auf dem Amiga als unter Windows/Linux, weil ich hier hundertprozentig weiß, welche Betriebssystem-Funktionen meine Programme benutzen. Schon die Benutzung der clib- oder der POSIX-API verschleiern, welche Funktionen man tatsächlich verwendet. Beispiel gefällig?

fopen() in Verbindung mit fread() wird je nach Implementierung und des Quellmediums (Floppy-Disk, Hard-Disk etc.) andere Puffer-Größen verwenden. Z.B. wird anhand des Struktureintrages "Bester Datentransfer" ("<sys/stat.h>") ein Puffer verwendet, der irgendwo im Bereich von 512 Bytes bis zu mehreren Kbytes angesiedelt ist, demnach wird fread()/fwrite() nicht exakt die Anzahl der Daten einlesen/schreiben, die Du angibst, sondern dies alles über einen Puffer im RAM bewerkstelligen, der ohne Dein Zutun alloziiert wurde. Erst wenn Du explizit diesen Puffer (Cache) leerst oder fclose() aufrufst oder auch Dein Programm beendest, werden Daten geschrieben. Beim Lesen ist es wiederum anders. Du kannst sagen ich lese Byte für Byte, intern wird aber ein Puffer verwendet, der Dateien blockweise liest, also zum Beispiel 64 Kbytes auf einmal. Liest Du das nächste Byte, wird keine Lesevorgang ausgeführt, sondern nur der Pufferzähler um ein höher gesetzt (fseek()) und Dir das nächste Byte, das sich im RAM (Cache) befindet, retourniert.
Jetzt hast Du auch den Grund, warum das nicht von Anfang an thread-safe programmiert wurde. Es wurden nämlich Variabeln auf Dateiebene angelegt. Erst als man begann, den FILE-Record (FILE-Descriptor) so zu erweitern, dass diese Puffer/Zähler Teile des FILE-Records wurden, ging man den thread-safe Weg (blödes Wort, aber mir fällt nichts Besseres ein, sorry).
Damit bleibt aber noch immer ein Problem bestehen. Beim Beenden eines Programmes müssen noch alle geöffneten Dateien geschlossen werden sowie alle verwendeten Speicherbereiche dem Betriebssystem zurückgegeben werden. Wie macht man das, wenn man alles im FILE-Record platziert hat, der FILE-Record aber nur dem Anwenderprogramm bekannt ist? Lösung, man erstellt eine Liste mit allen FILE-Records ohne Zutun des Anwenderprogrammes, ergo beim Aufruf von fopen()! Und wo bewahrt man den Zeiger auf diese Liste auf Dateiebene auf? Im Startup-Code! Was macht der Startup-Code wenn dessen Exit-Routine aufgerufen wird? Es testet die Liste; ist ein Eintrag nicht null, wird automatisch flcose() ohne Dein Zutun aufgerufen und damit der Pufferinhalt geleert (flush), die Datei geschlossen und die Speicherbereiche dem Betriebssystem als unbelegt zurückgemeldet!

Ja, ich gebe Dir Recht, der Verzicht auf clib- oder POSIX-Funktionen beim Programmieren unter AmigaDOS (speziell 3.x) bedeutet im Umkehrschluss sehr viel mehr Arbeit, macht mich aber unabhängig von irgendwelchen Implementierungen. Zudem spielt Zeit keine Rolle für mich; bin halt ein Hobby-Programmierer.

Auch solltest Du niemals außer Acht lassen, dass man unsichere Teile immer thread-safe gestalten kann, indem man *nur* die Library-Base klont, also negativ- sowie positiv-Offsets (OS3/AROS/MorphOS, OS4 ist ein wenig *anders*), und jedem Endanwender eine eigene Library-Base zuweist. Dementsprechend braucht man nicht Hand an die Funktionen selber zu legen, sondern nur die Sprungtabelle inklusive des Library-Records für jede Instanz zu reproduzieren (kopieren). Ist allerdings nicht der sauberste Stil, weil eine Shared-Bibliothek im Grunde genommen reentrant sein sollte und nicht nur thread-safe.


Als Ergänzung zu whose Worten kann ich Dir nur ans Herz legen, Weaver (amimedic.de) herunter zu laden.
Es ist ein Programm, das Dir anhand von SFD-Dateien die Grundgerüste für Shared-Libraries erzeugt, und zwar für OS3/AROS/MorphOS und OS4.
Alles was Du dazu brauchst ist dann ein Texteditor, einen C-Compiler, Weaver und fd2pragma und Du erstellst für alle vier Plattformen die benötigten Dateien, inklusiver derer für die Endbenutzer. Nach wie vor musst Du aber erst einmal Deine Funktionen so schreiben, dass diese auch mindestens thread-safe sind, besser wäre aber reentrant. Kriegst Du das nicht hin, klone wie oben beschrieben die Library-Base für jedes aufrufende Programm und dann sollte auch einer Amiga-Implementierung nichts im Wege stehen.
Willst Du weiterhin C++ benutzen, bleibt Dir sowieso nichts anderes übrig, es sei denn, Du kannst exakt bestimmen, ob der vom C++-Compiler generierte Code thread-safe ist.

Mein Fazit:
Wenn man denkt es geht nicht mehr, kommt von irgendwo ein Lichtlein her.
Oder anders gesagt, ich hoffe, dass Du jetzt nicht mehr ganz so schwarz siehst.


Grüße

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Also wenn ich mich zusammenreise, dann komme ich mit

fopen()
fread()
fwrite()
fseek()
ftell()
fclose()
malloc()
free()

aus.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Danke für die vielen Hinweise.

Alles hat natürlich seine Gründe.

Was bleibt ist aber, Windows DLL luppt, AmigaOS luppt nicht.

---

Zitat:

---

Die C Runtime zu benutzen sollte ja gerade dahin führen, dass der Code portabel ist. Ist mir schon klar dass ich es machen könnte direkt mit AmigaOS, nur ist das eine Zeit frage, wieviel man in die AmigaOS version stecken kann.

---

Zitat:

---

Eine Shared library will ich aus verschiedenen Gründen machen.

---

Die Pro/Contra-Argumente sind doch lange bekannt.

Fakt ist aber, "mal eben" Code, der die C-Standardfunktionen nutzt, in eine Amiga-shared-Library packen ist nicht drin. Aufwand wirst Du so oder so haben, wann immer Du Code fabrizierst, der vom Standardvorgehen bei der Programmierung in C abweicht (geteilter Code ist so ein Abweichung).

Ok, manchmal übernehmen die Entwickler des Betriebssystems den Aufwand für Dich und basteln, naja, interessante, Lösungen dazu, aber für AOS 68k fällt das auf alle Fälle flach, da passiert in dieser Richtung wohl eher nichts mehr.

Da mußt Du Dir dann die Frage stellen, ob Du den Aufwand (der bei gut durchdachtem Aufbau wirklich nicht gewaltig ist) treiben willst oder eben nicht. Hier kann Dir diese Entscheidung niemand abnehmen, nur Wege aufzeigen, wie Du Dein Ziel eben doch erreichen kannst. Allerdings niemals ohne zusätzlichen Aufwand im Gegensatz zur Windows-DLL-Variante.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Es geht um Sprachsynthese, wo es gemeinsame Resourcen gibt, z.B. die Lexica und die Stimmen.

---

Benötigst Du dazu die mathematischen Bibliotheken? - sprich Fließkommazahlen? Dann rennst Du nämlich ins nächste Problem.
Schon Anweisungen wie:
z = i + 1.5;
oder
i = z / 2.0;
benutzten auf dem Amiga Compiler-spezifische Routinen, die ausschließlich in der jeweiligen C-Runtime Bibliothek zu finden sind.

Erschwerend kommt hinzu, aber eher von theoretischer Natur, wenn ich das noch recht in Erinnerung habe, dass man jedwede zu benutzende mathematische Bibliothek von dem Prozess, der sie verwendet, auch öffnen lassen muss, und nicht nur einmal, wie sonst üblich. Der Grund liegt darin begründet, dass eine Ressource (ausschließlich ein Benutzer für die Nutzungsdauer gestattet) anstelle einer Software bzw. einer Software-Hardware-Lösung verwendet werden könnte und diese per Definition ausschließlich von dem Prozess, der sie öffnete, auch geschlossen werden darf.


@whose:

"Winzigweich"?

Habe den Ausdruck noch nicht vernommen.

Zitat:

---

Ja, aber es luppt auch nur deswegen als DLL, weil man bei Winzigweich entsprechend Aufwand mit dem OS getrieben hat. Normalerweise würde das genauso wenig luppen.

---

Ja, da hast Du Recht.
Allerdings kommt so etwas als zentrale Schnittstelle für ein schlankes, halbwegs effizientes Betriebssystem nicht infrage, weil:
a) zur Laufzeit externe Verweise aufgelöst werden müssen
b) zur Laufzeit die Sprungadressen ermittelt werden müssen
c) die Sprungadressen anhand des Namens ermittelt werden
d) ein zentraler Prozess die Nutzung dieser dynamischen Bibliotheken gewährleisten muss

In Zeiten von C#/Java und zig Giga-Hertz spielt das für Endanwender aber keine Rolle mehr, weil man es nicht wahrnimmt, bzw. die Geschwindigkeit als ausreichend erachtet.
Das gleiche für OS3, selbst mit einer 100 MHz 68060 CPU, würde abschreckend wirken.

Ich gebe zu, dass eine Amiga-Shared Bibliothek um ein vielfaches schwieriger zu erstellen ist als eine '.dll', jedoch ist ihre Verwaltung aus Sicht einer CPU effektiver.
Zudem hat Microsoft den Sprach-Standard von C um "__declspec" erweitert, damit es dem Programmierer leichter gemacht wird, eine '.dll' zu erstellen. So was müsste es für AmigaOS/AROS/MorphOS geben...

Zitat:

---

Ok, manchmal übernehmen die Entwickler des Betriebssystems den Aufwand für Dich und basteln, naja, interessante, Lösungen dazu, aber für AOS 68k fällt das auf alle Fälle flach, da passiert in dieser Richtung wohl eher nichts mehr.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Der_Wanderer:

Ehrlich gesagt, mir fällt keine bessere ein, als die Standardfunktionen in Wrapper zu verpacken (und für AOS im Wrapper OS-Funktionen statt C-Standard zu verwenden), um eine gewisse Unabhängigkeit vom startup code zu erreichen. Sowas ließe sich auch noch recht simpel im makefile abfrühstücken, ohne #ifdef-Orgie.

Mir ist auch nicht ganz klar, weswegen Du z.B. printf() verwenden willst. Für GUI-Programme wäre das selbst unter Win ein No-Go, es sei denn, Du baust auch dafür wieder Wrapper bzw. nutzt systemabhängige Lösungen.

Der ganze fxxxx()-Krempel gehört eigentlich auch nicht in eine systemabhängige dynamische Bibliothek, Gründe dafür wurden hier schon öfter genannt. Ok, irgendwie muß Deine Lib ja die Daten laden, ist schon klar, aber, wie schon erwähnt, sowas ist im Grunde nicht mehr "portabel".

Eventuell solltest Du Dein Design nochmal etwas überdenken. Gut, der Weg via .dll/.so & Standardfunktionen ist trivial, aber nicht wirklich schön, und irgendwann beißt es Dich in den Hintern.

Oder, wie im Fall von AmigaOS 3.x, gleich von vornherein.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Intern verwende ich hier und da Floats, z.b. um ein Hamming Fenster zu berechnen etc.

Verstehe ich aber nicht ganz, in Amiblitz kann ich doch auch Floats in Shared Libs benutzen.

---

Du kannst sie auch innerhalb einer in C erstellten Bibliothek verwenden, leider aber nicht die Versionen, die in der statischen Compiler (Runtime) Biblitohek zu finden sind, denn, wir näheren uns wieder dem Anfang dieses Threads, unter OS3 sind diese nicht thread-safe und zum Anderen setzen sie Teile des Startup-Codes als gegeben voraus.

Ich bin ein wenig überfragt, wie Amibltiz Fließkommazahlen handhabt und ob mittels Amiblitz erstellte Funktionsbibliotheken wirklich reentrant sind. Unter C jedoch gibt es diverse Referenzen zu Funktionen, die zwar alle dasselbe tun, z.B. dividieren, aber unterschiedliche Bezeichner haben, weil es neben FLOAT und DOUBLE noch die internen Formate der 68881/68882/68040/68060 FPUs gibt, die auch unterstützt werden.
Diese Funktionsnamen sind in den betreffenden Compilern fest verankert, z.B. __muldf3(), __fixsfsi(), __floatsisf(), __divsf3(), um nur einige unter "gcc" zu nennen. Und diese müssen zwingend reentrant für eine Amiga Shared-Library sein, ansonsten musst Du nämlich jede Funktion, die eine dieser Routinen benutzt, solange sperren, bis die betreffende Routine wieder frei zur Verfügung steht. Wohl kaum durchführbar.

So, nachdem ich mir jetzt mal kurz das 'Change.log' zu "clib2" angeschaut habe, gehe ich davon aus, dass alle Funktionen die Du benötigst, darin enthalten sind, auch die Compiler-spezifischen für FLOAT und DOUBLE.

Damit kannst Du schon mal OS3 und OS4 abdecken.
Unter MorphOS ist "libnix" das Äquivalent.
Macht schon mal drei von vier.
Ich hoffe, dass unter AROS die zur Verfügung stehenden "Static Libs" thread-safe sind, dann hättest Du nämlich alle vier abgedeckt.


Grüße

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Wie von meinem Vorredner schon aufgezeigt, sooo doll ist der Aufwand eigentlich nicht. Davon ab, Nutzung der C-Runtime bedeutet nur "portabel bei ausschließlicher Nutzung der Möglichkeiten der Runtime/Standard-Link-Library". Streng genommen ist nicht einmal der Weg DLL/.so im Sinne des C-Standards "portabel".

---

Zitat:

---

Mir ist auch nicht ganz klar, weswegen Du z.B. printf() verwenden willst. Für GUI-Programme wäre das selbst unter Win ein No-Go, es sei denn, Du baust auch dafür wieder Wrapper bzw. nutzt systemabhängige Lösungen.

---

Zitat:

---

Original von jolo:
@whose:

"Winzigweich"?

Habe den Ausdruck noch nicht vernommen.

---

Zitat:

---

Ja, da hast Du Recht.
Allerdings kommt so etwas als zentrale Schnittstelle für ein schlankes, halbwegs effizientes Betriebssystem nicht infrage, weil:
a) zur Laufzeit externe Verweise aufgelöst werden müssen
b) zur Laufzeit die Sprungadressen ermittelt werden müssen
c) die Sprungadressen anhand des Namens ermittelt werden
d) ein zentraler Prozess die Nutzung dieser dynamischen Bibliotheken gewährleisten muss

---

Zitat:

---

In Zeiten von C#/Java und zig Giga-Hertz spielt das für Endanwender aber keine Rolle mehr, weil man es nicht wahrnimmt, bzw. die Geschwindigkeit als ausreichend erachtet.
Das gleiche für OS3, selbst mit einer 100 MHz 68060 CPU, würde abschreckend wirken.

---

Zitat:

---

Ich gebe zu, dass eine Amiga-Shared Bibliothek um ein vielfaches schwieriger zu erstellen ist als eine '.dll', jedoch ist ihre Verwaltung aus Sicht einer CPU effektiver.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]