Zitat:

---

Original von Solar:

Zitat:

---

Original von gni:
Solar, Du hast bei Deinem Zitat etwas unterschlagen... putchar() ist genau wie putc() ein _Makro_! Das bedeutet doch wohl, das sowohl putchar() als auch putc() (und getc()) nicht als Funktion in einer Linker-Library sein müssen.

---

Der Linker hat ja auch keine "unresolved reference" gemeldet, sondern "can't find reference". Ich würde hier eher vermuten, das GCC bei Optimierung -O1 aus printf("n") das "billigere" putchar('n') macht, und sich dann irgendwo verhaspelt.

---

Zitat:

---

Mein Zitat bezog sich nur darauf, das putchar() sehr wohl Teil des Standards ist; nicht auf die eigentliche Fehlerursache. ;-)

---

Zitat:

---

Original von gni:

Zitat:

---

Solar:

Zitat:

---

Original von gni:
putchar ist keine ANSI/ISO Funktion und deswegen nicht Teil von libnix...

---

Da muß ich Dich enttäuschen... putchar() ist Teil des Standards, und definiert als "equivalent to putc with the second argument stdout"...

---

Tatsächlich, das war mir entgangen :-/ Da putchar als Makro in stdio.h definiert war, ist das Fehlen von putchar als Funktion nicht aufgefallen.

---

Zitat:

---

Mazze:

Zitat:

---

BTW, Du weisst, das GCC 3.3 unter Umständen bei Verwendung von LP-Inlines nicht-funktionierenden Code erzeugt?

---

Habe ich nicht gewusst. Allerdings muss ich ein #define setzen, wenn ich ReAction-GUIs erstelle. Dies hat möglicherweise etwas mit den LP-Makros zu tun.

---

Zitat:

---

Eine C-Funktion mit einem Pointer als Argument:
Bsp: void test(void *p)
würde ich in einer Library mit den Makros aus Clib-SDI folgendermaßen deklarieren
ASM(VOID) LIBtest (REG(a0, APTR p))
Kann ich a0 durch d0-7 ersetzen?

---

Zitat:

---

Leute, ich stelle das Thema "Library erzeugen" erstmal zurück und binde stattdessen den C-Code direkt ein. Wahrscheinlich habe ich einen Fehler gemacht, den ich erst finde, wenn ich mit etwas zeitlichem Abstand noch mal von vorne anfange.

---

Zitat:

---

analogkid:

Zitat:

---

tploetz:
Hallo,
das Programm NCodeR läuft auf meinem Amiga 4000T mit Cyberstorm PPC
wie eine Schnecke. Für eine Musikdatei von 4 Minuten braucht
das Programm zum Encodieren 30 Minuten und in diese Zeit läßt
sich die Maus nicht bewegen.

---

was spricht gegen SecondSpin ?

---

Zitat:

---

Mazze:

Zitat:

---

Machst Du Assembler oder C?

---

Ich programmiere in C und zwar gcc3.3 unter Amithlon/AOS3.9BB2.

---

Zitat:

---

Wenn ich in einem normalen C-Programm Registervariablen verwende, dann trifft es auf jeden Fall zu, dass die Registerinhalte an einen sicheren Ort gebracht werden.

---

Zitat:

---

Aber was passiert, wenn ich eine Library-Funktion aufrufe? Weis der C-Kompiler, dass bestimmte Register (Scratch) "hinterrücks" von den Library-Funktionen verändert werden können?

---

Zitat:

---

Ich habe jetzt mal in der Library die Registerparameter a0 und a1 durch a3 und a5 ersetzt.

---

Zitat:

---

Jetzt bekomme ich im Test-Programm einen Parse-Error. Als Ursache vermute ich folgendes Makro im Inline-Header:

code:

---

#define sl_map(root, func, data) 
	LP3A5(0x3c, APTR, sl_map, APTR, root, a2, struct Hook *, func, a3, APTR, data, d7, 
	, SL_BASE_NAME)

---

Hier fällt zunächst mal auf, dass der 3. Parameter statt auf a5 auf d7 liegt.

---

Zitat:

---

In meinem inline/macros.h ist kein LP3A5 definiert. Hier klappt offenbar das Zusammenspiel zwischen fd2pragma und gcc nicht.

---

Zitat:

---

Frage: gibt es einen Unterschied zwischen Adress- und Wert-Register? Kann ich eine Adresse an ein Wert-Register übergeben? Oder muss ich mich übergeben?

---

Zitat:

---

melior:

Zitat:

---

2. Wie sind denn die genauen Sekunden zwischen 1.1.1970 und 1.1.1978?

---

252457200 (ohne Gewähr)

---

Zitat:

---

thomas:

Zitat:

---

Library-Funktionen werden _immer_ relativ zur Librarybasis aufgerufen. Direkte Aufrufe sind nicht möglich. Der Prototyp in clib/ ist nicht der Name der "echten" Funktion im Quell-code sondern der des Einsprungs relativ zur Basis.

---

Das stimmt so nicht. Wenn du nur die clib/xyz_protos.h einbindest und die amiga.lib dazulinkst, hat jede OS-Funktion einen C-Stub, der ganz normal mit Stack-Parametern aufgerufen wird und auch eine absolute Adresse hat.

---

Zitat:

---

obw:

Zitat:

---

gni:
Das habe ich auch so verstanden. Und genau das verursacht auch den Stackoverflow. Library-Funktionen laufen immer im Context des Programmes, das die Library benutzt. Wenn das Programm "wenig" Stack hat, Du aber viel benötigst, gibts einen Crash. Entweder Du verlangst genügend Stack oder Du wechselst den Stack, wenn zuwenig da ist.

---

Interessante Frage: Wie stelle ich fest, ob zu wenig da ist? Spontan
würde ich sagen: StackSwap() auf Verdacht und dann stk_Pointer und stk_Lower vergleichen. Dann wieder zurückswappen. Kann man als Stack für die StackSwapStruct einfach beliebig allozierten Speicher verwenden (Alignment?)?

---

Zitat:

---

Zitat:

---

Library-Funktionen werden _immer_ relativ zur Librarybasis aufgerufen. Direkte Aufrufe sind nicht möglich. Der Prototyp in clib/ ist nicht der Name der "echten" Funktion im Quell-code sondern der des Einsprungs relativ zur Basis.

---

Wenn ich also eine Funktion habe, die sich z.B. rekursiv durch einen Baum arbeitet, mache ich das am besten wie? so?

code:

---

ULONG lib_func(ULONG foo)
{
  return do_func(ULONG foo);
}

static ULONG do_func(ULONG foo)
{
  [...]
  bar = do_func(bar);
  [...]
}

---

korrekt?

---

Zitat:

---

Für lib_func() gibt es ein öffentliches Interface in den Includes. do_func() ist rein intern.

---

Zitat:

---

Mazze:

Zitat:

---

Non-Scratch Register werden bei Funktionseintritt gesichert.

---

Angenommen, ich habe in einer Funktion eine Variable auf ein Scratch-Register gelegt.

---

Zitat:

---

melior:
Über die battclock.resource stellst Du nur die Echtzeituhr des Amigas. Wenn Du die Uhrzeit Deines Rechners dauerhaft verstellen willst, dann mußt Du sowohl die Systemuhr (timer.device:setSysTime) als auch die Echtzeituhr stellen.

---

Zitat:

---

THDany:
Ich will das die Uhr zur Sommer und Winterzeit automatisch die BattClock umstellt, spricht die aktuellen, mit time(); ermittelten Sekunden +-3600 in die BattClock speichert.

---

Zitat:

---

#include <time.h>
#inclue <proto/battclock.h>

void main()
{
time_t jetzt;

time(&jetzt);

jetzt -=3600;

WriteBattClock(jetzt);
}

---

Zitat:

---

Will ich es so compilieren bekomme ich die Fehlermeldung vom Linker, dass BattClockBase nicht nicht definiert ist.
Füge ich nun struct Library *BattClockBase; hinzu compiliert er das Teil anstandslos und beim Ausführen schmiert es mir ab. Ich würd ja gern eine Library für das Teil öffnen, nur welche?

---

Zitat:

---

Oder mache ich sonst etwas falsch?

---

Zitat:

---

Mazze:

Zitat:

---

von gni:

Zitat:

---

Mazze:
Um der Fehlerursache näher zu kommen: Was passiert, wenn sich eine Libraryfunktion rekursiv aufruft?

---

Das klingt nach Stack-overflow.

---

Ich habe mich ungenau ausgedrückt. Die Funktion wird absichtlich rekursiv aufgerufen.

---

Zitat:

---

Zitat:

---

Library-funktionen (auch eigene!) sollten immer relativ zur Librarybasis aufgerufen werden.

---

Bei den eigenen Funktionen kenne ich den Prototyp. Aber in den Protos der Systemlibraries taucht doch der Basepointer gar nicht auf?

---

Zitat:

---

THDany:
Wenn das Programm keine Funktionen findet kann es diese auch wohl schlecht ausführen.

---

Zitat:

---

Oder gehst du jetzt nur von den Prototypen ohne Funktion aus? Die will mein Compiler (Storm C V3) auch haben sonst gibt es Fehlermeldungen.

---

Zitat:

---

THDany:
Ja klar war es das __saveds. Hab den Timer aus nem anderen Programm das mit Near-Code compiliert wurde. Ich arveite aber mit Far-Code. __saveds gelöscht und schon gehts.

---

Zitat:

---

Mazze:
im Moment sieht es so aus, dass alles bis auf eine Sortierfunktion funktioniert.
Um der Fehlerursache näher zu kommen: Was passiert, wenn sich eine Libraryfunktion rekursiv aufruft?

---

Zitat:

---

Werden dann die Register gesichert oder muss ich mich selbst darum kümmern?

---

Zitat:

---

Holger:
Also bei mit steht in den protos:

code:

---

#if defined(__OPTIMIZE__) && !defined(__NOINLINES__)
#include <inline/dos.h>
#endif

---

Mag jeder selbst raten, welche compiler-optionen dafür gesetzt sein müssen.

---

Zitat:

---

Ich habe das Beispiel ohne weitere Optionen übersetzt und zumind. mit Version 2.7 keine Probleme gehabt.

---

Zitat:

---

Allerdings habe ich den starken Verdacht, daß auch die inlines anders aussehen und bei diesem Beispiel auch keine Warnungen produzieren würden. Habe jetzt auch keine Lust, für dieses Beispiel jetzt noch andere gcc-Versionen durchzuprobieren.
[...]
Sollten neuere Compiler/Umgebungen jetzt Fehler oder unnötige Warnungen verursachen, ist das nicht gerade eine Motivation zum Umsteigen.

---

Zitat:

---

Original von Mazze:
Nach dem ich free durch FreeVec ersetzt hatte, bekam ich bei dieser Funktion den Fehler mit der fehlenden SysBase. Der Fehler tritt nur auf, wenn ich die Funktionsadresse zuweise (z.B. func = FreeVec). Beim normalen Aufruf klappt das. Ich habe deshalb die Library-Funktion so umgebaut, dass keine Zuweisung der Funktionsadresse stattfindet.

---

Zitat:

---

Mazze:
/gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libnix/libnix.a(free.o)(.tex t+0x2a): undefined reference to 'SysBase'
/gg/lib/gcc-lib/m68k-amigaos/3.3/../../../libnix/libnix.a(malloc.o)(.t ext+0x18): undefined reference to 'SysBase'
[/code]
Da wird doch eindeutig noch free/malloc von libnix verwendet.
[code]
Ich verstehe das nicht. SysBase wird in libinit.c definiert.

---

Zitat:

---

Original von whose:
Hm, also mit meiner GCC-Installation hab ich gar nichts veranstaltet... der 3.3 ist der aus der GoldEd-Installation und läuft ohne irgendwelche "Anpassungen".

---

Zitat:

---

Der 2.95.2 ist der StormC4-GCC mit Includes die ich mir per fd2inline neu erzeugt hab, weil die mitgelieferten arge Probleme haben (weshalb meist ein NO_INLINE_LIBCALLS notwendig wird, wenn man AOS-Funktionen nutzt)

---

Zitat:

---

Zitat:

---

Zitat:

---

Übrigens: Hat nicht H. Wrobel den ersten Port des 3.x erledigt?

---

Wozu der Smiley?

---

Aus Spaß an der Freud?

---

Zitat:

---

P.S.: Ich hab nochmal nachgeschaut, die "Option" heißt __USE_INLINE__. Ich nutz die beim 3.3 selten, weil ich den meist nur für Testzwecke einsetze. Beim StormC hab ich das als Default, da heißts dann "Dont inline" und ist ausgeschaltet.

---

Zitat:

---

whose:
ob der GCC meckert oder nicht, sollte er den Jungs schon glauben, wenn sie es sagen. Bei mir meckern nämlich auch beide Versionen nicht (2.95.2 und 3.3)

---

Zitat:

---

Sagt Dir die Option "do-inline" was?

---

Zitat:

---

Übrigens: Hat nicht H. Wrobel den ersten Port des 3.x erledigt?

---

Zitat:

---

nferno:
habe mal wieder ein gcc - Problem

---

Zitat:

---

---- test.cpp ----

---

Zitat:

---

c++ -noixemul -o test test.cpp

übersetze, dann funktionierts.

---

Zitat:

---

gcc -noixemul -o test test.cpp

übersetze, dann kriege ich die Fehlermeldung:

"/t/ccRj10SW.o(.text-0x30): undefined reference to 'sin'"

---

Zitat:

---

Otokai:
Im gcc.guide (gg:guide/gcc.guide)

Invoking gcc ->
Option summary ->
Machine Dependent options

findet ihr eine komplette Auflistung aller 68k (oder auch PPC etc.) spezifischen Optionen.

---

Zitat:

---

Inferno:
Das Problem war die Reihenfolge. -lm muß unbedingt HINTER die object-files.

---

Zitat:

---

OMad_Dog:

Zitat:

---

gni:

Zitat:

---

Palgucker:
Wohlgemerkt, die anderen Aufrufe von
struct Library *IntBase; bis ...
if (IntBase != NULL) CloseLibrary(IntBase);
wurden nicht geändert.

---

"IntBase" ist dem Compiler völlig egal.

---

Da gab's aber auch so Schlaumeier, die behauptet haben, der Zeiger müsse zwingend *IntuitionBase heißen, weil in proto/intuition.h ein solcher als globaler Zeiger deklariert ist...

---

Zitat:

---

Mad_Dog:

Zitat:

---

gni:
Es steht nirgends, das das NDK ohne Fehler ist Die Type-Probleme entstehen erst, wenn man die proto/ Header verwendet. Ursprünglich waren die NDK Beispiele nur für SAS/C und verwendeten clib+pragmas ohne "extern base" (wurde da nicht benötigt).

---

Wobei in die proto-Header laut Kommentar ursprünglich für Lattice C gedacht waren.

---

Zitat:

---

Palgucker:
Wohlgemerkt, die anderen Aufrufe von
struct Library *IntBase; bis ...
if (IntBase != NULL) CloseLibrary(IntBase);
wurden nicht geändert.

---

Zitat:

---

Mad_Dog:
Trotzdem kommt mir das ganze Rumgecaste noch reichlich sinnlos vor.

---

Zitat:

---

Dann muß ich einen Typecast machen, bevor ich den Zeiger zuweise, weil OpenLibrary einen Zeiger auf eine Struktur vom Typ Library zurückgibt:

code:

---

// Intuition Library öffnen
  IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",36L);

---

---

Zitat:

---

Beim Schließen muß ich nochmal Casten, da CloseLibrary als Eingabeparameter ebenfalls einen Zeiger auf eine Struktur vom Typ Library erwartet:

code:

---

// Librarie schließen
  if (IntuitionBase != NULL) CloseLibrary((struct Library *)IntuitionBase);

---

---

code:

---

&IntuitionBase->LibNode

---

Zitat:

---

Ich halte also einen Zeiger auf IntuitionBase, obwohl ich eigentlich einen Zeiger auf Library brauche. Ziemlich strange.

---

Zitat:

---

Und daß der Zeiger tatsächlich IntuitionBase heißen muß, liegt an der Definition des globalen Zeigers IntuitionBase in <proto/intuition.h> :

code:

---

extern struct IntuitionBase * IntuitionBase;

---

---

Zitat:

---

Für meinen Geschmack ein Bischen viel Kuddelmuddel. Mir scheint, der gcc will auf Biegen und Brechen Lattice C kompatibel bleiben.

---

Zitat:

---

Ich persönlich fand meinen ursprünglichen Code irgendwie schlüssiger...

---

Zitat:

---

Mad_Dog:
Seltsamerweise ist das in einigen Beispielen der NDKs auch mit struct Library *IntuitionBase; gelöst. Jedenfalls kann man sich so die lästigen Typecasts sparen.

---

Es steht nirgends, das das NDK ohne Fehler ist Die Type-Probleme entstehen erst, wenn man die proto/ Header verwendet. Ursprünglich waren die NDK Beispiele nur für SAS/C und verwendeten clib+pragmas ohne "extern base" (wurde da nicht benötigt).

Zitat:

---

Solar:

Zitat:

---

Original von gni:
Frag mal Solar bezüglich seinen Erfahrungen mit Storm und seinen SFStools.

---

Öhm... ich glaube Du verwechselst mich mit jemandem.

---

Zitat:

---

Mad_Dog:

code:

---

#include <clib/intuition_protos.h>
#include <clib/graphics_protos.h>
#include <clib/exec_protos.h>

---

---

Zitat:

---

code:

---

struct Library *IntuitionBase;  // Zeiger auf IntuitionBase-Struktur
struct Library *GfxBase;        // Zeiger auf Library-Struktur

---

---

Zitat:

---

1.) Der gcc mag nur Zeiger auf Library-Structs, die genauso heißen wie der Datentyp des Structs selbst, also z.B. struct Library *IntuitionBase; StormC hingegen schluckt auch sowas wie struct Library *IntBase; . Dabei finde ich es von Stil her schöner, wenn der Zeiger nicht unbedingt den gleichen Bezeichner hat, wie der Typ des Structs.

---

Zitat:

---

2.) Das geschilderte Problem mit dem Syntax Error kommt, daher, daß es der gcc einem übel nimmt, wenn man bei einem Typecast den Datentyp nicht in Klammern setzt. StormC ist es egal. Deshalb hat mein Makro random() auch nicht funktioniert.

---

Zitat:

---

3.) Der gcc gibt Warnings bezüglich der Header-Datei <clib/graphics_protos.h> aus. (bin etwas ratlos - flasche Includes?)

---