How to write: Exec shared library in 100% C
Andreas Kleinert
On Aminet these days.
Short: How to write: Exec shared library in 100% C
Type: dev/c
Uploader:
Author: Andreas_...@t-online.de
example.library, test program and source-code V1.0 (14.8.96)
(C) 1996 by Andreas R. Kleinert. All rights reserved.
This small sample library source code demonstrates, how to completely
write an Amiga Exec shared library without any Assembler stubs
or compiler/linker tricks in PURE C source code.
You may use this example source code to write more portable
Amiga Exec shared libraries to allow easier porting of these
to other Amiga OS-derived operating systems, or the native
OS of an upcoming PowerPC Amiga.
Translate your 68k-Assembler Library-Startup-Codes smartly
to C by simply using this source-code as an advice how to do it.
_________________________________________________________
| You may reach me the following way. |
| Send bug-reports, money or whatever to: |
|---------------------------------------------------------|
| * SuperView Development & Registration * |
| * DRAFU Development & Registration * |
| * Image Engineer Registration Site Europe * |
| |
| |
| Persistant Software |
| |
| Andreas R. Kleinert |
| Sandstrasse 1 |
| D-57072 Siegen |
| Germany, Europe |
| |
| Any snail mail to the old address will still be routed. |
| |
| Phone: +49-271-22869 also FAX + AM |
| +49-271-22838 |
| |
| Weekdays after 17.00h. |
| |
| When calling via phone you may leave a message, |
| if I'm not available - but don't expect me |
| calling back to USA, Australia, ... since |
| german phone rates are HIGHLY expensive. |
|_________________________________________________________|
EMail:
DO not SEND ANY binaries (or uuencoded) VIA THE
FOLLOWING EMAIL ADDRESSES, EXCEPT MAYBE small ONES
VIA t-online.de (smaller or equal 16 KB).
THANK YOU.
- Fido Andreas Kleinert 2:2457/350.18
- Usenet
Andreas_...@superview.ftn.sub.org (Fido-Gate)
Andreas_...@t-online.de (T-Online)
A...@COB.wwbnet.de (Z-Netz)
- If nothing else works, try one of these public
Fido-Usenet gateways:
In Germany:
Andreas_...@p18.f350.n2457.z2.fido.sub.org
From USA or elsewhere:
Andreas_...@p18.f350.n2457.z2.fidonet.org
Please note, that the "superview.ftn.sub.org"
domain will perhaps be renamed in late 1996.
Stefan Becker
A...@cob.wwbnet.de (Andreas Kleinert) writes:
> This small sample library source code demonstrates, how to completely
> write an Amiga Exec shared library without any Assembler stubs
> or compiler/linker tricks in PURE C source code.
Dieser Beispiel-Source ist mit Vorsicht zu genießen. Beim kurzen
Überfliegen sind mir folgende Probleme aufgefallen:
- Bei der Initialisierung der Library werden andere Libraries global
geöffnet, d.h. deren Library-Bases werden zwischen den einzelnen
Callern der Library geshared. Das ist ein NO-NO.
Jetzt kommt bestimmt "Aber es funktioniert doch". Das ist aber noch
lange kein Grund dafür das es RICHTIG ist.
- Der Source ist SAS/C spezifisch. Tolle Basis für eine PPC Portierung :-)
Es können noch weitere Probleme versteckt sein, z.B. wird
lib_OpenCount in CloseLib() immer um 1 verringert, egal welchen Wert
es momentan hat. Geschmackssache ist wohl der C Programmierstil, aber bei
"&= (0xFF ^ LIBF_DELEXP)" statt "&= ~LIBF_DELEXP" dreht sich bei mir
der Magen um :-)
Regards,
Stefan
PS: Weitere C Beispiel-Sourcen für Libraries sind ScreenNotify,
WBStart, DOSPath und ToolManager 2.x.
---
Stefan Becker E-Mail: Stefan...@nmp.nokia.com
Office: +358-10505-1 (PBX) FAX: +358-10505-2525
My opinions need not to reflect those of my employer
Michael van Elst
Stefan Becker <Stefan...@nmp.nokia.com> writes:
> - Bei der Initialisierung der Library werden andere Libraries global
> geöffnet, d.h. deren Library-Bases werden zwischen den einzelnen
> Callern der Library geshared. Das ist ein NO-NO.
Es haengt von den Libraries ab, ob es legal ist die Base zu sharen.
Allerdings ist ein Wait() in der Init-Routine nicht legal. Das ist
IMHO der wesentlich groessere Fehler.
> Jetzt kommt bestimmt "Aber es funktioniert doch". Das ist aber noch
> lange kein Grund dafür das es RICHTIG ist.
Tja...
> - Der Source ist SAS/C spezifisch. Tolle Basis für eine PPC Portierung :-)
Nenn eine Alternative :) Nenn vor allem eine Alternative, die eine
"tolle Basis fuer eine PPC Portierung" waere.
>Es können noch weitere Probleme versteckt sein, z.B. wird
>lib_OpenCount in CloseLib() immer um 1 verringert, egal welchen Wert
>es momentan hat.
Ist kein Problem. Jedem CloseLibrary entspricht ja ein OpenLibrary, das
den OpenCount-Wert hochgezaehlt hat. Der Wert "kann" gar nicht falsch sein.
Wenn du sanity-checks haben willst, kannst du ja noch sowas wie
if (lib->lib_OpenCount <= 0)
Alert(DEADEND);
einbauen.
>Geschmackssache ist wohl der C Programmierstil, aber bei
>"&= (0xFF ^ LIBF_DELEXP)" statt "&= ~LIBF_DELEXP" dreht sich bei mir
>der Magen um :-)
Ist auch nicht portabel. Es geht davon aus, dass das Flags-Feld 8bit
gross ist. Ein ~ erlaubt zumindest Typen <= int und wenn LIBF_DELEXP
passend definiert ist auch groessere Typen.
Salut,
--
Michael van Elst
Internet: mle...@serpens.swb.de
"A potential Snark may lurk in every tree."
Andreas R. Kleinert
> Angeblich soll OpenLibrary() V37 gegen diverse Dinge
> (dos-based Libraries) geschuetzt sein - dass es nicht ganz
^^^^^^^^^
disk-based (pardon, typo ;-)
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Image Engineer Registration Site Europe
persistent - resistant -> PERSISTANT
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> - Bei der Initialisierung der Library werden andere Libraries global
> geöffnet, d.h. deren Library-Bases werden zwischen den einzelnen
> Callern der Library geshared. Das ist ein NO-NO.
Solange eine Library nicht explizit nicht zwischen diversen Callern
geshared werden darf (div. socket-libs), gehe ich davon aus, daß
es erlaubt ist.
Siehe sämtliche Beispielsources zu dem Thema...
> Jetzt kommt bestimmt "Aber es funktioniert doch". Das ist aber noch
> lange kein Grund dafür das es RICHTIG ist.
Ausser Dos, Exec, Intuition, Graphics wird nichts weiter geöffnet.
Wenn *die* kritisch sein sollten, wird unter PPC-OS so gut
wie *keine* Library mehr in der PPC-Emulation laufen.
Sieh Dir doch dazu mal den Beispiel-Source zu David Junods
picture-datatypes an. Oder den *Assembler* -Source aus den RKMs
David verwendet so etwas wie
Bas = OpenLibrary(...)
und setzt dann ClassBase->cb_Base = Base
für die Pragmas dann noch: #define XYBase ClassBase->cb_XYBase
Das ist (hier) *auch* global, nur ohne globale Variable.
BTW läßt sich mein Source problemlose umschreiben, so daß
er obige Bedingungen erfüllt.
> - Der Source ist SAS/C spezifisch. Tolle Basis für eine PPC Portierung :-)
Immer noch kompatibler als das diverse Assembler-Gehacke, in dem
sicherlich obige Regeln noch schlechter realisierbar sind, als
Du mir das vorhälst.
Wenn StormC so kompatibel zu SAS/C wird, wie angekündigt, sollte
das a) kein Problem sein und wenn es b) für Dich ein größeres
Problem ist, SAS/C nach XXX-C zu konvertieren, als XXX-Assembler
nach XXX-C, dann kann ich auch nichts dafür.
Die Betonung lag BTW auf "more portable" (than ...).
> Es können noch weitere Probleme versteckt sein, z.B. wird
> lib_OpenCount in CloseLib() immer um 1 verringert, egal welchen Wert
> es momentan hat.
Again: siehe Referenz-Sources von C=
Da die Library die einzige ist, die den Wert erhöhen kann, kann
auch sie ihn nur verringern.
Alles andere wäre ohnehin ein Hack.
> Geschmackssache ist wohl der C Programmierstil
Hätte mich auch gewundert, wenn nicht.
Den nächsten Source mache ich in K&R, dann hast Du wenigstens
einen *echten* Grund...
>, aber bei "&= (0xFF ^ LIBF_DELEXP)" statt "&= ~LIBF_DELEXP"
> dreht sich bei mir der Magen um :-)
für stilistische Feinheiten fehlte die Zeit.
So sieht man wenigstens, daß es sich um einen UBYTE-Wert handelt...
> PS: Weitere C Beispiel-Sourcen für Libraries sind ScreenNotify,
> WBStart, DOSPath und ToolManager 2.x.
Achso, das war der Zweck der Sache.
Die ScreenNotify-Library macht BTW bei mir nur Probleme
mit Spot und ThumbMail (ist doch nicht etwa ein Hack ?)
Wann gibt's ein Update ?
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Image Engineer Registration Site Europe
My opinions are usually not shared by anyone
- including me.
(Hey, wanna redefine "irony" ?)
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> > - Bei der Initialisierung der Library werden andere Libraries global
> > geöffnet, d.h. deren Library-Bases werden zwischen den einzelnen
> > Callern der Library geshared. Das ist ein NO-NO.
> Es haengt von den Libraries ab, ob es legal ist die Base zu sharen.
Denke ich auch.
> Allerdings ist ein Wait() in der Init-Routine nicht legal. Das ist
> IMHO der wesentlich groessere Fehler.
Da ist kein explizites Wait.
Versteckt sich eins im Öffnen der Gfx/IntuitionBase ?
Angeblich soll OpenLibrary() V37 gegen diverse Dinge
(dos-based Libraries) geschützt sein - daß es nicht ganz
so ist, wie es in den RKMs steht, mußte ich leider auch
schon feststellen.
> >Geschmackssache ist wohl der C Programmierstil, aber bei
> >"&= (0xFF ^ LIBF_DELEXP)" statt "&= ~LIBF_DELEXP" dreht sich bei mir
> >der Magen um :-)
> Ist auch nicht portabel. Es geht davon aus, dass das Flags-Feld 8bit
> gross ist. Ein ~ erlaubt zumindest Typen <= int und wenn LIBF_DELEXP
> passend definiert ist auch groessere Typen.
Yep, das war allerdings eher Absicht.
Beziehungsweise: ich habe vorausgesetzt, daß sich bei einer
Portierung die Größen aller Strukturen nicht ändern.
So gesehen wäre, z.B. eine Pragma-Direktive von SAS/C
auch nicht portabel, denn die Offsets zur Base sind
schließlich immer 6 Bit, egal was Exec's Init-Funktion
aus der Funktionstabelle für eine Base macht...
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Image Engineer Registration Site Europe
Any sufficiently advanced technologie is indistinguishable from magic.
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> PS: Weitere C Beispiel-Sourcen für Libraries sind ScreenNotify,
> WBStart, DOSPath und ToolManager 2.x.
Dann frage ich mich, warum Du die nicht schon früher öffentlich
verfügbar gemacht hast (einzeln, einfach, unkompliziert, als Beispiel).
Der Amiga existiert seit mehr als 10 Jahren, und es gibt bis heute
keine offiziell-legal dokumentierten Sourcen, wie man eine
Library komplett in C programmieren kann.
Lediglich einige, teilweise noch nichtmal korrekte, Assembler-Sources
in den RKMs und diversen Büchern.
IMHO ist ein großes Hindernis für die Portierung des AmigaOS
die Abhängigkeit von diversen 68k-Assembler-Relikten, die man, bei
einigem gutem Willen, schon längst hätte abstreifen können:
- Library-Beispielsourcen
- Device-Beispielsourcen
- Datatype-Beispielsourcen
(im C-Teil vorbildlich, aber viel zu kompliziert für ein Beispiel)
- RawDoFmt()
(es gibt bis heute keine Möglichkeit, die "Copy-Byte"-Routine,
die angegeben werden muß, irgendwie zu ersetzen - z.B.
durch eine Routine der amiga.lib - man *muß* 68k-Assembler
oder ein 4-Byte-#define mit 68k-Code (oder PPC ?) verwenden)
- usw. usf.
Sonstiges, was jedoch nicht mehr rückgängig zu machen ist:
- die 6-Bit-Offsets in den Libraries:
prinzipiell könnte Exec's Init-Funktion alles mögliche
daraus machen (z.B. eine Funktionstabelle mit
den 32-Bit Adressen der aufzurufenden Funktionen),
aber Exec's Entwickler mußten ja unbedingt ein JMP
mit in die Sprungtabelle einbauen...
(komme mir keiner mit Geschwindigkeitsgründen - die
Hardware-Coder haben das OS eh immer komplett ignoriert)
Paßt ein PPC-JMP plus Adresse in 6 Bit ?
Vermutlich nicht.
Werden PPC-Libraries dadurch inkompatibel zu 68k-Libraries
sein ?
Keine Ahnung.
Wird also ein 68k-Program eine PPC-Exec-Library aufrufen
können ?
Wer weiß - vielleicht steht deshalb plötzlich in den
OS-Docs (DeveloperCD) der Hinweis, daß man nicht davon
ausgehen kann, immer die gleiche Library-Base zurückzu-
bekommen (für mich ein Widerspruch zur gängigen
Programmierpraxis, es sein denn...)
Bekommt dann ein 68k-Programm (Prozess) eine
68k-style-Base und ein PPC-Programm (Prozess)
eine PPC-style-Base ?
Wie sieht es aus mit Interrupts (aha, deshalb die
andere Notiz dort) ?
Wie man sieht, kann man die Library-Sources frühestens
mit Verfügbarkeit von PPC-Compiler und PPC-OS anpassen,
aber auf Basis von C-Source mit Sicherheit einfacher,
als auf Basis von Assembler Source.
Außerdem möchte vielleicht auch der eine oder andere
aus der PPC-Umgebung heraus mit seinem PPC/68k-Cross
C-Compiler weiterhin 68k-Programme erzeugen.
Auch das ist Portabilität.
- "One-cycle instruction" (oder "One byte")-Operationen:
Nachdem Forbid() und Permit() auch nicht mehr das sind,
was sie mal waren, müßte man eigentlich solche
Vorgänge, wie das De/Inkrementieren eines Library-OpenCount-
Zählers durch Semaphoren schützen (keine atomare Instruktion
mehr auf PPC/DEC/HP/xy ?).
Was hätte es aber für einen Zweck, das bei einer 68k-Library
zu machen, von denen ca. 90 Prozent das a) sowieso (auch)
nicht tun und b) auf 68k-Assembler-Sourcen beruhen ?
- BCPL und BSTRs (bei 255 Zeichen ist Schluß)
- usw. usf.
Achja:
Mein Ansatz sollte dazu dienen, den Leuten - einfach - eine
Möglichkeit zu bieten, ihre Libraries gleich in C
(oder nach C um-) zu schreiben, und dabei möglichst portabel
zu bleiben.
Dass SAS/C der einzige Compiler ist, der das unkompliziert und
direkt erlaubt (vielleicht auch StormC), kann ich nicht ändern,
auch kann ich die Portierung auf PPC nicht vorwegnehmen
(schon gar nicht mit aktuellen Compilern).
Es gibt BTW eine Reihe Leute, die gar keine Lust haben, sich
mit 68k-Assembler auseinanderzusetzen, und alles, was sie
daran hindert, eine eigene Library zu programmieren, ist
eben dies.
Wieviele davon auf die Idee kommen, nach dem Source der
Toolmanager-Lib zu forschen, weiß ich nicht.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Image Engineer Registration Site Europe
"Es ist ein Triumph des Siliziums, eine Meisterleistung moderner
Steinmetzkunst." [ Scheibenwelt von A-Z, über den (Himmels-)"Computer" ]
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> Geschmackssache ist wohl der C Programmierstil,
Fuer mich steht immer Lesbarkeit und Verstaendlichkeit im
Vordergrund (gerade bei einem Beispielsource) - das erspart
so manchen // Kommentar, der die ganze Sache nur noch schwieriger
lesbar/verstaendlich macht.
Beispiel ;-)
/ ***************************** */
/* Statt */
DOSBase = (struct Library *) OpenLibrary("dos.library", 33)
if(DOSBase != NULL) { /* dos.library opened ? */
IntuitionBase = (struct Library *) OpenLibrary("intuition.library", 33)
if(IntuitionBase != NULL) { /* intuition.library opened ? */
all_ok = TRUE;
}
}
if(all_ok == TRUE) { /* Main program loop */
}
if(IntuitionBase != NULL) {
CloseLibrary(IntuitionBase);
IntuitionBase = NULL;
}
if(DOSBase != NULL) {
CloseLibrary(DOSBase);
DOSBase = NULL;
}
/ ***************************** */
/* Schreibe ich lieber */
DOSBase = (APTR) OpenLibrary("dos.library", 33)
if(DOSBase)
{
IntuitionBase = (APTR) OpenLibrary("intuition.library", 33)
if(IntuitionBase) all_ok = TRUE;
}
if(all_ok)
{
/* Main program loop */
}
if(IntuitionBase) CloseLibrary(IntuitionBase); IntuitionBase = NULL;
if(DOSBase) CloseLibrary(DOSBase); DOSBase = NULL;
OK, da wird u.U. eine Variable = NULL gesetzt, die schon NULL enthielt,
aber was ist wohl lesbarer ?
Dritte Möglichkeit wäre:
DOSBase = (APTR) OpenLibrary("dos.library", 33)
IntuitionBase = (APTR) OpenLibrary("intuition.library", 33)
if(DOSBase && IntuitionBase)
{
/* Main program loop */
}
if(IntuitionBase) CloseLibrary(IntuitionBase); IntuitionBase = NULL;
if(DOSBase) CloseLibrary(DOSBase); DOSBase = NULL;
IMHO hat der Aufbau des Sourcecodes, sowie die vorhandenen Ein/Ausgabe-
medien (Editor, Screenmode, etc.) einen mindestens ebenso großen
Einfluß auf die Verständlichkeit eines Sourcecodes, wie die
eigentliche Komplexität desselben.
Einem komplizierten Sourcecode, der merkwürdig strukturiert ist,
helfen IMHO auch keine Kommentare - ohne die ich normalerweise in
"privaten" Sourcen mit geringem Schwierigkeitsgrad gut auskommen kann.
Ebenso werden einfache Sourcen durch extrem "konforme" (wozu auch
immer) Strukturierung, sowie "Überkommentierung" viel komplexer
als notwendig.
Ich bin weit davon entfernt, mich irgendwie "belehrend" aufzuspielen
(so anmassend werde ich nicht sein), aber wenn Du meinen C-Stil
kritisiert - und die beiden letzten Beispiele repräsentieren diesen -
hast Du es nicht anders gewollt... ;-)))
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Image Engineer Registration Site Europe
Start it up: LOAD "WIN95", 8, 1
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
Die hier besprochenen und einige andere Dinge (die niemand
entdeckt hat ;-) sind als korrigierte Version demnächst
im Aminet zu finden.
Natürlich ist mir klar, daß man noch viel verbessern könnte
(z.B. die Aufteilung der Routinen auf die einzelnen Module,
Strukturnamen, Aufteilung des Resident-Teiles, etc.),
aber das Haupaugenmerk lag *nicht* darauf, etwas zu erstellen,
das besser als alles andere ist, sondern etwas, das besser
als die Standard-Assembler-Beispiel-Sources *und* leicht
verwendbar und verständlich ist (dev/c/CExecLib12.LHA):
***
Short: Sample Amiga Exec shared library in 100% C
Type: dev/c
Uploader:
Author: Andreas_...@t-online.de
Replaces: CExecLib11.LHA
example.library, test program and source-code V1.2 (5.9.96)
(C) 1996 by Andreas R. Kleinert. All rights reserved.
The author takes no responsibility for anything.
Legally or otherwise.
---
This small sample library source code demonstrates, how to completely
write an Amiga Exec shared library without any assembler stubs
or compiler/linker tricks in PURE C source code.
You may e.g. use this example source code to write more portable
Amiga Exec shared libraries to allow easier porting of these
to other Amiga OS-derived operating systems, or the native
OS of an upcoming PowerPC Amiga.
Translate your 68k-assembler library startup-codes smartly
to C by simply using this source-code as an advice how to do it.
---
Feel free to use this source for own projects.
It is allowed to be spread and distributed anywhere, as far
as my consent is concerned.
Amiga Technologies, or the current owner of the technologie,
is allowed to always put this source on their newest
Developer CD-ROM.
Thanks and credits will always be appreciated - for example,
you MAY, but NEED NOT:
give me credits in your program's docs, send me keyfiles for
your programs using the library, and so on.
But that's simply voluntarily.
EMail:
In Germany:
Andreas_...@p18.f350.n2457.z2.fido.sub.org
History:
V1.2 (4.9.96) : - fixed some things resulting out of a
discussion in Z-Netz
V1.1 (1.9.96) :
- small changes in style
(only bumped versions of changed modules):
o moved "examplebase.h" to include/example/
(so also adjusted LibInit.c, StartUp.c
and SCOPTIONS for reflecting that)
o SampleFuncs.h did contain wrong prototype
(did not matter, since only used for
ULONG function table within StartUp.c)
o explicitely __aligned ROMTag structure
V1.0 (14.8.96) :
- first release
---
All mentioned trademarks are subjects to their owners.
Andreas R. Kleinert
Wer außerdem noch meinen (picture) Datatype-Beispielsource
auseinandernehmen will - an dem es sicherlich wesentlich mehr
auszusetzen gibt, da bin ich mir sicher - kann dies
ebenfalls bald tun (dev/c/C_OS3-DT401.LHA oder *402.LHA):
Short: Sample Amiga OS 3 Datatype in 100% C
Type: dev/c
Uploader:
Author: Andreas_...@t-online.de
cPGM.datatype and source-code V40.2 (5.9.96)
(C) 1996 by Andreas R. Kleinert. All rights reserved.
The author takes no responsibility for anything.
Legally or otherwise.
---
This small sample datatype source code demonstrates, how to completely
write an Amiga OS 3 datatype without any assembler stubs
or compiler/linker tricks in PURE C source code.
You may e.g. use this example source code to write more portable
Amiga OS 3 datatypes to allow easier porting of these
to other Amiga OS-derived operating systems, or the native
OS of an upcoming PowerPC Amiga.
Translate your 68k-assembler datatype startup-codes smartly
to C by simply using this source-code as an advice how to do it.
As a common case, a datatype of class picture, supporting
PNM-PGM (P5) was used as an example.
For testing this datatype, simply use a tool from the NetPBM package
(or maybe for example a tool supporting superview.library) and
save a graphics in the binary PGM format (P5 of the PNM series).
Then install this datatype and try loading this file via MultiView.
Should work fine.
---
Feel free to use this source for own projects.
It is allowed to be spread and distributed anywhere, as far
as my consent is concerned.
Amiga Technologies, or the current owner of the technologie,
is allowed to always put this source on their newest
Developer CD-ROM.
Thanks and credits will always be appreciated - for example,
you MAY, but NEED NOT:
give me credits in your program's docs, send me keyfiles for
your programs using the library, and so on.
But that's simply voluntarily.
This work was only roughly inspired by David Junod's original
example source codes for datatypes.
EMail:
In Germany:
Andreas_...@p18.f350.n2457.z2.fido.sub.org
History:
V40.2 (5.9.96) : - fixed some "style" things
V40.1 (2.9.96) : - first release
Stefan Becker
mle...@serpens.swb.de (Michael van Elst) writes:
> Es haengt von den Libraries ab, ob es legal ist die Base zu sharen.
Und das könnte sich bei einer PPC Version der Libraries ändern. Also
sollte man es tunlichst vermeiden.
> Allerdings ist ein Wait() in der Init-Routine nicht legal. Das ist
> IMHO der wesentlich groessere Fehler.
Ooopps, das hatte ich wohl übersehen. Die Init-Routine wird im
Forbid() ausgeführt und das wird vom Wait() unterbrochen.
> Nenn eine Alternative :) Nenn vor allem eine Alternative, die eine
> "tolle Basis fuer eine PPC Portierung" waere.
Der einzige PPC Compiler für den Amiga ist wohl der GCC. Ich hätte
zumindestens Macros erwartet, d.h. LIB_FUNC, LIB_REG, etc., die man
entsprechend dem Compiler umdefinieren kann.
Dann wäre nur noch das Problem der PPC Calling Convention zu lösen :-)
> Ist kein Problem. Jedem CloseLibrary entspricht ja ein OpenLibrary, das
Bist du aber optimistisch, daß sich alle Programme richtig verhalten.
Regards,
Stefan
Aaron Digulla
Michael van Elst wrote in de.comp.sys.amiga.tech about "Re: How to write:
Exec shared library in 100% C":
> > - Der Source ist SAS/C spezifisch. Tolle Basis für eine PPC Portierung
> > :-)
> Nenn eine Alternative :) Nenn vor allem eine Alternative, die eine
> "tolle Basis fuer eine PPC Portierung" waere.
AROS hat inzwischen shared libs wie auf dem Amiga. Das laesst sich mit dem
GCC unter Linux/x86 ohne Probleme uebersetzen und es tut (aeh... im Moment
leider nicht, weil ein Bug das ganze abstuerzen laesst; aber es hat mal
getan ;)
--
Aaron "Optimizer" Digulla Team AMIGA AROS Head of Development
Author of XDME, ResTrackLib, CInt. (since no one else wanted)
"(to) optimize: Make a program faster by improving the algorithms rather than
by buying a faster machine."
Michael van Elst
Stefan Becker <Stefan...@nmp.nokia.com> writes:
>mle...@serpens.swb.de (Michael van Elst) writes:
>> Es haengt von den Libraries ab, ob es legal ist die Base zu sharen.
>Und das könnte sich bei einer PPC Version der Libraries ändern. Also
>sollte man es tunlichst vermeiden.
Ein paar Libraries werden wohl immer geshared werden koennen muessen.
Es waere auch _wuenschenswert_, dass das so bleibt. Die "Loesung"
per kopierter LibraryBase gefaellt mir jedenfalls ueberhaupt nicht.
Fuer die meisten Anwendungen waere ein separater Kontextparameter
(zusaetzlich zum Base-Pointer) fuer jede Funktion die sauberere Loesung.
Dann waere die Trennung zwischen gemeinsamen Daten und client-spezifischen
Daten explizit und muesste nicht geraten werden.
>> Allerdings ist ein Wait() in der Init-Routine nicht legal. Das ist
>> IMHO der wesentlich groessere Fehler.
>Ooopps, das hatte ich wohl übersehen. Die Init-Routine wird im
>Forbid() ausgeführt und das wird vom Wait() unterbrochen.
Die Specs garantieren uebrigens nicht den Forbid(). Aber da das
single-threading zur Zeit per Forbid() erreicht wird, muss man
auf das Wait() verzichten.
Eine zukuenftige Implementation koennte sehr gut mit Semaphoren
arbeiten. Allerdings muesste dann ramlib parallele OpenLibrary-Aufrufe
handhaben koennen.
>Der einzige PPC Compiler für den Amiga ist wohl der GCC. Ich hätte
>zumindestens Macros erwartet, d.h. LIB_FUNC, LIB_REG, etc., die man
>entsprechend dem Compiler umdefinieren kann.
Schwer genug. Besonders wenn manche Leute sogar ueber Binary-Fileformate
diskutieren und die exakte Anbindung fuer PPC-Systeme gar nicht feststeht.
>Dann wäre nur noch das Problem der PPC Calling Convention zu lösen :-)
Auch das :)
>> Ist kein Problem. Jedem CloseLibrary entspricht ja ein OpenLibrary, das
>Bist du aber optimistisch, daß sich alle Programme richtig verhalten.
Muss man wohl. Wenn du ueberzaehlige CloseLibrary-Aufrufe "tolerierst",
dann muesstest du auch Library-Funktionsaufrufe bei geschlossener
Library tolerieren. Du kannst natuerlich ueberall Sanity-Checks (samt
Alert()) einbauen, aber da ist dann CloseLibrary() nur ein Fall unter
vielen.
Ausserdem tut Mungwall sein uebriges >-)
Stefan Eggers
Stefan Becker <Stefan...@nmp.nokia.com> schrieb:
> > Ist kein Problem. Jedem CloseLibrary entspricht ja ein OpenLibrary, das
>
> Bist du aber optimistisch, daß sich alle Programme richtig verhalten.
Beispiel für fehlerhaftes Programm B:
A öffnet xyz.library
B öffnet xyz.library
B schließt xyz.library
B schließt xyz.library (ups, ja, ehm, Bug in B)
"C:Avail FLUSH" oder Speicherknappheit schmeißt xyz.libary raus
A crasht wegen B
Wem nützt also ein zusätzlicher Check beim Open-Count dekrementieren?
Bringt doch nur was, wenn die Library für jeden Task eine eigene neue
Library-Base erzeugt. Und in dem Fall würde sie sich doch bei Count
0 schon verabschiedet haben und der Fall Open-Count = 0 niemals auf-
treten.
Und eine vergessenes Schließen kann man nicht so ohne weiteres fest-
stellen. Aber das hat ja bei weitem nicht so fatale Auswirkungen auf
das System.
Stefan.
--
Stefan Eggers Wer mehr ueber mich wissen will und/oder meinen
Max-Slevogt-Str. 1 PGP-Key benoetigt schreibe an meinen Automaten:
51109 Koeln mailto:userinfo...@semyam.dinoco.de
FRG (Das "mailto:" ist nicht Bestandteil der Adresse!)
Stefan Zeiger
Andreas R. Kleinert schrieb:
> - Library-Beispielsourcen
> - Device-Beispielsourcen
Wenn Du schon SAS/C verwedest, solltest Du Dir die mitgelieferten Beispiele
einmal n=E4her ansehen.
> - RawDoFmt()
> (es gibt bis heute keine M=F6glichkeit, die "Copy-Byte"-Routine,
> die angegeben werden mu=DF, irgendwie zu ersetzen - z.B.
> durch eine Routine der amiga.lib - man *mu=DF* 68k-Assembler
> oder ein 4-Byte-#define mit 68k-Code (oder PPC ?) verwenden)
Das geht auch komplett in C. Beispiel f=FCr gcc:
| void __printf_callback()
| {
| register BPTR output asm("a3");
| register LONG data asm("d0");
|
| FPutC(output,data);
| }
|
| void __objc_printf (const char *format, ...)
| {
| RawDoFmt((char *)format, &format+1, __printf_callback, (APTR)Output());
| }
Stefan Zeiger
Andreas R. Kleinert schrieb:
> DOSBase =3D (APTR) OpenLibrary("dos.library", 33)
^^^^
Der Sinn ist nicht, einen "Absolute Memory Pointer" zu bekommen, sondern ei=
nen
impliziten Typecast durch "(void *)" zu erzwingen. IMHO sollte man dann auc=
h
"(void *)" und nicht "(APTR)" verwenden.
> if(all_ok)
Wozu diese Hilfsvariable? So kurz und =FCbersichtlich kann's aussehen:
| if(DOSBase=3D(struct DOSLibrary *)OpenLibrary(DOSNAME, 33))
| {
| if(IntuitionBase=3D(struct IntuitionBase *)OpenLibrary("intuition.libr=
ary", 33))
| {
| /* Main program loop [welcher "loop" eigentlich?] */
| CloseLibrary((struct Library *)IntuitionBase);
| }
| CloseLibrary((struct Library *)DOSBase);
| }
> OK, da wird u.U. eine Variable =3D NULL gesetzt, die schon NULL enthielt=
,
> aber was ist wohl lesbarer ?
So lange Dich die Hinweise vom Optimizer nicht st=F6ren ;)
> if(IntuitionBase) CloseLibrary(IntuitionBase); IntuitionBase =3D NULL=
;
> if(DOSBase) CloseLibrary(DOSBase); DOSBase =3D NULL=
;
^^^^^^^^^^^^^^^^^^^^^
Wozu?
Stefan Zeiger
Andreas R. Kleinert schrieb:
> Solange eine Library nicht explizit nicht zwischen diversen Callern
> geshared werden darf (div. socket-libs), gehe ich davon aus, da=DF
> es erlaubt ist.
Wenn Du mit "Caller" "Task" meinst, ist das falsch. Siehe RKM Libraries,
S.467, "Sharing Library Pointers".
> > - Der Source ist SAS/C spezifisch. Tolle Basis f=FCr eine PPC Portieru=
ng :-)
Wo ist dann eigentlich der Witz an der Sache? Ein SAS/C-spezifischer
Library-Source liegt dehn SAS/C-Beispielen sowieso bei.
> > PS: Weitere C Beispiel-Sourcen f=FCr Libraries sind ScreenNotify,
> > WBStart, DOSPath und ToolManager 2.x.
Sollte jemand einen Library-Source f=FCr gcc suchen: Bei ObjectiveAmiga ist
einer dabei (in C, nicht in Objective C).
Arno Eigenwillig
In article <yLsmuMD...@ark.cob.wwbnet.de>, Andreas R. Kleinert writes:
> - RawDoFmt()
> (es gibt bis heute keine Möglichkeit, die "Copy-Byte"-Routine,
> die angegeben werden muß, irgendwie zu ersetzen - z.B.
> durch eine Routine der amiga.lib - man *muß* 68k-Assembler
> oder ein 4-Byte-#define mit 68k-Code (oder PPC ?) verwenden)
amiga.lib/sprintf().
-- __
__/// Arno "Arnooo" Eigenwillig /\ ar...@yaps.rhein.de \/ PGP key available.
\XX/ http://comma.rhein.de/~arno/ /\ V+49-2225-5870 \/ MIME 8bit welcome.
Erik Wasser
Stefan...@nmp.nokia.com (Stefan Becker) benutzte seine Tastatur am
03.09.1996 um 08:41:56 Uhr, um folgenden Text unter dem Betreff "Re:
How to write: Exec shared library in 100% C" zu erzeugen:
> - Bei der Initialisierung der Library werden andere Libraries global
> geöffnet, d.h. deren Library-Bases werden zwischen den einzelnen
> Callern der Library geshared. Das ist ein NO-NO.
Wie würdest du/irgendjemand dieses Problem lösen? Mir fällt da auf
Anhieb keine Lösung ein, die ich für vertretbar halte. Problemlösung
wäre vielleicht die Library nicht shared zu machen, sprich bei jedem
Öffnen gibt es eine andere Library Base zurück.
--
So long... Fuzz (@KAROASS.gun.de)
Andreas R. Kleinert
Stefan...@nmp.nokia.com (Stefan Becker) schrieb am 06.09.1996 um 08:17:59 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> > Allerdings ist ein Wait() in der Init-Routine nicht legal. Das ist
> > IMHO der wesentlich groessere Fehler.
> Ooopps, das hatte ich wohl übersehen. Die Init-Routine wird im
> Forbid() ausgeführt und das wird vom Wait() unterbrochen.
Die Init-Routine wird doch wohl von RamLib ausgeführt, das
auch gegen Disk-Libraries geschützt sein muß (verursacht ein
Open(), LoadSeg(), etc. etwa kein Wait() ?)
Der Beispielsource war BTW außerdem explizit für V37, obwohl C=
es in den V33-kompatiblen Sourcen genauso praktiziert hat.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Per definitionem sind alle Theorien über den Ursprung
des Universums richtig." [ Scheibenwelt von A-Z, über "Anfang, der" ]
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
Stefan...@nmp.nokia.com (Stefan Becker) schrieb am 06.09.1996 um 08:17:59 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> > Es haengt von den Libraries ab, ob es legal ist die Base zu sharen.
> Und das könnte sich bei einer PPC Version der Libraries ändern. Also
> sollte man es tunlichst vermeiden.
[...]
> > Ist kein Problem. Jedem CloseLibrary entspricht ja ein OpenLibrary, das
> Bist du aber optimistisch, daß sich alle Programme richtig verhalten.
ROTFL.
Auf der einen Seite mit einem (imaginären) PPC-OS alles gewohnte über
den Haufen werfen (wollen), und dann Rücksicht auf Programme nehmen
(wollen), die noch nichtmal die elementarsten Regeln beherrschen
(Libraries nicht öfter schließen, als man sie geöffnet hat - im
umgekehrten Fall nützt BTW Deine zus. Abfrage ja auch nichts).
Im RKM Companion (1990) steht's so:
*************************************************************************
*
* sample.library.asm -- Example run-time library source code
*
* Copyright (c) 1990 Commodore-Amiga, Inc.
->>>>>>>>>>>>> CUT <<<<<<<<<<<<<<-
initRoutine:
;------ get the library pointer into a convenient A register
move.l a5,-(sp)
move.l d0,a5
;------ save a pointer to exec
move.l a6,sb_SysLib(a5)
;------ save a pointer to our loaded code
move.l a0,sb_SegList(a5)
;------ open the dos library
lea dosName(pc),a1
CLEAR d0
CALLSYS OpenLibrary
move.l d0,sb_DosLib(a5)
bne.s 1$
;------ can't open the dos! what gives
ALERT AG_OpenLib!AO_DOSLib
->>>>>>>>>>>>> CUT <<<<<<<<<<<<<<-
Close: ; ( libptr:a6 )
;------ set the return value
CLEAR d0
;------ mark us as having one fewer openers
subq.w #1,LIB_OPENCNT(a6)
;------ see if there is anyone left with us open
bne.s 1$
;------ see if we have a delayed expunge pending
btst #LIBB_DELEXP,sb_Flags(a6)
beq.s 1$
;------ do the expunge
bsr Expunge
1$:
rts
->>>>>>>>>>>>> CUT <<<<<<<<<<<<<<-
Das ist nur eines von unzähligen (offiziellen) Beispielen.
Mich nervt es langsam, wenn unter dem Deckmantel der Portabilität
Dinge nachträglich umgedeutet worden, die nie zuvor ähnlich
restriktiv irgendwo beschrieben worden sind.
Man braucht sich noch nichtmal auf den Standpunkt zurückziehen
"alles, was nicht verboten ist, ist erlaubt". Nein, C= selbst
hat es in den Sourcen vorgemacht.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
Any sufficiently advanced technologie is indistinguishable from magic.
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
dig...@home.lake.de (Aaron Digulla) schrieb am 06.09.1996 um 21:51:58 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> AROS hat inzwischen shared libs wie auf dem Amiga. Das laesst sich mit dem
> GCC unter Linux/x86 ohne Probleme uebersetzen und es tut (aeh... im Moment
> leider nicht, weil ein Bug das ganze abstuerzen laesst; aber es hat mal
> getan ;)
wenn Du so eine Library mit GCC/68k übersetzt, kommt allerdings
sicher keine unter AmigaOS lauffähige Lib dabei heraus ?
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Es ist ein Triumph des Siliziums, eine Meisterleistung moderner
Michael van Elst
a...@cob.wwbnet.de (Andreas R. Kleinert) writes:
>> Es haengt von den Libraries ab, ob es legal ist die Base zu sharen.
> Denke ich auch.
>> Allerdings ist ein Wait() in der Init-Routine nicht legal. Das ist
>> IMHO der wesentlich groessere Fehler.
> Da ist kein explizites Wait.
> Versteckt sich eins im Öffnen der Gfx/IntuitionBase ?
Das weisst du nicht. Die Libraries koennten auf einem zukuenftigen
System disk-based sein oder aus sonst welchen Gruenden ein Wait()
ausfuehren. Da du das nicht weisst, darfst du auch nicht annehmen,
dass es nicht passiert.
>> Ist auch nicht portabel. Es geht davon aus, dass das Flags-Feld 8bit
>> gross ist. Ein ~ erlaubt zumindest Typen <= int und wenn LIBF_DELEXP
>> passend definiert ist auch groessere Typen.
> Yep, das war allerdings eher Absicht.
???
> Beziehungsweise: ich habe vorausgesetzt, daß sich bei einer
> Portierung die Größen aller Strukturen nicht ändern.
Das ist halt falsch.
Matthias Andree
seg...@semyam.dinoco.de (Stefan Eggers) schrieb am 07.09.1996 um 14:22:21 Uhr
zu Re: How to write: Exec shared library in 100% C folgendes:
> Stefan Becker <Stefan...@nmp.nokia.com> schrieb:
>
> > > Ist kein Problem. Jedem CloseLibrary entspricht ja ein OpenLibrary, das
> >
> > Bist du aber optimistisch, daß sich alle Programme richtig verhalten.
>
> Beispiel für fehlerhaftes Programm B:
>
> A öffnet xyz.library
>
> B öffnet xyz.library
>
> B schließt xyz.library
>
> B schließt xyz.library (ups, ja, ehm, Bug in B)
>
> "C:Avail FLUSH" oder Speicherknappheit schmeißt xyz.libary raus
>
> A crasht wegen B
>
> Wem nützt also ein zusätzlicher Check beim Open-Count dekrementieren?
> Bringt doch nur was, wenn die Library für jeden Task eine eigene neue
> Library-Base erzeugt. Und in dem Fall würde sie sich doch bei Count
> 0 schon verabschiedet haben und der Fall Open-Count = 0 niemals auf-
> treten.
Eine neue Library-Base ist dazu nicht erforderlich, eine Liste der
Tasks, die OpenLibrary aufgerufen haben, genügt, sozusagen den
OpenCount pro Task festzuhalten. Wenn ein Task die Library einfach
öffnet und doppelt schließt, Alert() und den OpenCount NICHT
dekrementieren.
> Und eine vergessenes Schließen kann man nicht so ohne weiteres fest-
> stellen. Aber das hat ja bei weitem nicht so fatale Auswirkungen auf
> das System.
Es blockiert u. U. Speicher, wenn der dadurch unglücklich fragmentiert
ist, ist das vielleicht nicht letal, aber unangenehm. Vielleicht wäre
ein Debug-Tool in der Art von Memwatch (wie es neueren SAS/C beiliegt)
angezeigt.
Gruß,
--
MATTHIAS ANDREE
Öffentlicher PGP-Schlüssel auf Anfrage verfügbar
Matthias Andree
A...@cob.wwbnet.de (Andreas R. Kleinert) schrieb am 05.09.1996 um 14:52:06 Uhr
zu Re: How to write: Exec shared library in 100% C folgendes:
> > Geschmackssache ist wohl der C Programmierstil,
>
> if(IntuitionBase) CloseLibrary(IntuitionBase); IntuitionBase = NULL;
> if(DOSBase) CloseLibrary(DOSBase); DOSBase = NULL;
>
>
> OK, da wird u.U. eine Variable = NULL gesetzt, die schon NULL enthielt,
> aber was ist wohl lesbarer ?
Das gibt Dresche ;-) Wie wäre es mit geschweiften Klammern um
CloseLibrary(xxxBase); xxxBase = NULL;? Du kannst es ja in einer Zeile
stehen lassen. Oder Autokonstruktoren/destruktoren verwenden.
> Start it up: LOAD "WIN95", 8, 1
Öhm. Seit wann gibt's denn das auf Floppy?
Andreas R. Kleinert
sze...@isobel.rhein-main.de (Stefan Zeiger) schrieb am 07.09.1996 um 18:35:55 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> > Solange eine Library nicht explizit nicht zwischen diversen Callern
> > geshared werden darf (div. socket-libs), gehe ich davon aus, daß
> > es erlaubt ist.
> Wenn Du mit "Caller" "Task" meinst, ist das falsch. Siehe RKM Libraries,
> S.467, "Sharing Library Pointers".
Siehe dazu Statement von Michael van Elst. Dem schließe ich mich an.
Davon abgesehen "kenne" ich doch wohl die Libraries, die ich öffne,
"weiß" also, ob diese das erlauben, oder nicht.
Eine XPK-Lib zum Beispiel müßte man alleine schon deshalb außerhalb
von InitLib öffnen, weil sonst RamLib höchstwahrscheinlich abschmiert.
Es geht hier gar nicht um eine Grundsatzdikussion: was ist prinzipiell
mit *jeder* Library legal, und was nicht. Der Beispielsource öffnete:
- dos.library
- intuition.library
- graphics.library
Die offiziellen Beispielsources von C= machen es nicht anders,
also muß es in *diesem* Fall schonmal legal sein, für alle andere
Fälle gilt das oben gesagte: man "weiß" eben, ob es legal ist,
oder nicht. Für die mathieee-Libraries ist es z.B. nicht legal,
deshalb werden sie nicht geshared.
Abgesehen davon halte ich es für die denkbar schlechteste Lösung,
task/prozeßpezifische Dinge ausgerechnet in der LibraryBase
unterbringen zu wollen (dann lieber ein Handle-Modell, o.ä.)
> > > - Der Source ist SAS/C spezifisch. Tolle Basis für eine PPC Portierung :-)
> Wo ist dann eigentlich der Witz an der Sache? Ein SAS/C-spezifischer
> Library-Source liegt dehn SAS/C-Beispielen sowieso bei.
Es ist - kein Assembler mehr enthalten
- kein Assembler mehr enthalten
- kein Assembler mehr enthalten
Stichwort: - Crosscompiler PCC->68k
- saubere Programmierung von Library aus
einer reinen C-Umgebung heraus
> > > PS: Weitere C Beispiel-Sourcen für Libraries sind ScreenNotify,
> > > WBStart, DOSPath und ToolManager 2.x.
> Sollte jemand einen Library-Source für gcc suchen: Bei ObjectiveAmiga ist
> einer dabei (in C, nicht in Objective C).
Na, ist doch toll.
Trotzdem gehört sowas IMHO in die offiziellen Programmierunterlagen
bzw. zum Compiler-Zubehör.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Dehydriertes Wasser läßt sich in seinen ursprünglichen Zustand versetzen,
indem man der pulvrigen Substanz Wasser hinzufügt."
[ Scheibenwelt von A-Z, über den "Dehydrierten Ozean" ]
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> Der Sinn ist nicht, einen "Absolute Memory Pointer" zu bekommen, sondern einen
> impliziten Typecast durch "(void *)" zu erzwingen. IMHO sollte man dann auch
> "(void *)" und nicht "(APTR)" verwenden.
APTR ist genauso definiert, Amiga-OS-spezifisch, und kürzer.
Genausogut kann ich schreiben
typedef void *MEIN_VOID_POINTER;
und diesen dann verwenden. Wo ist das Problem ?
> > if(all_ok)
> Wozu diese Hilfsvariable? So kurz und übersichtlich kann's aussehen:
Argh - das war nur ein Beispiel.
> | /* Main program loop [welcher "loop" eigentlich?] */
dito - "willkürlicher Programmauschnitt"
> > if(DOSBase) CloseLibrary(DOSBase); DOSBase = NULL;
> Wozu?
dito
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Der klassische Internet-Surfer will unterhalten werden! Wer sein
Angebot nicht ständig erneuert und außer Prospekten nichts zu bieten
hat, wird mit Nichtachtung der Internet-Gemeinde bestraft!"
(pl@net (planet), Ausgabe 8/96, S. 24)
-- MicroDot 1.11beta26 registered
Stefan Becker
a...@cob.wwbnet.de (Andreas R. Kleinert) writes:
> Achso, das war der Zweck der Sache.
Ich wußte ja nicht, daß das Aufzeigen von Alternativen hier verboten
ist.
> Die ScreenNotify-Library macht BTW bei mir nur Probleme
> mit Spot und ThumbMail (ist doch nicht etwa ein Hack ?)
> Wann gibt's ein Update ?
Es zwingt dich keiner ScreenNotify zu installieren. Ich habe nie
behauptet, daß ScreenNotify keine Probleme machen kann, denn es ist
halt ein Patch. IMHO sollte Intuition diese Funktionalität selber
anbieten, aber das tut es ja bekanntlich nicht :-(
Bis jetzt hat sich aber immer gezeigt, daß die Programme, die Probleme
mit ScreenNotify haben, selber schuld daran sind.
Stefan Becker
a...@cob.wwbnet.de (Andreas R. Kleinert) writes:
> Dann frage ich mich, warum Du die nicht schon früher öffentlich
> verfügbar gemacht hast (einzeln, einfach, unkompliziert, als Beispiel).
Den Source habe ich schon einzeln vorliegen. Was nützt der allerdings
ohne Dokumentation? Auf Anfrage stelle ich ihn aber zur Verfügung.
> - RawDoFmt()
> (es gibt bis heute keine Möglichkeit, die "Copy-Byte"-Routine,
> die angegeben werden muß, irgendwie zu ersetzen - z.B.
> durch eine Routine der amiga.lib - man *muß* 68k-Assembler
> oder ein 4-Byte-#define mit 68k-Code (oder PPC ?) verwenden)
Ich meine mich dunkel erinnern zu können, so etwas schon mal in C
geschrieben zu haben.
> Paßt ein PPC-JMP plus Adresse in 6 Bit ?
Interessiert das einen die Bohne, wenn man MakeLibrary() zur Verfügung
hat?
> Wer weiß - vielleicht steht deshalb plötzlich in den
> OS-Docs (DeveloperCD) der Hinweis, daß man nicht davon
> ausgehen kann, immer die gleiche Library-Base zurückzu-
> bekommen (für mich ein Widerspruch zur gängigen
> Programmierpraxis, es sein denn...)
Es gab KEINEN Zeitpunkt wo dieser Sachverhalt dokumentiert war (siehe
exec.library/OpenLibrary()). Es hat sich wohl nach dem Prinzip "es
funktioniert ja" eingebürgert.
> Dass SAS/C der einzige Compiler ist, der das unkompliziert und
> direkt erlaubt (vielleicht auch StormC), kann ich nicht ändern,
Mit DICE geht es genauso unkompliziert.
> auch kann ich die Portierung auf PPC nicht vorwegnehmen
> (schon gar nicht mit aktuellen Compilern).
Wie schon erwähnt: GCC.
> Wieviele davon auf die Idee kommen, nach dem Source der
> Toolmanager-Lib zu forschen, weiß ich nicht.
Es gibt ja genügend andere kürzere Library C Sourcen von mir :-)
> "Es ist ein Triumph des Siliziums, eine Meisterleistung moderner
> Steinmetzkunst." [ Scheibenwelt von A-Z, über den (Himmels-)"Computer" ]
Deutsche Übersetzung, mir dreht sich der Magen um...
Stefan Becker
fu...@karoass.gun.de (Erik Wasser) writes:
> Wie würdest du/irgendjemand dieses Problem lösen? Mir fällt da auf
> Anhieb keine Lösung ein, die ich für vertretbar halte. Problemlösung
> wäre vielleicht die Library nicht shared zu machen, sprich bei jedem
> Öffnen gibt es eine andere Library Base zurück.
Siehe Sourcen zur dospath.library. Für jeden Caller wird eine eigene
LibraryBase erzeugt und gleichzeitig die dos und utility.library
geöffnet, da deren Funktionen benötigt werden.
Michael van Elst
fu...@karoass.gun.de (Erik Wasser) writes:
>Wie würdest du/irgendjemand dieses Problem lösen? Mir fällt da auf
>Anhieb keine Lösung ein, die ich für vertretbar halte. Problemlösung
>wäre vielleicht die Library nicht shared zu machen, sprich bei jedem
>Öffnen gibt es eine andere Library Base zurück.
Irgendwo musst du einen Kontext fuer den jeweiligen Opener speichern
(wo dann zum Beispiel die jeweiligen Bases gehalten werden).
Das kann explizit sein. Jede Funktion bekommt einen zusaetzlichen
Parameter auf die opener-spezifischen Daten. Stub-Routinen koennen
den Parameter (wie die Library-Base) automatisch uebergeben. Wenn
die Library Handles auf eigene Daten vergibt, dann kann man die Bases
natuerlich auch dort unterbringen.
Du kannst fuer jeden Opener eine eigenen Base erzeugen, der Pointer
auf die owner-spezifischen Daten steckt dann natuerlich implizit im
Base-Pointer. Besonders elegant ist das nicht.
Du kannst eine Tabelle der Opener anlegen in der Task-Adresse und
Pointer auf die owner-spezifischen Daten eingetragen sind. Die
jeweiligen Funktionen suchen dann in der Tabelle nach den zugehoerigen
Daten. Das ist natuerlich nicht sehr effizient.
Du kannst eventuell auch die Libraries fuer jede Funktion einzeln
oeffnen und schliessen.
Die SysBase kann immer geshared werden.
Salut,
Ralph Babel
Van Elst meinte:
> Stefan Becker writes:
>
>> Die Init-Routine wird im Forbid() ausgeführt
>> und das wird vom Wait() unterbrochen.
>
> Die Specs garantieren uebrigens nicht den Forbid().
> Aber da das single-threading zur Zeit per Forbid()
> erreicht wird, muss man auf das Wait() verzichten.
libInit() wird nicht unter Forbid() ausgeführt.
Andreas R. Kleinert
fu...@karoass.gun.de (Erik Wasser) schrieb am 07.09.1996 um 08:37:46 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> > - Bei der Initialisierung der Library werden andere Libraries global
> > geöffnet, d.h. deren Library-Bases werden zwischen den einzelnen
> > Callern der Library geshared. Das ist ein NO-NO.
> Wie würdest du/irgendjemand dieses Problem lösen? Mir fällt da auf
> Anhieb keine Lösung ein, die ich für vertretbar halte. Problemlösung
Ganz einfach - man zieht sich auf den Standpunkt zurück, daß das
zwar in den C= Beispielsourcen genauso gemacht wurde (außer mit
den Mathieee-Libs, da ist es laut Autodocs explizit verboten), daß
das eben falsch war, und daß dann eben 90 Prozent aller 68k-Libraries
auf dem PPC in der 68k-Emulation nicht mehr laufen, weil es die
Programmierer eben immer noch nicht gelernt haben.
Auf dem PPC sind dann nicht mehr die Hardware-Hacker die Sündenböcke
(das hat ja mittlerweile jeder akzeptiert), sondern alle, die
die RKMs nicht Wort für Wort in Software umgesetzt, sondern sich
auf C='s Beispielsourcen verlassen haben.
> wäre vielleicht die Library nicht shared zu machen, sprich bei jedem
> Öffnen gibt es eine andere Library Base zurück.
Am Besten noch bei Benutzung jeder Funktion jede Library neu öffnen.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
persistent - resistant -> PERSISTANT
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> >> Allerdings ist ein Wait() in der Init-Routine nicht legal. Das ist
> >> IMHO der wesentlich groessere Fehler.
> >Forbid() ausgeführt und das wird vom Wait() unterbrochen.
> Die Specs garantieren uebrigens nicht den Forbid(). Aber da das
> single-threading zur Zeit per Forbid() erreicht wird, muss man
> auf das Wait() verzichten.
Wie ich in <yNMUbMD...@ark.cob.wwbnet.de> dargelegt habe,
ist dokumentiert, daß Open/Close/Expunge in Forbid/Permit ausgeführt wird
wobei InitLib an gleicher Stelle dagegen nicht entsprechend gekennzeichnet wird
(RKM I&A '88, Bsp.-Sourcekommentare).
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
-- MicroDot 1.11beta26 registered
Stefan Becker
A...@COB.WWBNET.DE (Andreas R. Kleinert) writes:
> Wer außerdem noch meinen (picture) Datatype-Beispielsource
> auseinandernehmen will - an dem es sicherlich wesentlich mehr
> auszusetzen gibt, da bin ich mir sicher - kann dies
> ebenfalls bald tun (dev/c/C_OS3-DT401.LHA oder *402.LHA):
Unterstützt er den V43 picture.datatype? SCNR :-)
Heinz Wrobel
Michael van Elst (mle...@serpens.swb.de) wrote:
>von disk-residenten Libraries innerhalb von libinit
>nicht allgemein funktioniert.
Am Besten (sprich kompatibel und sicher) ist im Init nichts zu
machen, was ein Wait() durchführen könnte, und dort nur eine
Semaphore zu initialisieren. Open/Close sollen dann diese Semaphore
benutzen und sind damit single threaded. Libs öffnet man dann bei
einer shared base beim ersten Open und schließt sie beim letzten
Close. Expunge gibt nur bei lib_OpenCnt == 0 die Base frei.
Mit SAS/C libinit.c läßt sich das recht einfach erreichen, indem
man
- in __UserLibInit nur einfache Daten und die Semaphore
initialisiert.
- __UserLibOpen und __UserLibClose einbaut und dort die
Semaphore benutzt und passend Resourcen öffnet/schließt.
- __UserLibCleanup leer läßt.
Damit ist man Synchronisationsprobleme ohne Forbid()-Benutzung los.
Daß bei lib_OpenCnt == 0 die Libs dann auch nichts anderes mehr
offenhalten, ist eine IMHO positive stilistische Sache, die dem
Memory-Management hilft.
--
Heinz Wrobel Private Mail: he...@hwg.muc.de
My private FAX: +49 89 850 51 25, I prefer email
Stefan Eggers
a...@cob.wwbnet.de (Andreas R. Kleinert) schrieb:
> Den nächsten Source mache ich in K&R, dann hast Du wenigstens
> einen *echten* Grund...
??? Richtig formatierter und kommentierter K&R-Code muß doch nicht
schlecht sein. Allerdings ist mit ANSI-C-Compiler immer ANSI-C vor-
zuziehen, da da der Compiler bei der Fehlersuche besser mithelfen
kann.
> >, aber bei "&= (0xFF ^ LIBF_DELEXP)" statt "&= ~LIBF_DELEXP"
> > dreht sich bei mir der Magen um :-)
>
> für stilistische Feinheiten fehlte die Zeit.
>
> So sieht man wenigstens, daß es sich um einen UBYTE-Wert handelt...
So etwas geht einem in Fleisch und Blut über und kostet keine Zeit
beim Programmieren. Mir kommt Deine Konstruktion dabei noch nicht
einmal mehr in den Sinn. Ich schreibe automatisch die zweite.
Es spart sogar ein paar Tastendrücke und ist somit etwas schneller
getippt. ;-)
Warum sollte ich mir auch die Größe einer Variable merken müssen? Das
kann der Compiler viel besser und tut er sowieso schon zwangsweise.
Wenn sich die Variablengröße ändert weil mehr Bits verwendet werden
wird Dein Code gar keine Chance haben, während der zweite mit einem
neuen Compiler-Durchlauf mit neuen Includes perfekt funktioniert.
Das ist hier vielleicht nicht von Bedeutung, aber in eigenen Program-
men ist das sehr wichtig. Da fliegt man sonst bei einer Variablen-
vergrößerung massiv auf die Schnauze und das will ich mit meinen
Sourcen nicht erleben.
Stefan Eggers
M_An...@tribal.line.org (Matthias Andree) schrieb:
> Eine neue Library-Base ist dazu nicht erforderlich, eine Liste der
> Tasks, die OpenLibrary aufgerufen haben, genügt, sozusagen den
Netter Verwaltungsaufwand, aber ich denke bei jedem Library-Aufruf die
Parameter auf Korrektheit zu prüfen bringt wesentlich mehr Nutzen.
Ein zuviel an CloseLibrary() kann ein Programmierer durch entsprechen-
de Programmstruktur vermeiden (nach CloseLibrary() den Zeiger auf NULL
setzen) und durch Library-Listing-Tools beim Debugging erkennen. Da
sehe ich daher keinen Handlungsbedarf.
Parametercheck kostet in der Regel relativ wenig Zeit und Aufwand und
würde den Programmierern bei der Fehlersuche sicherlich oft massiv
helfen. Um das nicht ausarten zu lassen kann man eine Debug-Version
mit diesen Checks und eine normale ohne erstellen, wenn die Laufzeit
sonst zu groß wird.
> ein Debug-Tool in der Art von Memwatch (wie es neueren SAS/C beiliegt)
> angezeigt.
Du meinst ein externen Prüfer, der anzeigt, ob eine Library noch offen
blieb? Wäre in einer 2.04-konformen Version sicherlich wünschenswert.
Dann aber gleich für möglichst alle Resourcen im System.
Erik Wasser
How to write: Exec shared library in 100% C" zu erzeugen:
> Siehe Sourcen zur dospath.library. Für jeden Caller wird eine eigene
> LibraryBase erzeugt und gleichzeitig die dos und utility.library
> geöffnet, da deren Funktionen benötigt werden.
Wo gibt es diesen Source? Auf den Aminet 1-12 ist er wohl nicht, oder
war ich wieder blind?
Andreas R. Kleinert
> Das gibt Dresche ;-) Wie wäre es mit geschweiften Klammern um
> CloseLibrary(xxxBase); xxxBase = NULL;? Du kannst es ja in einer Zeile
> stehen lassen. Oder Autokonstruktoren/destruktoren verwenden.
Ich hatte die Mail schon abgeschickt, und wollte nicht noch eine vierte
Variante abschicken (im Ernst: wollte ich eigentlich noch ändern).
So ist das eben, wenn man zu schnell replied.
Normalerweise hätte ich
if(IntuitionBase) { CloseLibrary(IntuitionBase); IntuitionBase = NULL; }
if(DOSBase) { CloseLibrary(DOSBase); DOSBase = NULL; }
auch definitiv verwendet, aber es war halt nur ein Beispiel (was einige
Leute schon wieder zum Anlaß genommen hatten, den Code selbst zu hinterfragen %-)
> > Start it up: LOAD "WIN95", 8, 1
> Öhm. Seit wann gibt's denn das auf Floppy?
Das faszinierendere daran wäre eigentlich: seit wann gibt's denn das für den 64er ?
;-))
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
DL SuperView: 02774-92064 (COB: AmBos,ISDN/V34)
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
mle...@serpens.swb.de (Michael van Elst) schrieb am 08.09.1996 um 12:08:26 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> >> Allerdings ist ein Wait() in der Init-Routine nicht legal. Das ist
> >> IMHO der wesentlich groessere Fehler.
> > Da ist kein explizites Wait.
> > Versteckt sich eins im Öffnen der Gfx/IntuitionBase ?
> Das weisst du nicht. Die Libraries koennten auf einem zukuenftigen
> System disk-based sein oder aus sonst welchen Gruenden ein Wait()
> ausfuehren. Da du das nicht weisst, darfst du auch nicht annehmen,
> dass es nicht passiert.
Was kann denn schlimmstenfalls passieren, wenn das Forbid/Permit (oder
was auch immer) durchbrochen wird ?
Ein anderer Task kommt zum Zuge, während RamLib noch in der Init-Routine
am werkeln ist, und öffnet schlimmstenfalls ebenfalls die Library.
Im Moment kann RamLib das AFAIK ohnehin nicht handhaben (Task muß warten),
und wenn doch (zukünftig) dann müßte sie diesen Fall eben auch
berücksichtigen (ist die Aufgabe von RamLib und nicht des Tasks).
In der RKM-Source (RKM I&A) steht nur, daß man sich in Open/Close/Expunge
"beeilen" solle, weil diese durch Forbid/Permit geschützt seien, vom
InitLib-Einstiegspunkt steht dort nichts.
Davon abgesehen wird in den offiziellen Sample-Sources zu Libraries
*grundsätzlich* immer die DOS-Library in der InitRoutine und global
geöffnet, im Sample-Source zum BMP.datatype sogar Intuition, Graphics,
DOS und Utility (im Open-Teil dann noch iffparse.library, datatypes.library
und picture.datatype).
Ich habe ja nichts gegen vorausschauende und vorsichtige Programmierung,
aber irgendwie fehlen mir da Kontinuität und Konsequenz.
Warum soll ich mehr Vorsicht walten lassen, als die Programmierer des
OS selbst in ihren Beispielsourcen ?
> >> Ist auch nicht portabel. Es geht davon aus, dass das Flags-Feld 8bit
> >> gross ist. Ein ~ erlaubt zumindest Typen <= int und wenn LIBF_DELEXP
> >> passend definiert ist auch groessere Typen.
> > Yep, das war allerdings eher Absicht.
> ???
Beim Übersetzen von Assembler
> > Beziehungsweise: ich habe vorausgesetzt, daß sich bei einer
> > Portierung die Größen aller Strukturen nicht ändern.
> Das ist halt falsch.
Ein OS wo das nicht so ist, wäre in seinen Strukturen nicht
binärkompatibel zu AmigaOS: wie sollten da die PPC-Version und
68k-Emu parallel laufen ? Außerdem wollte ich in erster Linie
Assembler assimilieren, um mögliche Portierungen zu erleichtern.
Die eigentliche Portierungsarbeit könnte man ohnehin noch nicht
vorwegnehmen (z.B. könnte man für den PPC620 ja gleich eine ULONG64-
Sprungtabelle anstelle des ULONG-Tables verwenden, etc.)
Ich hab's aber natürlich korrigiert - ich halte es nicht für einen
Fehler, aber wie Du schon sagst, könnte leicht einer daraus werden.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
Greatest Win-Feature:
ALT-F4 works with any application...
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> > Wer außerdem noch meinen (picture) Datatype-Beispielsource
> > auseinandernehmen will - an dem es sicherlich wesentlich mehr
> > auszusetzen gibt, da bin ich mir sicher - kann dies
> > ebenfalls bald tun (dev/c/C_OS3-DT401.LHA oder *402.LHA):
> Unterstützt er den V43 picture.datatype? SCNR :-)
Nein, mit Absicht nicht - denn es ist immer noch ein Beispielsource.
Die Frage stellt sich ganz einfach nicht, weil als Grafikformat "PGM"
verwendet wird, und das bietet maximal 256 Graustufen.
Für meinen neuen JFIF-Datatype ist das dagegen angedacht.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> > Paßt ein PPC-JMP plus Adresse in 6 Bit ?
> Interessiert das einen die Bohne, wenn man MakeLibrary() zur Verfügung
> hat?
Es interessiert das 68k-Programm, das in einer PPC-Umgebung Libraries aufruft.
(Muss ich eigentlich alles dreimal erläutern, oder liest auch jemand mal
die Mails komplett, ohne gleich zurückzuflamen ?)
> > Dass SAS/C der einzige Compiler ist, der das unkompliziert und
> > direkt erlaubt (vielleicht auch StormC), kann ich nicht ändern,
> Mit DICE geht es genauso unkompliziert.
Den benutze ich weder, noch ist er die Referenz.
> > "Es ist ein Triumph des Siliziums, eine Meisterleistung moderner
> > Steinmetzkunst." [ Scheibenwelt von A-Z, über den (Himmels-)"Computer" ]
> Deutsche Übersetzung, mir dreht sich der Magen um...
die stammt von Andreas Brandhorst
Andreas R. Kleinert
> - die 6-Bit-Offsets in den Libraries:
*Byte* waren natuerlich gemeint
(nein, die Computer Bild habe ich nicht gelesen %-)
Ralph Babel
Van Elst meinte inkonsequenterweise:
> Die SysBase kann immer geshared werden.
Wo ist garantiert, daß das Langwort an der virtuellen
Adresse 4 für alle Formen und Inkarnationen der
Kodeausführung immer den gleichen Wert besitzen wird?
Andreas R. Kleinert
> > >, aber bei "&= (0xFF ^ LIBF_DELEXP)" statt "&= ~LIBF_DELEXP"
> beim Programmieren. Mir kommt Deine Konstruktion dabei noch nicht
> einmal mehr in den Sinn. Ich schreibe automatisch die zweite.
Ist vollkommen richtig - mir ging es nur darum, dass es in diesem
konkreten Fall nicht wirklich *falsch* war.
Dass die Konstruktion so komisch aussieht, liegt daran, dass ich
zu sehr auf Assembler geschielt habe...
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Es ist ein Triumph des Siliziums, eine Meisterleistung moderner
Steinmetzkunst." [ Scheibenwelt von A-Z, über den (Himmels-)"Computer" ]
-- MicroDot 1.11beta26 registered
Ralph Babel
Van Elst meinte:
> Ralph Babel schrieb:
>
>> Van Elst meinte:
>>
>>> Stefan Becker writes:
>>>
>>>> Die Init-Routine wird im Forbid() ausgeführt
>>>> und das wird vom Wait() unterbrochen.
>>>
>>> Die Specs garantieren uebrigens nicht den Forbid().
>>> Aber da das single-threading zur Zeit per Forbid()
>>> erreicht wird, muss man auf das Wait() verzichten.
>>
>> libInit() wird nicht unter Forbid() ausgeführt.
>
> Das aendert nichts an der Tatsache, dass das Oeffnen
> von disk-residenten Libraries innerhalb von libinit
> nicht allgemein funktioniert.
»Meine Prämisse wurde zwar widerlegt,
aber meine Folgerung erhalte ich aufrecht.«
Stefan Becker
fu...@karoass.gun.de (Erik Wasser) writes:
> Wo gibt es diesen Source? Auf den Aminet 1-12 ist er wohl nicht, oder
> war ich wieder blind?
DOSPath 1.0 habe ich erst vor kurzem freigegeben. Sie dürfte also erst
auf der Aminet CD 14 erscheinen. Also wirf' lieber den FTP an :-)
Gunther Nikl
Andreas R. Kleinert (A...@COB.WWBNET.DE) wrote:
> > Unterstützt er den V43 picture.datatype? SCNR :-)
> Nein, mit Absicht nicht - denn es ist immer noch ein Beispielsource.
> Die Frage stellt sich ganz einfach nicht, weil als Grafikformat "PGM"
> verwendet wird, und das bietet maximal 256 Graustufen.
Und? Auch dann ist V43 vorteilhaft.
Gunther
Heinz Wrobel
> aber irgendwie fehlen mir da Kontinuität und Konsequenz.
Korrekt.
> Warum soll ich mehr Vorsicht walten lassen, als die Programmierer des
> OS selbst in ihren Beispielsourcen ?
Weil Du inzwischen schlauer bist?
> Ein OS wo das nicht so ist, wäre in seinen Strukturen nicht
> binärkompatibel zu AmigaOS: wie sollten da die PPC-Version und
Und?
> 68k-Emu parallel laufen ? Außerdem wollte ich in erster Linie
Warum sollte das so sein müssen?
> Ich hab's aber natürlich korrigiert - ich halte es nicht für einen
> Fehler, aber wie Du schon sagst, könnte leicht einer daraus werden.
Irgendjemand hat irgendwo geschrieben "nur ein Beispiel". _Gerade_
ein Beispiel muß suaber sein. Sonst ist es _nur_ ein Hack.
Aaron Digulla
Ralph Babel wrote in de.comp.sys.amiga.tech about "Re: How to write: Exec
shared library in 100% C":
> > Die SysBase kann immer geshared werden.
> Wo ist garantiert, daß das Langwort an der virtuellen Adresse 4 für alle
> Formen und Inkarnationen der Kodeausführung immer den gleichen Wert
> besitzen wird?
RKRM Libraries p13: "... The only absolute address in the system is $0000
0004, which contains a pointer to the Exec library base. ..."
Dass der Wert sich während einer Sitzung aendert halte ich zwar fuer
theoretisch moeglich, aber wo waere der praktische Nutzen ? Bei AROS
haben wir das Problem dadurch umgangen, dass die erste Funktion im
Quellcode mit der SysBase als Parameter aufgerufen wird.
--
Aaron "Optimizer" Digulla Team AMIGA AROS Head of Development
Author of XDME, ResTrackLib, CInt. (since no one else wanted)
"(to) optimize: Make a program faster by improving the algorithms rather than
by buying a faster machine."
Matthias Andree
A...@COB.WWBNET.DE (Andreas R. Kleinert) schrieb am 10.09.1996 um 10:36:55 Uhr
zu Re: How to write: Exec shared library in 100% C folgendes:
> > > Start it up: LOAD "WIN95", 8, 1
> > Öhm. Seit wann gibt's denn das auf Floppy?
>
> Das faszinierendere daran wäre eigentlich: seit wann gibt's denn das für den 64er ?
> ;-))
Nicht fragen, kaufen. ;-)
Gruß,
--
MATTHIAS ANDREE
Öffentlicher PGP-Schlüssel auf Anfrage verfügbar
Michael van Elst
rba...@babylon.pfm-mainz.de (Ralph Babel) writes:
>Van Elst meinte inkonsequenterweise:
>> Die SysBase kann immer geshared werden.
>Wo ist garantiert, daß das Langwort an der virtuellen
>Adresse 4 für alle Formen und Inkarnationen der
>Kodeausführung immer den gleichen Wert besitzen wird?
Seite 5 und 467.
Michael van Elst
A...@COB.WWBNET.DE (Andreas R. Kleinert) writes:
> Was kann denn schlimmstenfalls passieren, wenn das Forbid/Permit (oder
> was auch immer) durchbrochen wird ?
Auch das weisst du nicht :) Im Moment kannst du sogar das Forbid
durchbrechen, du darfst nur keine Libraries aufmachen weil ramlib
sich nicht beliebig selbst aufrufen kann (wenn eine Library eine Library
aufmacht, die eine Library aufmacht, dann gibts crashes). Vielleicht
gibt es auch noch andere Probleme.
Aber das ist unwesentlich. Du solltest dich niemals am Verhalten
der realen Implementation ausrichten. Und die Forderung nach
Einhaltung eines Forbid() mag zwar Overkill sein, vermeidet aber
sehr viele Probleme und ermoeglicht Verbesserungen in zukuenftigen
OS-Versionen. Code, der nach dem "es geht doch"-Prinzip gebaut wird
> In der RKM-Source (RKM I&A) steht nur, daß man sich in Open/Close/Expunge
> "beeilen" solle, weil diese durch Forbid/Permit geschützt seien, vom
> InitLib-Einstiegspunkt steht dort nichts.
Korrekt. Aber Init hat ebenfalls solche Probleme. Mit dem Verbot
eines Wait() gehst du diesen aus dem Weg.
> Davon abgesehen wird in den offiziellen Sample-Sources zu Libraries
> *grundsätzlich* immer die DOS-Library in der InitRoutine und global
> geöffnet,
Auch Beispielsourcen koennen Fehler haben. Die gezeigten Routinen
_funktionieren_ sogar im Moment. Hauptsaechlich weil dos.library
schon im Speicher ist.
> im Sample-Source zum BMP.datatype sogar Intuition, Graphics,
> DOS und Utility (im Open-Teil dann noch iffparse.library, datatypes.library
> und picture.datatype).
iffparse, datatypes und der datatype muessen ja eventuell auch geladen
werden. Da wuerde sich der Fehler eventuell toedlich auswirken. Das
heisst nicht, dass das Oeffnen der dos.library im init die beste Idee
ist.
> Ich habe ja nichts gegen vorausschauende und vorsichtige Programmierung,
> aber irgendwie fehlen mir da Kontinuität und Konsequenz.
Dann darfst du leider nie Fehler berichtigen.
> Warum soll ich mehr Vorsicht walten lassen, als die Programmierer des
> OS selbst in ihren Beispielsourcen ?
Weil auch OS-Programmierer Fehler machen ?
>> Das ist halt falsch.
> Ein OS wo das nicht so ist, wäre in seinen Strukturen nicht
> binärkompatibel zu AmigaOS:
Das ist richtig. Aber es waere immer noch source-kompatibel.
> wie sollten da die PPC-Version und
> 68k-Emu parallel laufen ?
Das ist eine ganz andere Frage. Ein emulierter 68k muss in jedem Fall
ein kompatibles API zur Verfuegung gestellt bekommen.
> Außerdem wollte ich in erster Linie
> Assembler assimilieren, um mögliche Portierungen zu erleichtern.
Tja. Leider ist dein Source immer noch compiler-spezifisch. Das hilft
leider nicht viel.
> Ich hab's aber natürlich korrigiert - ich halte es nicht für einen
> Fehler, aber wie Du schon sagst, könnte leicht einer daraus werden.
:)
Michael van Elst
rba...@babylon.pfm-mainz.de (Ralph Babel) writes:
Lern lieber zitieren. Ein bisschen zivilisiertes Verhalten
koennte auch nicht schaden, so machst du dich nur laecherlich.
Andreas R. Kleinert
he...@hwg.muc.de (Heinz Wrobel) schrieb am 13.09.1996 um 11:39:56 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> > Ich habe ja nichts gegen vorausschauende und vorsichtige Programmierung,
> > aber irgendwie fehlen mir da Kontinuität und Konsequenz.
> Korrekt.
Danke.
> > Warum soll ich mehr Vorsicht walten lassen, als die Programmierer des
> > OS selbst in ihren Beispielsourcen ?
> Weil Du inzwischen schlauer bist?
s.u.
> > Ein OS wo das nicht so ist, wäre in seinen Strukturen nicht
> > binärkompatibel zu AmigaOS: wie sollten da die PPC-Version und
> Und?
s.u.
> > 68k-Emu parallel laufen ? Außerdem wollte ich in erster Linie
> Warum sollte das so sein müssen?
Stets wurde der Mac als Beispiel für die PPC-Portierung genannt.
Dort ist dies so, daß 68k-Prozesse und Anwendungen parallel zur
PPC-Umgebung laufen (können), und daß 68k-Anwendungen von native-Teilen
des OS-Kernel automatisch profitieren (umgekehrt aber auch 68k-Altlasten
von PPC-Prozessen genutzt werden).
Sollte sich AT von diesem Gedanken verabschiedet haben, wo wäre dann
noch der Unterschied zwischen einer API, einer Sammlung von "amiga.lib"s
für Unix, und einem echten, eigenständigen OS ?
Die Softwarebasis wäre futsch, und rekompilieren müßte man jedes Programm
ohnehin. Für Liebhaber gäbe es dann noch den UAE (oder ähnlich), vielleicht
gleich für jedes Programm eine eigene Virtual Machine.
Besser als nichts, aber der andere Ansatz gefällt mir besser.
> > Ich hab's aber natürlich korrigiert - ich halte es nicht für einen
> > Fehler, aber wie Du schon sagst, könnte leicht einer daraus werden.
> Irgendjemand hat irgendwo geschrieben "nur ein Beispiel". _Gerade_
> ein Beispiel muß suaber sein. Sonst ist es _nur_ ein Hack.
Das stimmt - das "nur ein Beispiel" bezog sich übrigens auf eine andere
Sache, in einem Seitenthread.
* ich will nicht ausschließen, daß ich irgendetwas übersehen oder
falsch interpretiert haben könnte
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
Start it up: LOAD "WIN95", 8, 1
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
gn...@informatik.uni-rostock.de (Gunther Nikl) schrieb am 13.09.1996 um 08:53:57 Uhr, eine Mail unter dem Betreff "Re: How to write: OS3-DT".
Dazu habe ich folgendes zu sagen:
> > > Unterstützt er den V43 picture.datatype? SCNR :-)
> > Nein, mit Absicht nicht - denn es ist immer noch ein Beispielsource.
> > Die Frage stellt sich ganz einfach nicht, weil als Grafikformat "PGM"
> > verwendet wird, und das bietet maximal 256 Graustufen.
> Und? Auch dann ist V43 vorteilhaft.
Ja klar (chunky bitmap vielleicht), aber es gibt noch einen anderen Grund:
seit wann ist der pic-dt V43 offiziell in's OS integriert ?
Sowas kann man immer noch nachschieben.
Für mich sind V40-Dataytypes und die V43-Erweiterungen immer noch zwei
verschiedene Dinge, die zwar aufeinander aufbauen, aber wer garantiert mir
denn, daß das von AT favorisierte Interface dem V43-Interface entsprechen wird ?
Zwei Sourcen für zwei Zwecke.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
WWW - Weird Wild Wet ;-)
-- MicroDot 1.11beta26 registered
Olaf Barthel
In Article <yMuWSMD...@ark.cob.wwbnet.de>, Andreas R. Kleinert <A...@COB.WWBNET.DE> wrote:
> Stefan...@nmp.nokia.com (Stefan Becker) schrieb am 06.09.1996 um 08:17:59 Uhr, eine Mail unter dem Betreff "Re: How to write:
> Exec shared library in 100% C".
> Dazu habe ich folgendes zu sagen:
>
> > > IMHO der wesentlich groessere Fehler.
> > Forbid() ausgeführt und das wird vom Wait() unterbrochen.
>
> auch gegen Disk-Libraries geschützt sein muß (verursacht ein
> Open(), LoadSeg(), etc. etwa kein Wait() ?)
Es geht nicht um's Wait() oder darum, potentiell ein Forbid() zu
unterbrechen. Die Library-Initialisierungsfunktion wird ohnehin nicht
notwendigerweise unter Forbid() ausgefuehrt, eigentlich ist es eher
unwahrscheinlich, dass es so passiert. Was gravierender ist, ist dass
ramlib beim Laden von Libraries und Devices eine Warteschlange abarbeitet:
Wenn Du in Deiner Initialisierungsroutine eine Matrix mit 676 Elementen
invertierst, hat dies mit einiger Wahrscheinlichkeit zur Folge, dass
andere Programme auf das Oeffnen ihrer disk-residenten Libraries und
Devices werden unverhaeltnismaessig lange warten muessen, bis Deine
Initialisierungsroutine beendet ist. Erst danach kann ramlib sich um
die naechste Anforderung kuemmern.
--
Home: Olaf Barthel, Brabeckstrasse 35, D-30559 Hannover
Net: ol...@sourcery.han.de
Michael van Elst
A...@COB.WWBNET.DE (Andreas R. Kleinert) writes:
> Also einen Zeiger auf etwas, das schon vorhanden war, und nicht etwas,
> das mit dem Aufruf durch einen *bestimmten* Prozeß erst noch generiert und
> intialisiert *werden* muß (bestenfalls ausnahmsweise modifiziert).
Rule #1: Do not assume.
> Ergo:
> Aus den V40-Autodocs geht jedenfalls relativ eindeutig hervor, daß die
> LibraryBase als solches immer dieselbe sein muß.
Nein !
> Daß Base-Sharing
> *in* *der* *Regel* legal sein sollte, geht IMHO daraus hervor, daß C= es
> selbst in den Beispielsourcen praktiziert,
Und die Tatsache dass sie es _explizit_ in den RKRMs _verbieten_
bedeutet dir wohl gar nichts ?
> Um nochmal darauf zurückzukommen, daß die Library-Base immer die gleiche
> sein muß:
Sie muss es nicht, sie ist es nicht. Weder Theorie noch Praxis stimmen
auch mit deinen Vorstellungen ueberein.
> wenn es sich also immer um die gleiche Base handelt -
Was es de facto nicht tut !
> Library-Base zu bekommen, ist für mich a) nicht überzeugend,
Was in der offiziellen Dokumentation steht ist also nicht ueberzeugend.
> und b)
> vielleicht sogar mißverständlich (&IntuitionBase ist vermutlich immer dieselbe,
> während eine disk-basierte Library immer eine andere Base liefert).
Genau _deswegen_ ist es ja nicht missverstaendlich beschrieben. Du
_darfst_ nicht voraussetzen, dass eine Base geshared werden kann.
Michael van Elst
A...@COB.WWBNET.DE (Andreas R. Kleinert) writes:
> Die offiziellen Beispielsources von C= machen es nicht anders,
> also muß es in *diesem* Fall schonmal legal sein,
Nein, das besagt nur, dass es funktioniert. Legal waere es, wenn
genau diese Praxis ausdruecklich erlaubt wuerde. Statt dessen aber,
war sowas frueher ueberhaupt nicht dokumentiert und in den
aktuellen RKRMs steht _explizit_ drin, dass du es _nicht_ tun
sollst.
Ich sehe auch das Problem nicht. Der Aufwand fuer die defensive
ist minimal, warum also nicht diese benutzen und damit moeglichen
Inkompatibilitaeten aus dem Weg gehen ?
> Abgesehen davon halte ich es für die denkbar schlechteste Lösung,
> task/prozeßpezifische Dinge ausgerechnet in der LibraryBase
> unterbringen zu wollen
Wenn du das API nicht aendern willst, dann ist die einzige effiziente
Loesung.
Allerdings gaebe es fuer ein zukuenftiges OS auch andere Moeglichkeiten.
Z.B. koennte man ein Ressource-Tracking-System nehmen, das der Library
erlaubt, ihre privaten Daten an die Task-Struktur zu haengen und sie
von dort auch wieder abzufragen.
> Es ist - kein Assembler mehr enthalten
> - kein Assembler mehr enthalten
> - kein Assembler mehr enthalten
Wo ist der Witz bei der Sache ? Ob du nun SAS/C mit oder ohne
Assembler benutzen musst ist ja wohl egal (und nebenbei brauchst
du den Assembler nicht zu benutzen, weil das einzige Assembler-Modul
schon assembliert in LIB: rumliegt).
> Stichwort: - Crosscompiler PCC->68k
Diese muesste die SAS/C-Spezialitaeten kennen.
> - saubere Programmierung von Library aus
> einer reinen C-Umgebung heraus
Quark mit Sosse. Wo ist __asm+Co reines C ?
Aaron Digulla
Bernhard Moellemann wrote in de.comp.sys.amiga.tech about "Re: How to
write: Exec shared library in 100% C":
> > Dass der Wert sich während einer Sitzung aendert halte ich zwar fuer
> > theoretisch moeglich, aber wo waere der praktische Nutzen ?
> Vielleicht siehst _Du_ nur keinen Nutzen, andere aber schon? Was wenn
> AmigaOS-NT feststellt, ob Dein Task eine "native" Anwendung ist oder
> nicht und dem Programm unterschiedliche SysBases zuschiebt?
Macht immer noch wenig Sinn. Bei AROS haben wir das gleiche Problem gehabt
und uns entschieden dem Programm die SysBase beim Aufruf mitzugeben. Dann
gibt es keine Probleme (auch nicht mit VMM oder so).
Aaron Digulla
Andreas R. Kleinert wrote in de.comp.sys.amiga.tech about "Re: How to
write: Exec shared library in 100% C":
> > AROS hat inzwischen shared libs wie auf dem Amiga. Das laesst sich mit
> > dem GCC unter Linux/x86 ohne Probleme uebersetzen und es tut (aeh...
> > im Moment leider nicht, weil ein Bug das ganze abstuerzen laesst; aber
> > es hat mal getan ;)
> wenn Du so eine Library mit GCC/68k übersetzt, kommt allerdings sicher
> keine unter AmigaOS lauffähige Lib dabei heraus ?
Habe ich noch nicht probiert, aber es sollte schon eine lauffähige Lib
rauskommen; vor allem, was Parameter-Übergabe in Registern und
SetFunction() angeht. AROS *ist* fast 100% kompatibel zum AmigaOS. Daher,
wie mlelstv schon richtig bemerkt hat, ist zB. MP nicht möglich (ausser
jemand hat noch eine geniale Idee).
Bernhard Moellemann
Aaron "Optimizer" Digulla schrieb:
> Ralph Babel wrote in de.comp.sys.amiga.tech about "Re: How to write: Exec
> shared library in 100% C":
>
> > > Die SysBase kann immer geshared werden.
> > Wo ist garantiert, daß das Langwort an der virtuellen Adresse 4 für alle
> > Formen und Inkarnationen der Kodeausführung immer den gleichen Wert
> > besitzen wird?
>
> RKRM Libraries p13: "... The only absolute address in the system is $0000
> 0004, which contains a pointer to the Exec library base. ..."
Genau, der Zeiger auf SysBase steht an derselben Stelle.
> Dass der Wert sich während einer Sitzung aendert halte ich zwar fuer
> theoretisch moeglich, aber wo waere der praktische Nutzen ?
Vielleicht siehst _Du_ nur keinen Nutzen, andere aber schon? Was wenn
AmigaOS-NT feststellt, ob Dein Task eine "native" Anwendung ist oder
nicht und dem Programm unterschiedliche SysBases zuschiebt?
Bernhard //
\X/
Stefan Zeiger
Bernhard Moellemann schrieb:
> Aaron "Optimizer" Digulla schrieb:
> > RKRM Libraries p13: "... The only absolute address in the system is $00=
00
> > 0004, which contains a pointer to the Exec library base. ..."
>
> Genau, der Zeiger auf SysBase steht an derselben Stelle.
In diesem Zusammenhang mu=DF man nat=FCrlich auch noch S.467 erw=E4hnen: ".=
..the
only library base sharable between tasks is Exec's library base."
Michael van Elst
"Bernhard Moellemann" <z...@mhystic.hall.sub.org> writes:
>müssen. Besonders brutal bremst das ARexx aus, weil das Function
>Libraries bei jedem Befehl neu öffnet und anschließend schließt.
Das Verhalten von AREXX ist eh nervig und gehoert gefixt.
>Mit obiger Empfehlung brauchen wir kein libInit: wenn ramlib die
>SegListen der Libaries zwischenspeichert, können wir es entsorgen und
>alles in libOpen() packen. Der Programmierer muß dann nur noch die
>Fälle OpenCnt==0 und OpenCnt>0 unterscheiden 8-(
Schon wahr. Aber da wuerde ich eher die Begrenzungen von LibInit
aufheben. Wenn du memory protection einfuehrst, dann vereinfacht
das ein paar Dinge.
Salut,
Ralph Babel
Andreas Kleinert schrieb:
> Was kann denn schlimmstenfalls passieren, wenn das
> Forbid/Permit (oder was auch immer) durchbrochen wird ?
Daß Van Elst anfängt zu pöbeln - sonst eigentlich nichts.
> Ein anderer Task kommt zum Zuge, während RamLib noch in
> der Init-Routine am werkeln ist, und öffnet
> schlimmstenfalls ebenfalls die Library.
>
> Im Moment kann RamLib das AFAIK ohnehin nicht handhaben
> (Task muß warten), und wenn doch (zukünftig) dann müßte
> sie diesen Fall eben auch berücksichtigen (ist die Aufgabe
> von RamLib und nicht des Tasks).
Korrekt.
Stefan Becker
A...@COB.WWBNET.DE (Andreas R. Kleinert) writes:
> Ich habe ja nichts gegen vorausschauende und vorsichtige Programmierung,
> aber irgendwie fehlen mir da Kontinuität und Konsequenz.
Genau deswegen bin ich inzwischen der Meinung, daß die Hüter des Grals
(wer das auch immer momentan sein mag) die Ausnahmen OFFIZIELL
dokumentieren sollten. Also z.B. "die Library Bases von DOS,
Intuition, Graphics.... dürfen zwischen Tasks geshared werden" als
Text im DevInfo Verzeichnis auf der Amiga Developer CD.
> Warum soll ich mehr Vorsicht walten lassen, als die Programmierer des
> OS selbst in ihren Beispielsourcen ?
Ich halte die meisten Beispiele in den RKMs für Quick Hacks, die grob
zeigen wie etwas gemacht wird. Eine offizielle Dokumentation sind sie
allerdings nicht.
Krause Michael
rba...@babylon.pfm-mainz.de (Ralph Babel) gab am 12.09.1996 um 20:50:42 Uhr folgenden Text von sich:
> Van Elst meinte inkonsequenterweise:
>
> > Die SysBase kann immer geshared werden.
>
> Wo ist garantiert, daß das Langwort an der virtuellen
> Adresse 4 für alle Formen und Inkarnationen der
> Kodeausführung immer den gleichen Wert besitzen wird?
Ich glaube, hier wird etwas mißverstanden -- Die SysBase kann (muß)
gesharet werden, aber nicht der gecachte Wert der SysBase: Exec muß sich
darum kümmern, daß 0x4 für jeden Task den jeweils richtigen Wert enthält,
reentrante Programmteile dürfen natürlich nicht auf einen im Startup (z.B.
Device- oder Library-Init) gecachten Wert zurückgreifen. Wenn man die
Adresse schon cachen will, muß das beim Start jedes Device-Prozeßes
geschehen.
Oder hab' /ich/ jetzt was mißverstanden?!?
---
******* Michael Krause ****************************************************
http://www.szczecin.pl/~rawstyle/
******* ProNET support ****************************************************
Ralph Babel
Aaron Digulla schrieb:
> Ralph Babel wrote:
>
>> Wo ist garantiert, daß das Langwort an der virtuellen
>> Adresse 4 für alle Formen und Inkarnationen der
>> Kodeausführung immer den gleichen Wert besitzen wird?
>
> RKRM Libraries p13: "... The only absolute address in the
> system is $0000 0004, which contains a pointer to the Exec
> library base. ..."
Bezug zu meiner Frage? Du verwechselst Adresse und Inhalt.
> Bei AROS haben wir das Problem dadurch umgangen, dass die
> erste Funktion im Quellcode mit der SysBase als Parameter
> aufgerufen wird.
Sehr vernünftig.
Heinz Wrobel
Bernhard Moellemann (z...@mhystic.hall.sub.org) wrote:
>Heinz Wrobel schrieb:
>
>> Daß bei lib_OpenCnt == 0 die Libs dann auch nichts anderes mehr
>> offenhalten, ist eine IMHO positive stilistische Sache, die dem
>> Memory-Management hilft.
>
>Das ist kaum nötig, wenn libExpunge() korrekt funktioniert. Es bremst
Wie definierst Du hier korrekt? In Expunge darfst Du nicht warten
oder viel Zeit verbrauchen, also auch kein CloseLibrary() aufrufen,
denn das könnte ja warten. Damit fällt Resource schließen, i.e.
CloseLibrary() o.Ä. in Expunge aus.
>müssen. Besonders brutal bremst das ARexx aus, weil das Function
>Libraries bei jedem Befehl neu öffnet und anschließend schließt.
Dummheit der ARexx Implementierung, nicht der Lib.
>Mit obiger Empfehlung brauchen wir kein libInit: wenn ramlib die
Nicht ganz. Eine single thread semaphore per Lib und eine semaphore
per lib system sind zwei par stiefel. Single threading per lib
semaphore erlaubt allgemein gestaffeltes Diskresidentes lib öffnen.
Single therading per single semaphroe im OS ist schwierig, wie wir
ja schon erlebt haben. Außerdem gibt es durchaus oft statische
Werte, die nicht per Open == 0 gesetzt werden müssen. Und nicht
jede lib muß per Open == 0 externes Zeug aufrufen. Die Trennung
Open/Close Init/Expunge ist durchaus nicht dämlich.
Andreas R. Kleinert
> > Was kann denn schlimmstenfalls passieren, wenn das Forbid/Permit (oder
> > was auch immer) durchbrochen wird ?
> Auch das weisst du nicht :)
Das war eine rhetorische Frage, die ich darauf folgend beantwortet
hatte (aber vermutlich war das Deine ebenfalls... :)
> Im Moment kannst du sogar das Forbid
> durchbrechen, du darfst nur keine Libraries aufmachen weil ramlib
> sich nicht beliebig selbst aufrufen kann (wenn eine Library eine Library
> aufmacht, die eine Library aufmacht, dann gibts crashes). Vielleicht
> gibt es auch noch andere Probleme.
Das ist ja genau der Punkt :-)
> Aber das ist unwesentlich. Du solltest dich niemals am Verhalten
> der realen Implementation ausrichten. Und die Forderung nach
> Einhaltung eines Forbid() mag zwar Overkill sein, vermeidet aber
> sehr viele Probleme und ermoeglicht Verbesserungen in zukuenftigen
> OS-Versionen.
Ich finde es schlicht nicht akzeptabel, dass Referenzimplementationen
aus den RKMs auf einmal schlimme Hacks sein sollen.
Das mag zwar im Interesse einer PPC-Portierung sein (und deshalb allgemein
beachtet werden), aber es ist letztlich nicht im Interesse der Anwender
(des bestehenden 68k-Systems und kommender Emulationen).
Davon abgesehen ist Forbid() mittlerweile auch als "obsolete" deklariert,
d.h. wenn schon, dann dürfte der Library-Porgrammierer *gar* *nichts* fordern,
und sich auf *gar* *nichts* verlassen, das eingehalten oder nicht eingehalten
wird, sondern müsste sich sein jeweiliges Semaphoren-System selber basteln.
Sollte sich das wirklich in dieser Form im neuen OS manifestieren, wird
das Chaos a la Windows-DLLs nicht lange auf sich warten lassen.
> Code, der nach dem "es geht doch"-Prinzip gebaut wird
Dann ist das ganze OS nach diesem Prinzip gebaut worden.
Um es klarer auszudrücken: Der Argumentationsweg "es war zwar ursprünglich
nicht vorgesehen, aber für die Portierung brauchen wird das" leuchtet mir
eher ein, als Dein "die OS-Programmierer wußten eben nicht, wie's richtig geht".
Richtig ist, daß 1985 noch niemand etwas von einer PPC- (oder überhaupt) Portierung
ahnen konnte - aber deshalb läßt sich die OS-Geschichte nicht einfach umschreiben.
Leider.
> > In der RKM-Source (RKM I&A) steht nur, daß man sich in Open/Close/Expunge
> > "beeilen" solle, weil diese durch Forbid/Permit geschützt seien, vom
> > InitLib-Einstiegspunkt steht dort nichts.
> Korrekt. Aber Init hat ebenfalls solche Probleme. Mit dem Verbot
> eines Wait() gehst du diesen aus dem Weg.
Es ist nirgendwo dokumentiert, wie RamLib arbeitet, daß man also,
irgendwelche Dinge in InitLib *nicht* tun sollte (V40, ab V37).
Wonach soll man sich jetzt richten ?
Nach Beispielsourcen (Du sagst: nein), nach dem NDUK (dort steht es nicht),
oder nach den guten Ratschlägen erfahrener OS-Programmierer (ich wette,
jetzt sagen hier drei Dutzend Leute: ja) ?
> Auch Beispielsourcen koennen Fehler haben. Die gezeigten Routinen
> _funktionieren_ sogar im Moment. Hauptsaechlich weil dos.library
> schon im Speicher ist.
Das ist kein Einzelfehler.
> > im Sample-Source zum BMP.datatype sogar Intuition, Graphics,
> > DOS und Utility (im Open-Teil dann noch iffparse.library, datatypes.library
> > und picture.datatype).
> iffparse, datatypes und der datatype muessen ja eventuell auch geladen
> werden. Da wuerde sich der Fehler eventuell toedlich auswirken. Das
Eben.
> heisst nicht, dass das Oeffnen der dos.library im init die beste Idee
> ist.
Trotzdem ist auch mit dem Öffnen der Libraries in OpenLib (wie im BMP.dt)
das Argument mit den "gemeinsamen" (oder geshareten ?) Library-Basen immer
noch im Raum.
Vermutlich sind hier die OS-Sourcen auch fehlerhaft, oder "man" wußte nicht,
wie's richtig funktioniert...
> > Ich habe ja nichts gegen vorausschauende und vorsichtige Programmierung,
> > aber irgendwie fehlen mir da Kontinuität und Konsequenz.
> Dann darfst du leider nie Fehler berichtigen.
Fehler im Konstruktionsprinzip ? Oder Fehler in der Implementierung ?
> > Warum soll ich mehr Vorsicht walten lassen, als die Programmierer des
> > OS selbst in ihren Beispielsourcen ?
> Weil auch OS-Programmierer Fehler machen ?
Das war kein Fehler, das waren umgesetzte 1985-68k-AmigaOS-Programmierrichtlinien.
Andy Finkel, Carl Sassenrath, David Junod - haben die alle nur "Fehler" gemacht ?
> > Ein OS wo das nicht so ist, wäre in seinen Strukturen nicht
> > binärkompatibel zu AmigaOS:
> Das ist richtig. Aber es waere immer noch source-kompatibel.
Bedingt. Darauf kann man sich allerdings IMHO nicht *wirklich* vorbereiten, bevor
es nicht auch wirklich existiert.
> > wie sollten da die PPC-Version und
> > 68k-Emu parallel laufen ?
> Das ist eine ganz andere Frage. Ein emulierter 68k muss in jedem Fall
> ein kompatibles API zur Verfuegung gestellt bekommen.
Und was ist mit dem Nutzen von PPC-Libs durch 68k-Tasks, und der Kommunikation
von 68k-Tasks mit PPC-Tasks, etc. ?
Alles *ein* System, oder ein PPC-System mit "angeflanschter" 68k-Emulation (UAE ?).
> > Außerdem wollte ich in erster Linie
> > Assembler assimilieren, um mögliche Portierungen zu erleichtern.
> Tja. Leider ist dein Source immer noch compiler-spezifisch. Das hilft
> leider nicht viel.
Den Leuten, die kein Assembler können/wollen/mögen, schon (wenn man die
eigentliche Arbeit "versteckt" vom Compiler erledigen läßt - wie beim
SLINK-Feature des SAS/C - kann man ja erst recht nicht 100% sicher sein,
*was* der Compiler da eigentlich macht ;-)
Jedenfalls hat sich über diverse Assembler Sourcen, die a) alle Libraries
in LibInit öffnen und b) alle Bases sharen, niemals jemand aufgeregt,
aber als C-Source ist es auf einmal ein kleines Verbrechen...
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Per definitionem sind alle Theorien über den Ursprung
des Universums richtig." [ Scheibenwelt von A-Z, über "Anfang, der" ]
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
mle...@serpens.swb.de (Michael van Elst) schrieb am 10.09.1996 um 04:41:59 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> >libInit() wird nicht unter Forbid() ausgeführt.
> Das aendert nichts an der Tatsache, dass das Oeffnen
> von disk-residenten Libraries innerhalb von libinit
> nicht allgemein funktioniert.
Warum und dass es nicht funktioniert, ist allerdings nirgendwo dokumentiert,
also somit eher ein RamLib-Bug als eine Implementationsrestriktion.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Es ist ein Triumph des Siliziums, eine Meisterleistung moderner
Steinmetzkunst." [ Scheibenwelt von A-Z, über den (Himmels-)"Computer" ]
-- MicroDot 1.11beta26 registered
hartmut Goebel
Michael van Elst (mle...@serpens.swb.de) schrieb:
>>müssen. Besonders brutal bremst das ARexx aus, weil das Function
>>Libraries bei jedem Befehl neu öffnet und anschließend schließt.
>
>Das Verhalten von AREXX ist eh nervig und gehoert gefixt.
In ARexx gehört noch eine ganze Menge anderren Dinge gefixt, auch im Bereich
Lib-Handling.
+++hartmut
PGP fingerprint = BF DD D6 75 7C 03 21 52 47 65 50 7F 54 47 06 C7
Bernhard Moellemann
Stefan Becker schrieb:
> Genau deswegen bin ich inzwischen der Meinung, daß die Hüter des Grals
> (wer das auch immer momentan sein mag) die Ausnahmen OFFIZIELL
> dokumentieren sollten.
Das ist auch meine Meinung. Zusätzlch sollte jeder Programmierer einen
Library einfach dokumentieren, ob sie für jeden Task einzeln geöffnet
werden muß oder nicht.
Bernhard //
\X/
Stefan Zeiger
Andreas R. Kleinert schrieb:
> und diesen dann verwenden. Wo ist das Problem ?
Nochmal: Es ist ein stilistisches Problem. (APTR) funktioniert nat=FCrlich
auch. Du verwendest hier aber einen Typecast, um einen impliziten Typecast
durch (void *) zu erm=F6glichen. Die Verwendung von (APTR) macht dies nicht
deutlich.
--
"Das Sch=F6ne an eMail: Sie k=F6nnen v=F6llig spontan drauflosschreiben, oh=
ne sich
um Gro=DF- und Kleinschreibung oder Kommaregeln zu k=FCmmern. Die Briefpos=
t geht
schweren Zeit entgegen." (Werbeprospekt der 1&1 Direkt GmbH, Oktober 1996)
Andreas R. Kleinert
> > Also einen Zeiger auf etwas, das schon vorhanden war, und nicht etwas,
> > das mit dem Aufruf durch einen *bestimmten* Prozeß erst noch generiert und
> > intialisiert *werden* muß (bestenfalls ausnahmsweise modifiziert).
> Rule #1: Do not assume.
Ich weiss durchaus, worauf Du hinauswillst: siehe meine andere Mail dazu:
> > Daß Base-Sharing
> > *in* *der* *Regel* legal sein sollte, geht IMHO daraus hervor, daß C= es
> > selbst in den Beispielsourcen praktiziert,
> Und die Tatsache dass sie es _explizit_ in den RKRMs _verbieten_
> bedeutet dir wohl gar nichts ?
Sie bedeutet für mich, daß sie ihre Theorie in der Praxis nicht umgesetzt
haben, sondern "vorsichtshalber" dem Programmierer dies veboten haben.
> Was in der offiziellen Dokumentation steht ist also nicht ueberzeugend.
es ist nicht *eindeutig* - in Theorie vs. Praxis
Andreas R. Kleinert
> > > > - RawDoFmt() (es gibt bis heute keine Möglichkeit, die
> > > > "Copy-Byte"-Routine, die angegeben werden muß, irgendwie zu ersetzen
[...]
> > > Das geht auch komplett in C. Beispiel für gcc: | void
[...]
> Tja, AROS machts. Da sieht es so aus:
[...]
> Das laesst sich ueberall uebersetzen (ok, es sieht nicht so doll aus...) und
> funktioniert auch auf dem Amiga. Die Macros werden in einem System- und
> Compilerspezifischen Include-File entsprechend umgesetzt.
Dass es prinzipiell mit irgendwelchen Registerfunktionen geht, ist mir klar.
Was mich stört, ist, daß es nicht eine Standard-Funktion gibt, die man angeben
kann, sondern man selbst einen 68k-Ersatz zusammenbasteln muss.
Mit IFFParse setze ich z.B. auch nur *dann* einen User-Stream, wenn ich
ihn benötige...
RawDoFmt() ist zwar eher nebensächlich, aber eben *einer* der Punkte,
die man vielleicht für V43 ändern sollte.
Es würde ja schon reichen, wenn ein RawDoFmt(format, data, NULL, dest)
legal wäre, so daß bei Angabe von NULL für &PutChProc die interne
Routine verwendet werden würde. Damit wären dann 90 Prozent der Fälle
abgedeckt.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Dehydriertes Wasser läßt sich in seinen ursprünglichen Zustand versetzen,
indem man der pulvrigen Substanz Wasser hinzufügt."
[ Scheibenwelt von A-Z, über den "Dehydrierten Ozean" ]
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
Stefan...@nmp.nokia.com (Stefan Becker) schrieb am 16.09.1996 um 08:55:03 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> > Ich habe ja nichts gegen vorausschauende und vorsichtige Programmierung,
> > aber irgendwie fehlen mir da Kontinuität und Konsequenz.
> Genau deswegen bin ich inzwischen der Meinung, daß die Hüter des Grals
> (wer das auch immer momentan sein mag) die Ausnahmen OFFIZIELL
> dokumentieren sollten. Also z.B. "die Library Bases von DOS,
> Intuition, Graphics.... dürfen zwischen Tasks geshared werden" als
> Text im DevInfo Verzeichnis auf der Amiga Developer CD.
100 Prozent Zustimmung
> > Warum soll ich mehr Vorsicht walten lassen, als die Programmierer des
> > OS selbst in ihren Beispielsourcen ?
> Ich halte die meisten Beispiele in den RKMs für Quick Hacks, die grob
> zeigen wie etwas gemacht wird. Eine offizielle Dokumentation sind sie
> allerdings nicht.
Kann sein, aber das ist zumindest grob fahrlässig (weniger schnelle Hacks
gibt's nirgendwo in den RKMs oder Companions), und ein weiteres Indiz für
die Vermutung, dass der Hinweis "do not share..." in den RKMs eine reine
Vorsichtsmaßnahme war, die die OS-Programmierer selbst nicht in die Praxis
umgesetzt haben.
Ich finde, man sollte die Kriterien für PPC-Programme entsprechend verschärfen,
aber bitte die 68k-Programme (und die 68k-Emulation) in Frieden ruhen lassen.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"66-Megalith-Steinkreise sind inzwischen der Standard."
[ Scheibenwelt von A-Z, über Druiden(-Computer) ]
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
ol...@sourcery.han.de (Olaf Barthel) schrieb am 15.09.1996 um 19:05:12 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
[ InitLib ]
> Es geht nicht um's Wait() oder darum, potentiell ein Forbid() zu
> unterbrechen. Die Library-Initialisierungsfunktion wird ohnehin nicht
> notwendigerweise unter Forbid() ausgefuehrt, eigentlich ist es eher
> unwahrscheinlich, dass es so passiert. Was gravierender ist, ist dass
> ramlib beim Laden von Libraries und Devices eine Warteschlange abarbeitet:
> Wenn Du in Deiner Initialisierungsroutine eine Matrix mit 676 Elementen
> invertierst, hat dies mit einiger Wahrscheinlichkeit zur Folge, dass
> andere Programme auf das Oeffnen ihrer disk-residenten Libraries und
> Devices werden unverhaeltnismaessig lange warten muessen, bis Deine
> Initialisierungsroutine beendet ist. Erst danach kann ramlib sich um
> die naechste Anforderung kuemmern.
Stimmt - das ist aber eher eine Frage des Stils, als der Legalität ;-)
Außerdem werden die Libs ja nur einmal geöffnet - dürfen die Bases nicht
gemeinsam verwendet werden (Sharing), kann diese Wartezeit theoretisch
bei jedem libOpen-Aufruf zustandekommen...
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
dig...@home.lake.de (Aaron Digulla) schrieb am 15.09.1996 um 17:15:44 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> Das erinnert mich gleich an ein Problem, das ich mal bei meiner CInt.library
> hatte: Ich benötigte Shared and Local Data. Kannst Du den Beispielcode so
> erweitern, dass man ohne Probleme Daten erzeugen kann, die allen Prozessen
> zugaenglich sind und solche, die nur dem Prozess zugaenglich sind, der die
> Library geoeffnet hat ?
Klar ;-)
/* für die Library */
struct Handle /* private, deshalb APTR */
{
struct DOSLibrary *DOSBase;
};
APTR __saveds __asm EXP_AllocHandle(ULONG register __a0 *args)
{
struct Handle *handle;
handle = (APTR) AllocVec(sizeof(struct Handle), MEMF_ANY);
if(handle)
{
handle->DOSBase = OpenLibrary("dos.library", 37)
if(handle->DOSBase) return(handle);
FreeVec(handle);
}
return(NULL);
}
void __saveds __asm EXP_FreeHandle( register __a1 struct Handle *handle)
{
if(!handle) return;
if(handle->DOSBase) CloseLibrary(DOSBase);
FreeVec(handle);
}
/* für's Programm */
handle = EXP_AllocHandle(args)
if(handle)
{
Funktion_Aus_Lib(handle, func_args)
EXP_FreeHandle(handle)
}
to be continued
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
Never test for an error condition you don't know how to handle.
- Steinbach's Guideline for Systems Programming
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
> So wie ich das verstanden habe, wird nicht die Library-Base modifiziert,
> sondern eine *neue* Library-Base angelegt, dh. lib-init ist leer und
> lib-open macht die ganze Arbeit.
Stimmt.
Es ging mir aber darum, dass das Kopieren einer Base IMHO keine besonders gute
Lösung ist - schließlich ist das *auch* eine Systemstruktur, mit der ich
da umgehe.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"Per definitionem sind alle Theorien über den Ursprung
Andreas R. Kleinert
mle...@serpens.swb.de (Michael van Elst) schrieb am 15.09.1996 um 16:10:18 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> > Die offiziellen Beispielsources von C= machen es nicht anders,
> > also muß es in *diesem* Fall schonmal legal sein,
> Nein, das besagt nur, dass es funktioniert. Legal waere es, wenn
> genau diese Praxis ausdruecklich erlaubt wuerde. Statt dessen aber,
> war sowas frueher ueberhaupt nicht dokumentiert und in den
> aktuellen RKRMs steht _explizit_ drin, dass du es _nicht_ tun
> sollst.
Um das mal klarzustellen - ich will mich naemlich nicht mit Dir streiten,
sondern mir geht's um die Sache:
Du mußt mich nicht überzeugen !
Ich sehe durchaus ein, daß eine PPC-Portierung (womöglich mit angedachter
MP-Unterstützun) gewisse Anforderungen an die Programme (Libraries, etc.)
stellt.
Ich bin nur dafür, daß man die ganz klar von den Anforderungen an bestehende
68k-Programme trennt, die de fakto überwiegend nunmal nicht diesen Anforderungen
entsprechen.
Weil die hierzu gehörige Dokumentation schlicht nicht *eindeutig* ist
(im RKM kann 10x irgendetwas stehen - 90 Prozent der Leute orientieren
sich an den Beispielsourcen, außerdem steht nicht in allen RKMs das gleiche).
Es hat eben 1985 noch niemand eine PPC-Portierung und MP-Unterstützung
vorwegnehmen *können*
Wenn ich die Vorschläge, die bisher gemacht wurden...
- kein Base-Sharing, stattdessen: - Base Kopieren
- kontextbezogener Parameter für Fkt.
- nichts mehr in LibInit öffnen, sondern alles in LibOpen erledigen
- nicht auf Forbid() verlassen, sondern Semaphoren verwenden
...mit dem vergleiche, was in den RKM-Sourcen steht (die auch auf der
neuesten Developer-CD unverändert enthalten sind), dann ergibt sich ein
Unterschied wie Tag und Nacht.
Ich persönlich habe damit *kein* Problem - *meine* aktuellen Libraries
besitzen für fast jede Fkt. den o.g. Kontextparameter...
> > Es ist - kein Assembler mehr enthalten [...]
> Wo ist der Witz bei der Sache ? Ob du nun SAS/C mit oder ohne
> Assembler benutzen musst ist ja wohl egal (und nebenbei brauchst
s.u.
> > Stichwort: - Crosscompiler PCC->68k
> Diese muesste die SAS/C-Spezialitaeten kennen.
StormC ist die neue Referenz. StormC ist kompatibel zu SAS/C.
> > - saubere Programmierung von Library aus
> > einer reinen C-Umgebung heraus
> Quark mit Sosse. Wo ist __asm+Co reines C ?
Ist es nicht, habe ich auch nicht geschrieben - aber was ich in C
durch ein simples #define ändern kann, geht mit Assembler nicht.
#define REG register
#define __XYZ __a6
Aber die und ähnliche Tricks kennst Du ja sicherlich ebenfalls bereits.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
Any sufficiently advanced technologie is indistinguishable from magic.
-- MicroDot 1.11beta26 registered
Michael van Elst
A...@COB.WWBNET.DE (Andreas R. Kleinert) writes:
>> > Paßt ein PPC-JMP plus Adresse in 6 Bit ?
>> Interessiert das einen die Bohne, wenn man MakeLibrary() zur Verfügung
>> hat?
> Es interessiert das 68k-Programm, das in einer PPC-Umgebung Libraries aufruft.
Wie kommst du darauf ?
> (Muss ich eigentlich alles dreimal erläutern, oder liest auch jemand mal
> die Mails komplett, ohne gleich zurückzuflamen ?)
Du ueberschaetzt dich aber gewaltig.
>> > Dass SAS/C der einzige Compiler ist, der das unkompliziert und
>> > direkt erlaubt (vielleicht auch StormC), kann ich nicht ändern,
>> Mit DICE geht es genauso unkompliziert.
> Den benutze ich weder, noch ist er die Referenz.
Die was ? :)
Joern Plewka [pe]
mle...@serpens.swb.de (Michael van Elst) -> "Re: How to write: Exec shared library in 100% C"
(16.09.1996)
> "Bernhard Moellemann" <z...@mhystic.hall.sub.org> writes:
>
> >müssen. Besonders brutal bremst das ARexx aus, weil das Function
> >Libraries bei jedem Befehl neu öffnet und anschließend schließt.
>
> Das Verhalten von AREXX ist eh nervig und gehoert gefixt.
Gab es da nicht irgendeinen Trick für den Interpreter!?
CALL vor die Aufrufe oder so?! (Ich beschränke mich auf AdPro....)
--http://users.informatik.fh-hamburg.de/~plewka_j
|
+-> elm:j_pl...@amtrash.comlink.de
+-> plew...@informatik.fh-hamburg.de
|
+--> MELODY, MPEG audio w/o intensive system load
+--> SIMMfonie, PS/2 Modules in Amiga3ooo(T)
Michael van Elst
RAWS...@BLACKBOX.dame.de (Krause Michael) writes:
>Ich glaube, hier wird etwas mißverstanden -- Die SysBase kann (muß)
>gesharet werden, aber nicht der gecachte Wert der SysBase: Exec muß sich
>darum kümmern, daß 0x4 für jeden Task den jeweils richtigen Wert enthält,
>Oder hab' /ich/ jetzt was mißverstanden?!?
Ja und nein. Es waere natuerlich machbar, dass ein zukuenftiges OS
getrennte SysBase-Pointer fuer verschiedene Tasks benutzt (so dass
auf Adresse 4 je nach Task verschiedene Werte stehen).
Andererseits garantieren die derzeitigen RKRMs, dass der Pointer
(== der Wert an Adresse 4) von anderen Tasks benutzt werden kann.
Getrennte Pointer bedeuten also eine Inkompatibilitaet, und zwar
eine unnoetige.
Salut,
Matthias Andree
RAWS...@BLACKBOX.dame.de (Krause Michael) schrieb am 16.09.1996 um
16:30:20 Uhr zu Re: How to write: Exec shared library in 100% C
folgendes:
> Ich glaube, hier wird etwas mißverstanden -- Die SysBase kann (muß)
> gesharet werden, aber nicht der gecachte Wert der SysBase: Exec muß sich
> darum kümmern, daß 0x4 für jeden Task den jeweils richtigen Wert enthält,
> reentrante Programmteile dürfen natürlich nicht auf einen im Startup (z.B.
> Device- oder Library-Init) gecachten Wert zurückgreifen. Wenn man die
> Adresse schon cachen will, muß das beim Start jedes Device-Prozeßes
> geschehen.
Gängige Praxis vieler Compiler ist aber, die Zementierung der ExecBase
anzunehmen und die Adresse im Fastmemory zu cachen. Bisher läuft's, ob
es in zukünftigen Versionen läuft, ist, wie schon gesagt wurde,
fraglich.
Gruß,
--
MATTHIAS ANDREE
Öffentlicher PGP-Schlüssel auf Anfrage verfügbar
Michael van Elst
m_an...@tribal.line.org (Matthias Andree) writes:
>Gängige Praxis vieler Compiler ist aber, die Zementierung der ExecBase
>anzunehmen und die Adresse im Fastmemory zu cachen.
Das hat a) nichts mit dem Thema zu tun und wird b) sogar ausdruecklich
empfohlen.
Ralph Babel
Andreas Kleinert schrieb:
> Daß Base-Sharing *in* *der* *Regel* legal sein sollte,
> geht IMHO daraus hervor, daß C= es selbst in den
> Beispielsourcen praktiziert, und an den Stellen, wo es
> nicht sein sollte, *explizit* darauf hinweist (mathieee).
>
> Daß irgendwann einmal jemand (in den späteren RKM-Auflagen
> ?) "vorsichtshalber" hineingeschrieben hat, daß man nicht
> davon ausgehen solle, immer dieselbe Library-Base zu
> bekommen, ist für mich a) nicht überzeugend, und b)
> vielleicht sogar mißverständlich
Im Zusammenhang mit diesen Kerngedanken möchte ich auf zwei
ältere Artikel von mir verweisen, die ich unter
ftp://ftp.pfm-mainz.de/pub/amiga/libbase.lha
verfügbar gemacht habe.
Andreas R. Kleinert
> In diesem Zusammenhang muß man natürlich auch noch S.467 erwähnen: "...the
> only library base sharable between tasks is Exec's library base."
Bei der Diskussion "shareable oder nicht-shareable" sollte man vielleicht
auch berücksichtigen, daß die Intention hinter dieser Restriktion auch
eine ganz andere gewesen sein könnte (natürlich nur, falls das jetzt nicht
auch wieder unter "#1: Do not assume" fällt. SCNR ;-)
Wenn Task A eine Library öffnet, die Base mit Task B teilt,
und dann Task A vor Task B endet, und die Library wieder schließt,
besitzt Task B eine (möglicherweise) ungültige Library-Base.
(Der OpenCnt spiegelte dann BTW auch nicht mehr die Anzahl der Nutzer
wider, was - back from excursion - bei einer Library ein Sonderfall wäre).
Die SysBase dagegen erhält man nie durch Öffnen - da exec.library deshalb auch
nie geschlossen/entfernt werden kann, kann die Base auch nie durch Schließen
ungültig werden...
Das ist *eine* Interpretationsmöglichkeit - natürlich ändert das nichts daran,
daß im RKM Libraries steht "do not share...", aber das Base-Sharing über eine
(andere) Library-Base ist nunmal kein *direktes* Sharing von Library-Bases,
sondern erfolgt *indirekt* , ohne das Risiko für den (anderen) Task, die Base
unter den Füßen weggezogen zu bekommen.
*So* hätte ich die Stelle in den RKMs verstanden.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
persistent - resistant -> PERSISTANT
-- MicroDot 1.11beta26 registered
Andreas R. Kleinert
Stefan...@nmp.nokia.com (Stefan Becker) schrieb am 16.09.1996 um 08:55:03 Uhr, eine Mail unter dem Betreff "Re: How to write: Exec shared library in 100% C".
Dazu habe ich folgendes zu sagen:
> Ich halte die meisten Beispiele in den RKMs für Quick Hacks, die grob
> zeigen wie etwas gemacht wird. Eine offizielle Dokumentation sind sie
> allerdings nicht.
Darf ich dazu Heinz Wrobel aus <heinz...@hwg.muc.de> zitieren (SCNR ;-) ?
->Irgendjemand hat irgendwo geschrieben "nur ein Beispiel". _Gerade_
->ein Beispiel muß suaber sein. Sonst ist es _nur_ ein Hack.
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
"66-Megalith-Steinkreise sind inzwischen der Standard."
Andreas R. Kleinert
> In diesem Zusammenhang muß man natürlich auch noch S.467 erwähnen: "...the
> only library base sharable between tasks is Exec's library base."
...und was ist eigentlich mit *Prozessen* ;-)
(erst seit V36 ist OpenLibrary() "protected from tasks")
--
Andreas_...@t-online.de | SY...@superview.ftn.sub.org
Fido 2:2457/350.18 | A...@COB.wwbnet.de
Visit http://home.t-online.de/home/Andreas_Kleinert/main.htm
->>> Image Engineer Registration Site Europe <<<-
Greatest Win-Feature:
ALT-F4 works with any application...
-- MicroDot 1.11beta26 registered
Stefan Becker
A...@COB.WWBNET.DE (Andreas R. Kleinert) writes:
> Ich finde es schlicht nicht akzeptabel, dass Referenzimplementationen
> aus den RKMs auf einmal schlimme Hacks sein sollen.
Ich würde sie nicht als Referenzimplementationen bezeichnen. Die
einzige Referenz sind die AutoDocs.
> Davon abgesehen ist Forbid() mittlerweile auch als "obsolete" deklariert,
> d.h. wenn schon, dann dürfte der Library-Porgrammierer *gar* *nichts* fordern,
> und sich auf *gar* *nichts* verlassen, das eingehalten oder nicht eingehalten
> wird, sondern müsste sich sein jeweiliges Semaphoren-System selber basteln.
Wenn Forbid() obsolet wird, dann wird Exec Open/Close/Expunge mit
einer Semaphore sichern, da diese Operationen "atomic" sein müssen. Wo
ist da ein Problem?
> Jedenfalls hat sich über diverse Assembler Sourcen, die a) alle Libraries
> in LibInit öffnen und b) alle Bases sharen, niemals jemand aufgeregt,
> aber als C-Source ist es auf einmal ein kleines Verbrechen...
Du hast deinen Source vollmundig als Beispiel angekündigt und wir
haben dich nur darauf hingewiesen, daß es ein schlechtes ist :-)
Stefan Zeiger
Andreas R. Kleinert schrieb:
> Es w=FCrde ja schon reichen, wenn ein RawDoFmt(format, data, NULL, dest)
> legal w=E4re, so da=DF bei Angabe von NULL f=FCr &PutChProc die interne
> Routine verwendet werden w=FCrde. Damit w=E4ren dann 90 Prozent der F=E4=
lle
> abgedeckt.
Was sollte diese Routine denn machen? sprintf()? Das ist bereits in der
amiga.lib enthalten, ebenso printf().
Sven Heithecker
Stefan Zeiger wrote:
>
> Andreas R. Kleinert schrieb:
>
> > legal wäre, so daß bei Angabe von NULL für &PutChProc die interne
> > Routine verwendet werden würde. Damit wären dann 90 Prozent der Fälle
>
> Was sollte diese Routine denn machen? sprintf()? Das ist bereits in der
> amiga.lib enthalten, ebenso printf().
Stimmt. Die machen das Programm aber gleich um mehrere K laenger, und
wenn die Moeglichkeiten von RawDoFmt ausreichen, warum dann nicht sehr
einfach Code sparen ?
--
____
|_||_ Ceterum Censeo MEGAHARD Esse Delendam
| | _| HTS Sven Heithecker s.heit...@tu-bs.de
Stefan Eggers
A...@COB.WWBNET.DE (Andreas R. Kleinert) schrieb:
> > > Paßt ein PPC-JMP plus Adresse in 6 Bit ?
> > Interessiert das einen die Bohne, wenn man MakeLibrary() zur Verfügung
> > hat?
>
> Es interessiert das 68k-Programm, das in einer PPC-Umgebung Libraries aufruft.
Nicht notwendigerweise. Man könnte in der Basis ein 68k-JMP stehen
haben und der Zeiger zeigt auf PPC-Code. Der PPC-Code dagegen ist so
schlau und macht nicht ein JSR -6 * Nummer(Basis) sondern holt sich
die Adresse direkt da draus. Dann ist's egal wie groß ein PPC-JMP
ist.
Was man allerdings braucht ist eine Kennung wo 68k-Code anfängt und
wo der aufhört. Irgendwie muß man das dann wohl dem System per MMU
beibringen. Sonst funktionieren Funktionen einer PPC-Library von
einem 68k-Programm aus aufgerufen niemals wenn sie ein Callback benö-
tigen. Wäre ja höchst unschön.
Stefan.
--
Stefan Eggers
Max-Slevogt-Str. 1
51109 Koeln
Federal Republic of Germany
Gunther Nikl
Sven Heithecker (s.heit...@tu-bs.de) wrote:
> Stefan Zeiger wrote:
> > Was sollte diese Routine denn machen? sprintf()? Das ist bereits in der
> > amiga.lib enthalten, ebenso printf().
> Stimmt. Die machen das Programm aber gleich um mehrere K laenger, und
> wenn die Moeglichkeiten von RawDoFmt ausreichen, warum dann nicht sehr
> einfach Code sparen ?
Bloedsinn! Das sprintf() der *amiga.lib* benutzt RawDoFmt(). Aber
sprintf() ist die einzige Routine die mann verwenden sollte (printf
der amiga.lib braucht noch zusaetzliche globale Variablen und kann
leicht auf dem Stack Unordnung schaffen)
Gunther
Sven Heithecker
Gunther Nikl wrote:
>
> Sven Heithecker (s.heit...@tu-bs.de) wrote:
> > Stefan Zeiger wrote:
> > > Was sollte diese Routine denn machen? sprintf()? Das ist bereits in der
> > > amiga.lib enthalten, ebenso printf().
>
> > Stimmt. Die machen das Programm aber gleich um mehrere K laenger, und
> > wenn die Moeglichkeiten von RawDoFmt ausreichen, warum dann nicht sehr
> > einfach Code sparen ?
>
> Bloedsinn! Das sprintf() der *amiga.lib* benutzt RawDoFmt(). Aber
Ok, sorry - hab ich ueberlesen ...
Michael van Elst
Sven Heithecker <s.heit...@tu-bs.de> writes:
>> Was sollte diese Routine denn machen? sprintf()? Das ist bereits in der
>> amiga.lib enthalten, ebenso printf().
>Stimmt. Die machen das Programm aber gleich um mehrere K laenger
Du denkst wahrscheinlich an sprintf/printf aus der SAS library.
Die amiga.lib-Versionen machen nichts anderes als dein Code mit
RawDoFmt und sind dementsprechend kurz.
Salut,
Stefan Eggers
gn...@informatik.uni-rostock.de (Gunther Nikl) schrieb:
> sprintf() ist die einzige Routine die mann verwenden sollte (printf
> der amiga.lib braucht noch zusaetzliche globale Variablen und kann
> leicht auf dem Stack Unordnung schaffen)
Globale Variablen sind klar. Aber wieso sollte der Aufruf dieser
Funktion den Stack beeinflussen?
Stefan Eggers
A...@COB.WWBNET.DE (Andreas R. Kleinert) schrieb:
>
> > In diesem Zusammenhang muß man natürlich auch noch S.467 erwähnen: "...the
> > only library base sharable between tasks is Exec's library base."
>
> Bei der Diskussion "shareable oder nicht-shareable" sollte man vielleicht
> auch berücksichtigen, daß die Intention hinter dieser Restriktion auch
> eine ganz andere gewesen sein könnte (natürlich nur, falls das jetzt nicht
Wenn jemand diesen Programmierfehler (Task A öffnet Library, Task B
startet und nutzt die Library ohne sie zu öffnen, Task A schließt
Library, Task A ended, Task B will Library nutzen) im Sinn hatte ist
das wie mit Kanonenkugeln auf Spatzen zu schießen.
Wäre es nicht vielleicht sinnvoll auch gleich als neue Programmier-
konvention einzuführen, daß bei einem Funktionsaufruf einfach alle
Register scratch sind? Nur für den Fall, daß jemand in seinen Routi-
nen die D0/D1/A0/A1-Konvention nicht beachtet ...
SCNR
> Das ist *eine* Interpretationsmöglichkeit - natürlich ändert das nichts daran,
> daß im RKM Libraries steht "do not share...", aber das Base-Sharing über eine
> (andere) Library-Base ist nunmal kein *direktes* Sharing von Library-Bases,
> sondern erfolgt *indirekt* , ohne das Risiko für den (anderen) Task, die Base
> unter den Füßen weggezogen zu bekommen.
??? Du meinst wenn beide Tasks getrennte GfxBase haben würde der von
Dir beschriebene Fall harmlos sein? Oder wie soll ich das verstehen?
Wäre er nämlich keineswegs. Einziger Unterschied ist der, daß Task A
nicht unabsichtlich Task B den Zeiger wegziehen kann, aber wenn die
Library geschlossen wurde ist sie immer noch geschlossen.